<div dir="ltr"><div>Hi Fantasai,</div><div>Thanks for bringing us in this quite interesting discussion. <br></div><div>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.<br></div><div>Speaking for myself I find the storage of the uppercase and xheight heights (sic) in top of the ascender/descender/lineGap very Latin oriented</div><div>(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).<br></div><div>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.</div><div>So in theory software should use only these ascender/descender/lineGap values, since they are the only common ones, <br></div><div>and are chosen by the font maker as the best way to make it work.</div><div>But since the values exist (sxHeight and sCapHeight), implementers have the habit of using them, <br></div><div>and I reckon that the idea of leading-trim seems quite smart and useful. <br></div><div>For "monoscript" fonts, the designer could <i>à la rigueur </i>cheat and put in this fields values that make leading-trim works.<br></div><div>But for multiscript fonts this hack would obviously not work.<br></div><div><br></div><div>So I guess there are 2 ways of addressing this issue:</div><div>- 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);</div><div>- 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<br>(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),<br>so "older" fonts that can't be updated with the new heights values could still work.</div><div><br></div><div>A precision: my advice is a type designer one, since I'm not a spec writer or a software engineer. <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 27 août 2020 à 08:52, fantasai <<a href="mailto:fantasai.lists@inkedblade.net">fantasai.lists@inkedblade.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">CSSWG requested additional metrics for the vertical bounds of writing systems <br>
other than Latin/CJK/Indic in its liaison statement from January 2020:<br>
<br>
<a href="https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf" rel="noreferrer" target="_blank">https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf</a><br>
I wanted to provide some background for this request.<br>
<br>
The context for this request is the CSS Inline Layout specification which is <br>
currently under development.<br>
Official draft: <a href="https://www.w3.org/TR/css-inline-3/" rel="noreferrer" target="_blank">https://www.w3.org/TR/css-inline-3/</a> # latest WG-approved<br>
Editor's draft: <a href="https://drafts.csswg.org/css-inline-3/" rel="noreferrer" target="_blank">https://drafts.csswg.org/css-inline-3/</a> # tip of tree<br>
Of particular interest would be the 'text-edge', 'leading-trim', and <br>
'initial-letter-align' properties: which control the spacing of text with <br>
respect to adjacent content; and the sizing and positioning of <br>
drop/raised/sunken caps or their equivalent in other writing systems. These <br>
depend on such font metrics.<br>
<br>
The corresponding CSSWG issue is<br>
<a href="https://github.com/w3c/csswg-drafts/issues/5244" rel="noreferrer" target="_blank">https://github.com/w3c/csswg-drafts/issues/5244</a><br>
<br>
For a video introduction to the CSS inline layout model and some of the <br>
problems we're trying to fix with it, see <br>
<a href="https://www.youtube.com/watch?v=OtlGo48iTOk" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=OtlGo48iTOk</a><br>
<br>
Also, Ethan Wang from Microsoft has written a blog post explaining the <br>
motivation for leading-trim, which might be useful (particularly as it has <br>
good illustrations):<br>
<br>
<a href="https://medium.com/microsoft-design/leading-trim-the-future-of-digital-typesetting-d082d84b202" rel="noreferrer" target="_blank">https://medium.com/microsoft-design/leading-trim-the-future-of-digital-typesetting-d082d84b202</a><br>
<br>
Fwiw, feedback on this specification is quite welcome... I imagine this group <br>
in particular would have useful insights on these sections which deal directly <br>
with font metrics, and which are a bit shaky atm:<br>
<a href="https://www.w3.org/TR/css-inline-3/#css-metrics" rel="noreferrer" target="_blank">https://www.w3.org/TR/css-inline-3/#css-metrics</a><br>
<a href="https://www.w3.org/TR/css-inline-3/#baseline-synthesis-fonts" rel="noreferrer" target="_blank">https://www.w3.org/TR/css-inline-3/#baseline-synthesis-fonts</a><br>
<br>
Issues can be filed in the CSSWG repo at<br>
<a href="https://github.com/w3c/csswg-drafts/issues" rel="noreferrer" target="_blank">https://github.com/w3c/csswg-drafts/issues</a><br>
-> or, if that is troublesome, by sending a message to the archived mailing <br>
list <a href="mailto:www-style@w3.org" target="_blank">www-style@w3.org</a> <a href="https://lists.w3.org/Archives/Public/www-style/" rel="noreferrer" target="_blank">https://lists.w3.org/Archives/Public/www-style/</a><br>
with "[css-inline-3]" as part of the subject line. (I can also take feedback <br>
directly myself, as the editor, if that's easier.)<br>
<br>
Also feel free to ask questions about the spec, I'm happy to answer either <br>
here or on some other channel as you like.<br>
<br>
Thanks for your consideration~<br>
~fantasai<br>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><span style="font-family:Calibri,sans-serif;line-height:normal"><div dir="ltr"><span style="color:rgb(61,133,198);font-size:x-small">++<br>Jean-Baptiste Morizot<br><br></span><div><span style="color:rgb(11,83,148)"><span style="font-size:x-small">type design & font engineering<br></span></span></div>
<span style="color:rgb(11,83,148)"><span style="font-size:x-small"><a href="tel:%2B33%20%280%296%2023%2034%2055%2030" value="+33623345530" target="_blank">+33 (0)6 23 34 55 30</a><br>w : <a href="http://phantom-foundry.com/" target="_blank">phantom-foundry.com</a><br>
e : <a href="mailto:jb@phantom-foundry.com" target="_blank">jb@phantom-foundry.com</a><br>t : <a href="https://twitter.com/phantomfoundry" target="_blank">@phantomfoundry</a><br></span></span></div><div dir="ltr"><br></div><div dir="ltr">👻</div></span></div></div>