Missing vhea, vmtx and VORG tables

[justvanrossum]

When doing vertical layout using harfbuzz, I notice that the vertical advances are all the same (1000). Vertical kerning works, but the vertical spacing is too wide, and uneven for glyphs that have accents.

Is this to be expected?

This should be fixable by adding vhea, vmtx and VORG tables. Maybe a 2020 update would be a nice project? @davelab6? 😊

[djrrb]

Thanks for the message, @justvanrossum!

No, this is not to be expected. :-)

The vertical spacing information is included in the vpal features, which is the way I found that worked with Adobe Illustrator’s vertical type tool. Here’s the intended appearance:

(Note that the final line in Bungee shade is set with an Opaque white Regular layer to manage the Aring overlap...the hollow counters issue in the basic Shade is kind of a separate unresolved issue)

Do you happen to know why the vpal feature would be recognized by Illustrator but not by harfbuzz?

If you believe that vhea, vmtx, and VORG tables are a better solution, do you have an implementation of these tables that you could recommend I use as an exemplar? Thanks again!

[justvanrossum]

Ahh, turning on vpal fixes it. It seems vpal is off by default in harfbuzz (as is vkrn).

But yes, I think it would be better if the vertical advances (and origins) are the right ones to begin with, instead of having them "touched up" by vpal. (The way I read the vpal description is that its main use is for CJK fonts, which by default are vertically monospaced, but can have optional proportional behavior via vpal. I don't think this should be optional for Bungee.)

UFO3 supports these settings (with http://unifiedfontobject.org/versions/ufo3/glyphs/glif/#advance and the public.verticalOrigin lib key), and I'm fairly sure fontmake will generate vhea,vmtx and VORG if they're used. Not sure about RF, but I doubt it.

How to conveniently edit them is another story, but given you have all the necessary information available in vpal, it should be possible to convert this to advance height + vertical origin info.

[justvanrossum]

(Btw. VORG is only needed for otf, for ttf vmtx is enough, where the top-sidebearing will imply the vertical origin, using the yMax value of the bounding box.)

[justvanrossum]

One more thing: only the otfs work correctly with harfbuzz (when turning on vpal), but not the ttfs. With ttf it seems to line up all glyphs by their bounding boxes, whereas with otf it seems to take the (typo)ascender value as the vertical reference. That seems inconsistent and arbitrary, but I don't think it's well specified what should happen in the absence of vhea and vmtx.

[justvanrossum]

I made a messy little script that takes your vpal.fea file, a source ttf or otf, and adds vhea, vmtx and VORG tables to the font.

I have attached the result of running this on Bungee-Regular.ttf from the Bungee_Basic folder. And the script itself, which contains hard-coded paths, so needs tweaking before you can run it.

The resulting ttf behaves perfectly with harfbuzz, without the need for vpal, and works identical to the (unchanged) otf version with vpal on.

Bungee-Regular-vmtx.ttf.zip
add_vmtx.py.zip

[justvanrossum]

I just checked the spec: VORG should only be added for CFF-based otf.

[djrrb]

Just, you are the best! 🙌

Thanks so much for putting together this script so I can see how the tables are supposed to look.

I’ll be happy to integrate the contents of this script into the build process so that the work is done by the vhea, vmtx and VORG tables (VORG for CFF only) instead of the vpal feature.

Leaving this issue open until I get around to it...

[justvanrossum]

No problem! Ideally your vpal data should be incorporated into the source UFOs as glyph.height and glyph.lib["public.verticalOrigin"] values. But if you wait long enough, maybe you can use unified-font-object/ufo-spec#95 :)