Strange.

I didn't quite understand, is this blue outline in the background the mask that is supposed to become the other master? Or is it actually the other master, so you already have an MM font? In that case, did that accident happen when it was already an MM font, or did something go wrong in the moment you built the MM font (out of two single master fonts)? In that case, how did you build the MM font? "Manually" with Mask to Master or with the built-in automatism (that never really works)?

Is it only in this particular view this is visual? That is, when you have the other master active the problem is solved?

Artur,

sounds like http://www.fontlab.com/support/problem

A.

Hi Tim,

This is already an MM font, so the contour in the background is actually the second master.
I build the MM font by adding a defining a weight axis to the first font, and after which I assigned a second master (so another opened vfb file) to the font.

In the source file of this other master, the contour is OK, the accident occurs when assigning this as a master.

Best,
Artur

@ Goran:

Nope, the contour is still affected with the other master active.

@ Adam:

Thanks, will do that.

Ah, I see. I hadn't thought of that possibility to build an MM font. Just out of curiosity: does the g also get messed up if you use Mask to Master instead of Assign Master? I always use the former method but it's not much different, actually.

If it's only a very small number of glyphs that gets messed up then you could fix that quite quickly by putting the bold master into the mask of the MM font (using Assign Mask) and then manually shift the nodes of the bold master back where they belong. Should only take a minute.

Cool, that last suggestion worked actually! Well, I didn't maunually shift nodes, but I copied the contours of g from the source font and pasted them into the mask layer of the bold master in the MM font, then I used the Mask to Master command.

So what I understand from this is that it is better to first assign a source font as a mask to an MM font, and then use the Mask to Master command.

And all this only to use your wonderful RMX tools Tim! ;)

Best,
Artur

Artur,

I see by your example, that your g is made up of three separate pieces. May I suggest that you try to interpolate as many characters as possible as whole glyphs, and not rely on this piece-together approach.

With your current approach once you have all your instances generated, you are still going to have a lot of "remove overlap" work to do. Wouldn't you agree that touching up two g glyphs is more efficient that touching up 6, 8 or 12?

And I agree that Tim's RMX tools are terrific!

JamesM

Personally, I prefer to have all my in between weights built from parts.
If for whatever reason I need to edit something, it's going to be a lot of pain with all the overlaps removed. A lot more pain than running a macro which the removes overlaps without any touching up after.

Best,
Artur

> Notice that a few points of the master in the background are being cast into space.

I've seen this happen too. I think it's related with the contour's starting point and the type of the previous node.

One thing that bugs me is that FLS has a problem with removing overlaps in some cases like an 'A': FLS seems to expect that in this case, both the 'arrow' and the 'dash' outlines follow the same direction -- but FLS's own function for setting outline directions to 'PS' turns one counter-clockwise, the other clockwise. Then removing overlaps fails. It is not safe to correct path direction and remove overlaps automatically. In so far I never trusted the last-minute removal of overlaps, but envy everyone who does it successfully.
(I really don't want to care for outline directions manually ...)

Karsten

There are definitely cases when keeping a glyph as separate parts has advantages when using multiple masters. A good example is a Q in which the tail crosses the bowl at an angle. When you go from the lightest to the boldest weight, you want the intersection of the tail and the bowl to follow the curve of the bowl. If you remove overlaps before interpolating, the intersection will follow a straight line between the two extremes, rather than the curve of the bowl:

The Q on the left was interpolated from separate parts; the Q on the right was interpolated from a continuous outline. Note the distortion in the area where the tail intersects the bowl.

In fact, anytime there is a change of angle or rotation between the extremes, you're going to have interpolation problems. There isn't always an adequate solution, but in some cases, having separate parts helps.

There is also the vastly superior Superpolator.

—K

One thing that bugs me is that FLS has a problem with removing overlaps in some cases like an ’A’: FLS seems to expect that in this case, both the ’arrow’ and the ’dash’ outlines follow the same direction — but FLS’s own function for setting outline directions to ’PS’ turns one counter-clockwise, the other clockwise. Then removing overlaps fails.

Yes, I have had that problem a few times. However, since I've been using AFDK macro's for setting contour directions I haven't seen it occur anymore. And ofcourse checking a print out of the complete charset for faulty overlaps is standard procedure.

Best,
Artur

Speaking of the AFDKO, one little known thing is that the CheckOutlines tool actually corrects the direction of the contours and removes overlaps. Just use the '-e' option like so,

checkoutlines -e font.pfa

Thanks for both tips! These are two parts of AFDKO which I haven't used so far.

I'm a big fan of using overlapping paths in MMs as ain intermediate step, and only removing overlap in the generated instances. It can avoid many sorts of interpolation problems. Mark's example is a good one, but there are many.

Cheers,

T

It is not safe to correct path direction and remove overlaps automatically..

No, it isn't. But if you do one manually, then you can safely do the other automatically. I personally prefer to do direction manually and remove overlaps automatically (since removing overlaps by hand is tricky, and maintaining direction is not).

Apparently the AFDKO does both, and correctly. I don't see how this can work always: I assume that it uses heuristics, and mostly guesses right. I'd be curious as to what that heuristic is, if it isn't an Adobe trade secret.

But if you do one manually, then you can safely do the other automatically.

Yes, another collegue made this point during a chat today. Still I'd prefer it if FLS would do the right thing automatically. A designer really shouldn't need to bother about path directions or closepaths or things like that, these are technical issues on the level of the font format to be generated. But I repeat myself, sorry.

Still I’d prefer it if FLS would do the right thing automatically.

I don't see how that's possible. The reason it doesn't do both automatically is that it's ambiguous. How does a program know how to resolve that ambiguity?

True. I have thought through a couple of examples since my last post. In most of them path directions could be corrected automatically, but there are cases which are indeed ambiguous, or put differently: where path direction is a design decision.