Manual TrueType instructions and alignment zones

I’ve been using the manual TT instructor for a variable font because TTFAutoHint does not yet (as far as I know) handle variable fonts. The manual instructor in Glyphs is a great tool, and it’s wonderful that Glyphs can instruct variable fonts, but I’ve run into a problem and am wondering if there’s a workaround.

When Glyphs generates TT instructions, it appears to handle alignment zones by generating two CVT entries, one for the bottom of the zone and one for the top. If a point is closer to the bottom of the zone, the first CVT entry is used, and if it’s closer to the top, the second is used. This is usually not a problem, if an alignment zone is no wider than it has to be, but sometimes it produces anomalies.

Here’s a test done in Illustrator, with some letters exactly at the font’s x-height (848) and some with overshoot (870). The letters with overshoot (nopac) have their tops aligned via a MIAP instruction with a CVT entry of 870; the others (uxyvw) have a CVT entry of 848. (The percentages are Illustrator’s zoom factor, and the type is 12pt: I’ve magnified the image to 200%. Sorry, I don’t know the pixels-per-em values.)

The top line is correct, and it’s what you mostly get. In the next two (114% and 134%), uxyvw are lower at a resolution where they ought to match nopac. At 143% there’s a truly bizarre effect, probably due to the 848 CVT entry being rounded up while the 870 entry is being rounded down.

Here’s my question. If I could, I would want the points in the x-height alignment zone for both uxyvw and nopac to use a single CVT entry so that you wouldn’t see these differences at low resolutions. Is there any way to do this?

(I’m using Glyphs version 2.6.2 (1257).

Can you send me the .glyphs file?

Thanks, Georg. I’ve sent a link.

I can’t reproduce this. Can you send me the .ttf file and the Illustrator file. Do you have a Retina screen? And what are the axis positions?

this is what I get with 12pt and 143%

and you should set all stems to not round and you don’t need most of the Anchors:


And the zone settings of the anchors is only meant to keep the distance of an accents to a zone.

Thanks again, Georg. I suppose I have a retina screen: it’s a recent (within the last six months) 15" MacBook Pro. I’m not sure I understand exactly what you mean by “axis positions.” Here are the axes:

  • wght 200-800
  • opsz 6-18
  • Grade 1-500

Masters at:

  • wght 200, opsz 18, Grade 1
  • wght 800, opsz 18, Grade 1
  • wght 200, opsz 6, Grade 1
  • wght 100, opsz 18, Grade 500

Regular is wght 420, opsz 12, Grade 1.

I have revised the instructions for u and n as you suggest (will revise the rest later) and copied over the TTFZones parameters to my current file (TTFZones are very cool! I missed them somehow).

Here is a sample of what I get:
I’ve added some u’s and n’s from Gentium on the right for comparison. At 99% (magnification in AI) I’m getting what I want, while at 106% my u’s and n’s seem to be jumping up and down.

I suppose things look different on different screens. In AI, if you put your cursor in the scale box at lower left and step up or down using the cursor keys, you may see the problem I’m talking about at several different sizes.

The overshoot is technically correct. You can control it with the TTFOvershootSuppressionBelowPPM parameter.

Another parameter I didn’t know about! (I see it was discussed in the announcement of v. 2.4.) This could be exactly what I’m looking for–but it seems to be working at the baseline, not the x-height:
Is this the intention?

it should work with all zones.

And it goes in the custom parameter set for the font, not the masters or instances?

I’m going to experiment with TTFOvershootSuppressionBelowPPM and correct my instructions, and if I can’t figure it out I’ll come back looking for more advice.

Thanks, Georg, for all your help!

Hm, that is currently a Font custom parameter. Is that optimal?
A Light instance certainly needs different overshoot suppression from a Black instance, and a zone for superiors needs different overshoot suppression than a zone for capitals.
So I think the OvershootSuppression should be a parameter of a zone, like in VTT.
In Calibri I built several overlapping zones, thin zones for rounded vertical stems, thick zones for rounded letters, each with their specific overshoot behavior. (2003, VTT)

This would be cool. I’m not absolutely sure I understand what’s going on in the prep and fpgm code, but it looks as if a function is being called once for each zone, to set the cvt entries for the top and bottom of the zone to be equal to each other. So in theory it ought to be possible to have a separate value for each zone.