Multiple Master question

Artur Schmal's picture

Hi all,

I've recently started working with MM technology in FL and there's a particular problem I'm running into which I haven't been able to solve, so I thought let's see if anyone here can help me with this.

In the attached picture you see a lowercase g with another master behind it.
Notice that a few points of the master in the background are being cast into space.
I have compared pointstructures, starting points, contour direction and the glyphs seem to be identical.

Any thoughts on this?

Best,
Artur

AttachmentSize
MM_g.png18.04 KB
Tim Ahrens's picture

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)?

Goran Soderstrom's picture

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

Artur Schmal's picture

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

Artur Schmal's picture

@ Goran:

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

@ Adam:

Thanks, will do that.

Tim Ahrens's picture

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.

Artur Schmal's picture

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

.00's picture

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

Artur Schmal's picture

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

Miguel Sousa's picture

> 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.

k.l.'s picture

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

Mark Simonson's picture

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.

kris's picture

There is also the vastly superior Superpolator.

—K

Artur Schmal's picture

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

Miguel Sousa's picture

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

k.l.'s picture

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

Thomas Phinney's picture

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

mr's picture

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.

k.l.'s picture

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.

mr's picture

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?

k.l.'s picture

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.

Syndicate content Syndicate content