<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Further to what Jean-Baptiste has
written:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">There's an open item that ad hoc OT
working group has discussed a few times, which is a new version of
the BASE table that would allow for custom linespacing metrics to
be defined for OTL script and langsys tags, so the multiscript and
multilingual fonts could have different default linespacing
behaviour for different scripts (e.g. Latin vs Devanagari) or for
different languages (e.g. English vs Vietnamese).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Rather than defining additional metrics
alignment zones à la Latin cap height, x-height, etc. for a subset
of other scripts, and hoping that these are accurately set in
fonts so that they could be used by CSS to control vertical
spacing within text frames via leading-trim—I already have
concerns about the reliability of existing Latin metrics in fonts
for this purpose—, we have the opportunity to define explicit
metrics for these spacing alignment purposes, and also to link
them to script and langsys tags. I think we should spec the new
BASE table to include metric sets for interline spacing as well as
first-line trim and last-line trim. This extends the model to any
script and down to the language level, and also links the
properties to specific layout behaviour as proposed by CSS.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">JH<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:CAMjHz319A4F2f_jUNu0PPRGnK-gYWPYMbY-ffXBcmaV6wMV7Ug@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">www-style@w3.org</a> <a
href="https://lists.w3.org/Archives/Public/www-style/"
rel="noreferrer" target="_blank" moz-do-not-send="true">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"
moz-do-not-send="true">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec"
rel="noreferrer" target="_blank" moz-do-not-send="true">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"
moz-do-not-send="true">+33 (0)6 23 34 55 30</a><br>
w : <a href="http://phantom-foundry.com/"
target="_blank" moz-do-not-send="true">phantom-foundry.com</a><br>
e : <a href="mailto:jb@phantom-foundry.com"
target="_blank" moz-do-not-send="true">jb@phantom-foundry.com</a><br>
t : <a href="https://twitter.com/phantomfoundry"
target="_blank" moz-do-not-send="true">@phantomfoundry</a><br>
</span></span></div>
<div dir="ltr"><br>
</div>
<div dir="ltr">👻</div>
</span></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
mpeg-otspec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>
<a class="moz-txt-link-freetext" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
</pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
John Hudson
Tiro Typeworks Ltd <a class="moz-txt-link-abbreviated" href="http://www.tiro.com">www.tiro.com</a>
Salish Sea, BC <a class="moz-txt-link-abbreviated" href="mailto:tiro@tiro.com">tiro@tiro.com</a>
NOTE: In the interests of productivity, I am currently
dealing with email on only two days per week, usually
Monday and Thursday unless this schedule is disrupted
by travel. If you need to contact me urgently, please
use some other method of communication. Thank you.</pre>
</body>
</html>