Hello, I am looking for some guidance on best practices for vertical metrics in a multiscript project. Specifically, Arabic and Latin: What should typo/hhea values be set to? When I have both scripts in the same exports, should the vertical metrics be tuned to Latin, even though that means they will be very small for the Arabic?
Is a setup like this okay? (Yes, winAscent/Descent are set to englobe Arabic)
That is tricky business. The height of Arabic is difficult to predict (e.g. cursive attachment and marks can make for a very high ascender). The win descent is the worst …
I don’t know of a easy solution: You probably have to try a lot.
The typo/hhea metrics should be how you would like the default line spacing to be. In general, Arabic benefits from wider line spacing, but it also depends on the design and the kinds of texts it would generally be used with. A display design where people are unlikely to use it with fully vocalized text can get a way with tighter line spacing. I’d set a few different paragraphs with different kinds of texts (no vowel marks, some vowel marks, fully vocalized, etc), and see how it looks, and if you are not familiar with the script, then may be run it by someone who is.
There is GitHub - googlefonts/fontheight: Find out the vertical extents your font reaches on shaped words for calculating win metrics, but does not seem to have any releases yet.
Thanks for the insight. What happens, though, if it’s one single font, which contains Latin and Arabic? Really wide line spacing would look weird for Latin, while it would look fine for Arabic. Is there just no proper solution?
In this case you pick the line spacing that is suitable for the main use/script of the font, and let the users adjust line spacing manually for other uses (in my opinion, line spacing is a typographic choice and different uses/texts require different line spacing, so font author can only suggest a good default).
Another option, it to export two families, that are identical expect for the family name and the default line spacing. I sometimes do this for custom type so the client does not have to keep adjusting the line spacing manually when switching languages.
OpenType could make use of a per script/language line spacing, and BASE table can potentially be used for that, but no fonts do this AFAIK and no applications support it: Per-script/language vertical metrics · Issue #88 · harfbuzz/boring-expansion-spec · GitHub
These are great insights, thank you very much! I will discuss this with my client. Separating into subfamilies seems like the most sensible option.
I set the vertical metrics like this:
typo / hhea → for Latin uppercase + one level of marks above and below. This is my default line spacing / leading.
win → for highest (usually it’s a second level of upper Latin marks) and lowest (usually it’s a lower Arabic marks) coordinates.
Yes, of course (at least for win). That’s a technical requirement.
I do the same for typo/hhea: one level of marks above cap height (usually Aacute). Descender: at least designed descender depth, plus possible difference to (typoAscender - cap height), for vertically centered capitals.
