-
Notifications
You must be signed in to change notification settings - Fork 99
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
New family check: No styles in a font family (or VF) should have Agrave bounds that exceed hhea.ascent #3170
Comments
From the tests I have done, Mac OS only looks at |
I would like to take this as an opportunity to add more details to a v-metric check:
|
Yes to the above! I might also add...
Two challenges:
|
The challenges don’t suggest that we shouldn’t use these parameters, but more that the check should probably include an explanation of which kinds of fonts it applies to (and possibly result in a I believe the Noto project has different metric guidance for compact scripts (e.g. Latin) vs taller scripts (e.g. Arabic). |
Recommended 120%-130% of UPM size ? Should there be a recommended max?
True, although it works for greek and cyrillic which have same caps metrics as Latin. +1 for the skip if not-latin-greek-cyrillic focused. |
I've just made a quick test to test whether the Agrave is used to determine the positioning of the first line of text. Unfortunately, it isn't as simple as we hoped. In glyphsapp: Agrave glyph with lines drawn each spaced 100 units apart (starting at 1000 units) My custom Agrave is only displaying 3 lines, this means it's getting clipped at 1200 units. Perhaps the heuristic could be I'm using Big Sur so if someone could test this on an older version, I'd be most grateful. cc @RosaWagner |
I only see 3 in Mojave too |
Also, there is the test I have made to see how first base line is changing according to Agrave and typoAscender value. In 1-3: typoAscender=1000 And other test confirming the limits Marcs pointed out. |
Ensures the typoAscender is taller than the /Agrave. The check seems to be working well! I’ve tested it on: - An OTF font with an /Agrave that exceeds the typoAscender. It fails and provides a rationale. - An OTF font with an /Agrave that doesn’t exceed the typoAscender. It passes. - TTF fonts that do and do not fail. - OTF and TTF fonts that don’t include an /Agrave. It skips this successfully, and provides the reason if the --verbose arg is passed. EXPERIMENTAL - com.arrowtype.fonts/check/typoascender_exceeds_Agrave Added to Universal profile. (issue fonttools#3170)
Ensures the typoAscender is taller than the /Agrave. The check seems to be working well! I’ve tested it on: - An OTF font with an /Agrave that exceeds the typoAscender. It fails and provides a rationale. - An OTF font with an /Agrave that doesn’t exceed the typoAscender. It passes. - TTF fonts that do and do not fail. - OTF and TTF fonts that don’t include an /Agrave. It skips this successfully, and provides the reason if the --verbose arg is passed. EXPERIMENTAL - com.arrowtype.fonts/check/typoascender_exceeds_Agrave Added to Universal profile. (issue fonttools#3170)
Ensures the typoAscender is taller than the /Agrave. The check seems to be working well! I’ve tested it on: - An OTF font with an /Agrave that exceeds the typoAscender. It fails and provides a rationale. - An OTF font with an /Agrave that doesn’t exceed the typoAscender. It passes. - TTF fonts that do and do not fail. - OTF and TTF fonts that don’t include an /Agrave. It skips this successfully, and provides the reason if the --verbose arg is passed. EXPERIMENTAL - com.arrowtype.fonts/check/typoascender_exceeds_Agrave Added to Universal profile. (issue fonttools#3170)
Ensures the typoAscender is taller than the /Agrave. The check seems to be working well! I’ve tested it on: - An OTF font with an /Agrave that exceeds the typoAscender. It fails and provides a rationale. - An OTF font with an /Agrave that doesn’t exceed the typoAscender. It passes. - TTF fonts that do and do not fail. - OTF and TTF fonts that don’t include an /Agrave. It skips this successfully, and provides the reason if the --verbose arg is passed. EXPERIMENTAL - com.arrowtype.fonts/check/typoascender_exceeds_Agrave Added to Universal profile. (issue #3170)
Hey! I’ve been thinking on this check lately, and I have some questions |
Observed behaviour
For a long time, I struggled with arrowtype/recursive#308, wherein just a few styles of Recursive were given unexpected default line heights on macOS.
Last week, I discovered that this was due to Latin Basic (single-accent) uppercase characters exceeding the
hhea.ascent
value. When this was the case – as it was in my Linear ExtraBold sources (and therefore styles nearby) – macOS disregards the specified hhea values, and instead seems to use yMin & yMax values to determine default line height. In turn, this negatively affects the font usability in programs like Keynote & Sketch.Expected behaviour
FontBakery could use a check that:
hhea.ascent
is exceed by the yMax bound of any characters in Latin BasicSomething that might be challenging about this: how can we check for yMax in non-default instances of a variable font? Would this check have to calculate all deltas for instances? Is there any kind of quick way to do that?
Resources and exact process needed to replicate
This issue was discovered at v1.030 and existed up to v1.073. So, this can be reproduced with the variable and static fonts in any release of Recursive prior to v1.074, where it was fixed by making uppercase accents slightly shorter.
This issue exists on macOS Catalina (10.15) and to a slightly lesser extent macOS 11 Big Sur. (In Big Sur, it doesn’t happen in Sketch, but does occur in Keynote and presumably also other apps).
The text was updated successfully, but these errors were encountered: