[MPEG-OTSPEC] CSS context for metrics request

[Jean-Baptiste Morizot]

Hi Fantasai,
Thanks for bringing us in this quite interesting discussion.
Metrics are a notorious issue in fonts. They are stored multiple times, in
a different way each time. I guess you already know about this.
Speaking for myself I find the storage of the uppercase and xheight heights
(sic) in top of the ascender/descender/lineGap very Latin oriented
(the simple idea of specifying the UC height to indicate the difference
between base letters and letters with diacritics focus clearly on
Latin/Greek/Cyrillic).
Writing systems that do not work the same way are completely left outside,
and softwares can rely only on the ascender/descender/lineGap for them.
So in theory software should use only these ascender/descender/lineGap
values, since they are the only common ones,
and are chosen by the font maker as the best way to make it work.
But since the values exist (sxHeight and sCapHeight), implementers have the
habit of using them,
and I reckon that the idea of leading-trim seems quite smart and useful.
For "monoscript" fonts, the designer could *à la rigueur *cheat and put in
this fields values that make leading-trim works.
But for multiscript fonts this hack would obviously not work.

So I guess there are 2 ways of addressing this issue:
- one idea would be to have more entries and more height values, one per
groups of writing systems (even CJK and Indic could use more precise values
than sCapHeight);
- the other would be to keep the spec as they are and let the softwares do
complex math calculation to find the average maximum height per unicode
block
(or one can define a default letter that gives the top height for each
script, like Illustrator does in latin with letter D if I'm right),
so "older" fonts that can't be updated with the new heights values could
still work.

A precision: my advice is a type designer one, since I'm not a spec writer
or a software engineer.

Le jeu. 27 août 2020 à 08:52, fantasai <fantasai.lists at inkedblade.net> a
écrit :

> CSSWG requested additional metrics for the vertical bounds of writing
> systems
> other than Latin/CJK/Indic in its liaison statement from January 2020:
>
>
> https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf
> I wanted to provide some background for this request.
>
> The context for this request is the CSS Inline Layout specification which
> is
> currently under development.
> Official draft: https://www.w3.org/TR/css-inline-3/    # latest
> WG-approved
> Editor's draft: https://drafts.csswg.org/css-inline-3/ # tip of tree
> Of particular interest would be the 'text-edge', 'leading-trim', and
> 'initial-letter-align' properties: which control the spacing of text with
> respect to adjacent content; and the sizing and positioning of
> drop/raised/sunken caps or their equivalent in other writing systems.
> These
> depend on such font metrics.
>
> The corresponding CSSWG issue is
>    https://github.com/w3c/csswg-drafts/issues/5244
>
> For a video introduction to the CSS inline layout model and some of the
> problems we're trying to fix with it, see
> https://www.youtube.com/watch?v=OtlGo48iTOk
>
> Also, Ethan Wang from Microsoft has written a blog post explaining the
> motivation for leading-trim, which might be useful (particularly as it has
> good illustrations):
>
>
> https://medium.com/microsoft-design/leading-trim-the-future-of-digital-typesetting-d082d84b202
>
> Fwiw, feedback on this specification is quite welcome... I imagine this
> group
> in particular would have useful insights on these sections which deal
> directly
> with font metrics, and which are a bit shaky atm:
>    https://www.w3.org/TR/css-inline-3/#css-metrics
>    https://www.w3.org/TR/css-inline-3/#baseline-synthesis-fonts
>
> Issues can be filed in the CSSWG repo at
>    https://github.com/w3c/csswg-drafts/issues
> -> or, if that is troublesome, by sending a message to the archived
> mailing
> list www-style at w3.org https://lists.w3.org/Archives/Public/www-style/
> with "[css-inline-3]" as part of the subject line. (I can also take
> feedback
> directly myself, as the editor, if that's easier.)
>
> Also feel free to ask questions about the spec, I'm happy to answer either
> here or on some other channel as you like.
>
> Thanks for your consideration~
> ~fantasai
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>


-- 
++
Jean-Baptiste Morizot

type design & font engineering
+33 (0)6 23 34 55 30
w : phantom-foundry.com
e : jb at phantom-foundry.com
t : @phantomfoundry <https://twitter.com/phantomfoundry>

👻
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200828/56e6903a/attachment.html>