[MPEG-OTSPEC] CSS context for metrics request
John Hudson
john at tiro.ca
Fri Aug 28 18:36:46 CEST 2020
Further to what Jean-Baptiste has written:
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).
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.
JH
> 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
> <mailto: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 <mailto: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 <mailto: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 <tel:%2B33%20%280%296%2023%2034%2055%2030>
> w : phantom-foundry.com <http://phantom-foundry.com/>
> e : jb at phantom-foundry.com <mailto:jb at phantom-foundry.com>
> t : @phantomfoundry <https://twitter.com/phantomfoundry>
>
> 👻
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
--
John Hudson
Tiro Typeworks Ltd www.tiro.com
Salish Sea, BC tiro at tiro.com
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200828/a6a66bc0/attachment.html>
More information about the mpeg-otspec
mailing list