- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Sep 2020 16:45:22 +0000
- To: public-css-archive@w3.org
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> <dael> Topic: Interoperable font metrics<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4792<br> <dael> myles: There's this problem. Problem is font files have a bunch of different metrics and many conflict.<br> <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> <dael> myles: Some use metrics not even in the file. It's the wild west<br> <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> <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> <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> <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> <dael> myles: Satisfies constraints and gives consistency if authors use this. And if browser doesn't understand it falls back to font file.<br> <chris> q+ to wonder if Chrome is proposing or arguing against a descriptor<br> <xiaochengh> q+<br> <dael> myles: For problem at hand I think this is a fairly good design. Interested to hear thoughts.<br> <Rossen_> q?<br> <Rossen_> q+ TabAtkins<br> <Rossen_> ack chris<br> <Zakim> chris, you wanted to wonder if Chrome is proposing or arguing against a descriptor<br> <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> <Rossen_> ack xiaochengh<br> <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> <dael> chris: Does that only apply to these descriptors or also to previous descriptors?<br> <dael> chrishtr: Which did you have in mind?<br> <myles> q+ to talk about descriptors vs properties<br> <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> <dael> xiaochengh: Others aren't covered, should look independently<br> <faceless2> q+<br> <dael> chrishtr: In favor of adding the ones xiaochengh mentioned as well as asc one from myles<br> <TabAtkins> q-<br> <Rossen_> ack myles<br> <Zakim> myles, you wanted to talk about descriptors vs properties<br> <fantasai> strong +1 to using descriptors, strong -1 to using properties for this<br> <faceless2> q-<br> <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> <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> <florian> agreed, descriptors are a much better fit indeed.<br> <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> <dael> chris: Agree they're a better fit<br> <Rossen_> q?<br> <TabAtkins> q+<br> <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> <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> <xiaochengh> q+<br> <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> <florian> q+<br> <Rossen_> ack TabAtkins<br> <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> <dael> myles: Yeah, proposal from 8 days ago says it adds additional space. I don't think it satisfies the use case<br> <dael> TabAtkins: Would for monospace<br> <dael> myles: Not for font fallback<br> <dael> TabAtkins: Yes, if you know width of primary and fallback you add the space. Using override is unfortunate name<br> <Rossen_> ack xiaochengh<br> <dael> xiaochengh: proposal is add a constant to advance of glyph. I agree we should rename the descriptor.<br> <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> <dael> myles: We can open up a few issues<br> <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> <chris> Flashback to 1997 - all the widths in a descriptor https://www.w3.org/TR/WD-font-970721#widths :)<br> <myles> +1 to fantasai re:advance-override<br> <florian> +1<br> <dael> fantasai: On main prop for asc and desc it's fine. Had discussed similar for super and subscript metrics<br> <jfkthame> +1 here too<br> <fantasai> s/change.s/changes depending on the exact font/<br> <fantasai> s/ratio/ratio of advance widths for different letters/<br> <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> <florian> q-<br> <Rossen_> ack florian<br> <Rossen_> ack fantasai<br> <dael> Rossen_: Other comments? If not are we coming to resolution?<br> <dael> fantasai: Prop: add asc and desc and linegap-ooverride as fontface descriptors<br> <dael> myles: and they take %s<br> <dael> Rossen_: Objections?<br> <dael> chrishtr: sgtm<br> <dael> RESOLVED: Add ascent, descent, and lanegap override as fontface descriptors that take %<br> <fantasai> s/lanegap/line-gap/<br> <dael> fantasai: While we're on topic should we add the super and subscript variants<br> <faceless2> +1 from me on @fantasais additions<br> <dael> chrishtr: Sound interesting, want to look more<br> <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> <dael> chrishtr: Is there difference between OS and browsers?<br> <dael> fantasai: No, font metrics are frequently wrong<br> <fantasai> chrishtr, see example in https://www.w3.org/TR/css-fonts-4/#font-variant-position-prop<br> <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> <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