Further improve vertical typesetting #639
Conversation
Updated to check GSUB tables for vert use, and to correctly set the width of 'rotat' forms.
|
If you export a font from glyphsapp which has these OT features and doesn't have vertWidth or vertOrigin set, will it add a vmtx or VORG (cff) table? |
|
can you make a concrete example of a font intended for vertical typesetting where all vertWidth and vertOrigin are None? glyphsLib should only attempt to replicate what Glyphs.app does.
again that's what Glyphs.app does, as far as we know. If you don't like the default value, you should explicitly set vertWidth. That's exactly what it's for. |
| @@ -270,6 +270,8 @@ def to_ufo_glyph_height_and_vertical_origin(self, ufo_glyph, layer): | |||
|
|
|||
| if layer.vertWidth: | |||
| ufo_glyph.height = layer.vertWidth | |||
| elif "rotat" in ufo_glyph.name: | |||
There was a problem hiding this comment.
I've never heard of this "rotat" glyph name suffix. Is that your particular glyph naming scheme, or some new magic feature in Glyphs.app? I sincerely hope that's not the latter.
There was a problem hiding this comment.
From what I can tell, it is a common suffix for Japanese development using the AFDKO (Fontworks has it in its AFDKO sources). Yes, it does have 'magic feature' in Glyphs, but I do not believe it is exclusive to Glyphs.
There was a problem hiding this comment.
Furthermore, given that I've been reviewing fonts from 17 different foundries, and they have all used it when indicating rotated forms gives me confidence that it can be explicitly used :).
There was a problem hiding this comment.
can't the font developer simply set the vertWidth explicitly for these glyphs instead of relying on a magic suffix?
There was a problem hiding this comment.
I've provided you an example of a font that doesn't have vertWidth set, that clearly wants the font to be used for vertical typesetting, and has followed (what appears to be) a common convention for glyph naming in the Japanese type design industry.
All this code does is provide a safety net in case a designer does not set that field. It is really no different than setting it to ascender - descender. Do you deliberately want them to produce bad fonts?
There was a problem hiding this comment.
is this documented anywhere? How can we glyphsLib devs know that? The job of the tool is to try mimic what Glyphs.app does. If we can get confirmation from some authoritative source that that's indeed the case, we will certainly do what needs to be done (even though I do confess I personally dislike this kind of automatic features).
There was a problem hiding this comment.
TBH, I see this more as a fallback safety net than an automatic feature that someone would want to use—it'll always be better to set these values manually.
As for the documentation, I haven't seen any but what I have found in my own testing. One thing I did locate was this comment which seems to indicate the behavior I suggest:
If the glyph has a suffix “.rotat”, “.vert” or “.vrt2” and contains a component that is rotated by 90° the automatic alignment will position the component and set the vertWidth correctly.
https://forum.glyphsapp.com/t/how-to-make-rotat-glyphs-in-japanese-fonts/13014/4
But probably best to wait for Georg to confirm.
Forgot to add in the pass
|
@m4rc1e Yes. It will export the vmtx table with nothing set in the vertOrigin or vertWidth (I'm testing in TTF). |
|
@anthrotype Sure. Here: https://github.com/go108go/Chokokutai It has an example of vertical typesetting on the github page, has the vertical-specific opentype tables included, does not set vertOrigin or vertWidth. I think we need to keep in mind that just because a feature exists doesn't mean that someone necessarily knows how to use it, or needs to use it (like in the case of Cokokutai). |
From my testing, Glyphs will generate a vmtx / VORG table based on the non rotated form if no vertWidth is set. |
I can confirm that the vmtx/VORG table is added when the feature |
|
@schriftgestalt could you please chime in and shed some light on how Glyphs.app determines whether a particular font is intented for vertical typesetting? |
Currently the _is_vertical function checks if vertWidth or vertOrigin are not
Nonein the font to decide if the font is intended for vertical use. However, in many cases, I see those fields are not set, but GSUB features likevert,vrt2, orvknaare set in the font, indicating that the author intended the font to be used in vertical typesetting scenarios. This PR adds a check for any of those three GSUB features (and saves authors from having to set vertWidth or vertOrigin to a non-Nonevalue across the font).Additionally, at current, without any values set in vertWidth or vertOrigin, the code sets the advancedWidth to be
ascender-descenderautomatically. For rotated forms, indicated by the suffix.rotat, this is not workable—they will appear as full-width forms rather than proportional ones, as appropriate. Instead, they should be set to the width of the non-rotated glyph. SoA.rotatshould have a height equal to the width ofA. This PR adds that as a secondary check, in case the value is not set explicitly.