Just lately I learned how vertical metrics (hhea, OS/2, win) work, so I have no comparison, but might it be that Microsoft Word for Mac 2019 (16.26 … today’s update) changed how the clipping works? According to the tutorial and some forum posts I presumed that the clipping is only applied by winAscent and winDescent. For my font I applied a strategy based on the webfont strategy with deviant typoLineGap and hheaLineGap. In Word the descenders still were clipped. The same happens to an Adobe font I installed. Is Microsoft (ever or since Word 16.26?) only supporting correct vertical metrics displaying for their own strategy? Or did I do something wrong? Now, how do I decide which strategy I should use? Thanks!
If you use the Use Typo Values parameter, Word may clip at the OS/2 values. And on the Mac, it may clip at hhea or OS/2 depending on which display mode (page versus web) you are using.
Give your hhea and OS/2 values a bit more padding. And make sure you avoid cache problems when you test.
If by “padding” you only mean the “line gap”, that does not work on my system, because in Word it is only added above the ascender.
Regardless, I wonder because in the tutorial’s “The OS/2 typo Values” section you describe the “UPM dogma”, then in the “The Webfont Strategy, more general” section you say “Do not worry if the sum of ascender and descender is more than 1000.”. What happens if I don’t stick to the specs stipulation? In Word, TextEdit and InDesign I don’t experience any problems. The UPM dogma paragraph reads very worrisome, when in the end it does not have any relevance.
Right now I’d say for typoDescender I better use the descender including overshoot and for typoAscender the UPM plus (the negative) typoDescender. In Word 2019 the ascender is only clipped at the ascender+linegap height (with Use Typo Metrics parameter).
Which part reads misleading for you? I think you got the gist of it just right, because you summed up exactly what is written in the tutorial: The spec stipulates it, but in modern software, you can go beyond it and won’t run into grave issues.
In recent discussions, the ‘UPM dogma’ (the spec requirement that typoAscender and typoDescender add up to the UPM) has been under fire, especially for complex non-Latin scripts. One of the proponents of letting go of the UPM dogma is Victor Gaultney from SIL, who wrote both Best Practice: Design Metrics and Best Practice: Line Metrics.
Of course, what I cannot do is foresee software development in the years to come, but for now, the major renderers seem to tolerate it. In any event, you will need to test, test, test.
In bigger projects we have frequently found bugs or inconsistencies in implementations and had to come up with workarounds, or had to deal with backwards compatibility issues, where we could not change certain values (because, e.g., it would jeopardise rendering in old versions of Word), but would still have to fit in new requirements.
Thanks! That’s calming.
When I read “the spec stipulates” I thought that (in modern software) something will not be working if I ignore it. But maybe it was the “that’s going to make things complicated” that triggered me.