Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further improve vertical typesetting #639

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

aaronbell
Copy link

@aaronbell aaronbell commented Nov 19, 2020

Currently the _is_vertical function checks if vertWidth or vertOrigin are not None in 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 like vert, vrt2, or vkna are 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-None value across the font).

Additionally, at current, without any values set in vertWidth or vertOrigin, the code sets the advancedWidth to be ascender-descender automatically. 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. So A.rotat should have a height equal to the width of A. This PR adds that as a secondary check, in case the value is not set explicitly.

Updated to check GSUB tables for vert use, and to correctly set the width of 'rotat' forms.
@m4rc1e
Copy link
Contributor

m4rc1e commented Nov 19, 2020

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?

@anthrotype
Copy link
Member

can you make a concrete example of a font intended for vertical typesetting where all vertWidth and vertOrigin are None?
That seems strange to me.

glyphsLib should only attempt to replicate what Glyphs.app does.

without any values set in vertWidth or vertOrigin, the code sets the advancedWidth to be ascender-descender automatically.

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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't the font developer simply set the vertWidth explicitly for these glyphs instead of relying on a magic suffix?

Copy link
Author

@aaronbell aaronbell Nov 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
@aaronbell
Copy link
Author

@m4rc1e Yes. It will export the vmtx table with nothing set in the vertOrigin or vertWidth (I'm testing in TTF).

@aaronbell
Copy link
Author

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

@aaronbell
Copy link
Author

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.

From my testing, Glyphs will generate a vmtx / VORG table based on the non rotated form if no vertWidth is set.

@m4rc1e
Copy link
Contributor

m4rc1e commented Nov 19, 2020

@m4rc1e Yes. It will export the vmtx table with nothing set in the vertOrigin or vertWidth (I'm testing in TTF).

I can confirm that the vmtx/VORG table is added when the feature vrt2 is present. When I tested the other two features, it didn't add the table.

@anthrotype
Copy link
Member

@schriftgestalt could you please chime in and shed some light on how Glyphs.app determines whether a particular font is intented for vertical typesetting?
Also, whether Glyphs.app gives any special treatment to glyphs whose name includes the suffix ".rotat"?

Base automatically changed from master to main February 17, 2021 12:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants