Re: [csswg-drafts] Interoperable font metrics (#4792)

The CSS Working Group just discussed `Interoperable font metrics`, and agreed to the following:

* `RESOLVED: Add ascent, descent, and lanegap override as fontface descriptors that take %`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Interoperable font metrics<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4792<br>
&lt;dael> myles: There's this problem. Problem is font files have a bunch of different metrics and many conflict.<br>
&lt;dael> myles: Most egregious is there are 3 different asc and desc metrics in open type font files. All different numbers. Some browsers use some, others use others.<br>
&lt;dael> myles: Some use metrics not even in the file. It's the wild west<br>
&lt;dael> myles: This is an interesting problem b/c all text is rendered with whatever metrics the browser happens to use. Any solution that's browser Y should switch is a pretty scary change. It changes all text on the web. So I think it's nto a good solution<br>
&lt;dael> myles: Looked for better. A few design principles I wanted to abide by. All text should not be changes. Browsers should not have to parse font files themselves, they should be able to delegate to lower level libraries.<br>
&lt;dael> myles: Last is that we don't want to have different metrics for some properties than others. If we do that you end up with inconsistent typography and poor design<br>
&lt;dael> myles: Given those requirements I think best way to solve is for CSS authors in CSS to override metrics inside font file. The mechanism for doing this is a new descriptor or set of descriptors in font-face block. A css author can override the font file metrics and say please instead use 80%em for asc.<br>
&lt;dael> myles: Satisfies constraints and gives consistency if authors use this. And if browser doesn't understand it falls back to font file.<br>
&lt;chris> q+ to wonder if Chrome is proposing or arguing against a descriptor<br>
&lt;xiaochengh> q+<br>
&lt;dael> myles: For problem at hand I think this is a fairly good design. Interested to hear thoughts.<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> q+ TabAtkins<br>
&lt;Rossen_> ack chris<br>
&lt;Zakim> chris, you wanted to wonder if Chrome is proposing or arguing against a descriptor<br>
&lt;dael> chris: Reading thread I'm puzzled. I see people from chrome saying they don't want descriptors and existing ones should be removed. See others from chrome proposing descriptors. I appreciate opinions can change but would like to know their current opinion.<br>
&lt;Rossen_> ack xiaochengh<br>
&lt;dael> xiaochengh: From chrome side we do want descriptors. Earlier comment opposing was mostly from impl side. We've prototyped the descriptors behind a flag so impl isn't an issue.<br>
&lt;dael> chris: Does that only apply to these descriptors or also to previous descriptors?<br>
&lt;dael> chrishtr: Which did you have in mind?<br>
&lt;myles> q+ to talk about descriptors vs properties<br>
&lt;dael> chris: Dominic pointed to other issues saying removed font-varient and would like to remove other overrides. Basically, are you now happy with these or still look at removing?<br>
&lt;dael> xiaochengh: Others aren't covered, should look independently<br>
&lt;faceless2> q+<br>
&lt;dael> chrishtr: In favor of adding the ones xiaochengh mentioned as well as asc one from myles<br>
&lt;TabAtkins> q-<br>
&lt;Rossen_> ack myles<br>
&lt;Zakim> myles, you wanted to talk about descriptors vs properties<br>
&lt;fantasai> strong +1 to using descriptors, strong -1 to using properties for this<br>
&lt;faceless2> q-<br>
&lt;dael> myles: Talk directly about descriptor vs property. Descriptors are a direct natural fit to way metrics are handled by browsers. When you use a font face you have a font associated. Way to impl this is when you pull out metrics remove that and slot in from the rule.<br>
&lt;chris> I agree that descriptors seem like a good fit here, beter than propoerties as Myles said. I just didn't want a solution tht had been argued against in the past.<br>
&lt;florian> agreed, descriptors are a much better fit indeed.<br>
&lt;dael> myles: If we wanted to move to property not against but tricky problems like how does font fallback work if you have nested element with different font family. Multiplier on font size? A bunch of questions. If we can answer that's fine but descriptor approach means we don't have to.<br>
&lt;dael> chris: Agree they're a better fit<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> q+<br>
&lt;dael> myles: I can also talk about the 2 additional descriptors from xiaochengh. line gap amkes a lot of sense. Advanced override I'm not against but unanswered questions about how interacts with letter-spacing. Letter-spacing is not a simple property.<br>
&lt;dael> myles: Would be unfortunate if we had 2 ways of effecting letter-spacing and they worked differently. So there's still some design work for that one. line-gap-override makes sense<br>
&lt;xiaochengh> q+<br>
&lt;dael> TabAtkins: There is 2 separate mechnically things to do that are letter-sapcing like. Advance-override solves making sure monospace isn't screwed up with fallback. You want to effect advance of a letter to make sure they have exact width of primary font.<br>
&lt;florian> q+<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;dael> TabAtkins: Nothing to do with variable width fonts. That wants to be more like letter-spacing so you don't have awkward spaces. Have to be different and separate. advance-override which is make monospace work with fallback is straightforward<br>
&lt;dael> myles: Yeah, proposal from 8 days ago says it adds additional space. I don't think it satisfies the use case<br>
&lt;dael> TabAtkins: Would for monospace<br>
&lt;dael> myles: Not for font fallback<br>
&lt;dael> TabAtkins: Yes, if you know width of primary and fallback you add the space. Using override is unfortunate name<br>
&lt;Rossen_> ack xiaochengh<br>
&lt;dael> xiaochengh: proposal is add a constant to advance of glyph. I agree we should rename the descriptor.<br>
&lt;dael> xiaochengh: At this moment problem with variable width font is value of this descriptor has to be tried manually. Agree there's a design issue but we do want this descriptor<br>
&lt;dael> myles: We can open up a few issues<br>
&lt;dael> fantasai: I strongly want advance-override to be in a separate issue. Needs to be discussed in more detail. Monospace case also has a bunch of considerations. Not sure why adding a fixed value is right because ratio change.s It's a crude fixup.<br>
&lt;chris> Flashback to 1997 - all the widths in a descriptor https://www.w3.org/TR/WD-font-970721#widths :)<br>
&lt;myles> +1 to fantasai re:advance-override<br>
&lt;florian> +1<br>
&lt;dael> fantasai: On main prop for asc and desc it's fine. Had discussed similar for super and subscript metrics<br>
&lt;jfkthame> +1 here too<br>
&lt;fantasai> s/change.s/changes depending on the exact font/<br>
&lt;fantasai> s/ratio/ratio of advance widths for different letters/<br>
&lt;dael> chrishtr: Agree we should split advance-override. I think this is appropriate to 2nd use case from xiaochengh more than the original one brought by myles. Split and continue to discuss<br>
&lt;florian> q-<br>
&lt;Rossen_> ack florian<br>
&lt;Rossen_> ack fantasai<br>
&lt;dael> Rossen_: Other comments? If not are we coming to resolution?<br>
&lt;dael> fantasai: Prop: add asc and desc and linegap-ooverride as fontface descriptors<br>
&lt;dael> myles: and they take %s<br>
&lt;dael> Rossen_: Objections?<br>
&lt;dael> chrishtr: sgtm<br>
&lt;dael> RESOLVED: Add ascent, descent, and lanegap override as fontface descriptors that take %<br>
&lt;fantasai> s/lanegap/line-gap/<br>
&lt;dael> fantasai: While we're on topic should we add the super and subscript variants<br>
&lt;faceless2> +1 from me on @fantasais additions<br>
&lt;dael> chrishtr: Sound interesting, want to look more<br>
&lt;dael> fantasai: Briefly, font has metrics on amount to shipt up/down for super/subscript and says what size as function of font size. If font provides a glyph it's supposed to provide ones that match. If you don't have glyph UA can synth by resizing. IN order to get that to match you need metrics and a lot of fonts don't have<br>
&lt;dael> chrishtr: Is there difference between OS and browsers?<br>
&lt;dael> fantasai: No, font metrics are frequently wrong<br>
&lt;fantasai> chrishtr, see example in https://www.w3.org/TR/css-fonts-4/#font-variant-position-prop<br>
&lt;dael> Rossen_: This is very much related but I would prefer we open a new issue where more thought can be given. fantasai can you open that?<br>
&lt;dael> fantasai: Yep<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-693528301 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 16 September 2020 16:45:29 UTC