- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Mar 2021 00:37:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `advance-override details`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: advance-override details<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5983<br> <myles> fantasai: We decided we wanted to add an advance-override descriptor to the @font-face rule, but we didnt' define what it actually does other htan to say it takes a percentage that's resovled agains the advance itself<br> <chris> q+<br> <myles> fantasai: A couple of points that would need to be resolved: 1. How are we increasing or decreasing the advance width? The size of the glyph in bohth axes together? Just x axis? Space around each glyph? left side? right side, start end, end end?<br> <myles> fantasai: There's been some discussion in the issue about what it should apply to and how it should apply, but no conclusions.<br> <myles> fantasai: I think the first thing we'd have to decide is how we increase the size of the glyphs<br> <myles> fantasai: to do text layout<br> <fantasai> myles: Shouldn't distort the outlines<br> <Rossen_> ack chris<br> <fantasai> chris: We're changing the advance, not the bounding box of the glyph. Not changing the outline<br> <fantasai> chris: just changing the amount you need to move forward<br> <myles> chris: We're changing the advance, not the bounding box of the glyphs, n or teh geometry. We're changing the amount you need to move forward before painting the next glyphs. Changing spacing in the text advance direction<br> <fantasai> chris: very clearly not changing any glyph geometry<br> <myles> chris: There's also a size override, but there's separate<br> <fantasai> chris: There is a proposal to have a scale factor, but that's separate<br> <fantasai> myles: I think that the exact way that space is added, I think that's not a super important decision, so doing whatever makes sense is easiest. For us that would be applying to the right side always<br> <fantasai> Rossen_: Is that affected by directionality?<br> <fantasai> myles: No, always on the right side<br> <fantasai> chris: Why?<br> <fantasai> myles: it's just easier to implement. Base-level API renders text LTR<br> <fantasai> chris: So you're saying you do bidi reordering in the backing store and then apply space after that?<br> <jfkthame> q+<br> <fantasai> Rossen_: So proposal is to keep it uniform on one side<br> <fantasai> jfkthame: I would not like to specify that space is only applied on one side<br> <fantasai> jfkthame: if that's easiest to apply, maybe allow it<br> <fantasai> jfkthame: but I don't think that's the best behavior<br> <fantasai> jfkthame: browser should be able to apply equally across both sides of glyph<br> <fantasai> jfkthame: which is superior<br> <Rossen_> ack jfkthame<br> <Rossen_> ack fantasai<br> <chris> I'm a bit concerned about margins not lining up, with space at the margins<br> <Rossen_> q<br> <fantasai> chris: could add space not at margins<br> <fantasai> myles: bleeds into my point. naive implementation is to just multiply the number in the font file<br> <fantasai> myles: but that applies before shaping<br> <fantasai> myles: when you apply shaping, have to match what's in the font file.<br> <fantasai> myles: Correct implementation of this needs to apply this after shaping<br> <fantasai> myles: which is a more complicated implementation<br> <fantasai> myles: doing something like what chris said is not hard, because you're already at the level of knowing that information<br> <fantasai> Rossen_: So sounds like we're aligning on adding space on both sides?<br> <fantasai> Rossen_: any other opinions? or resolve?<br> <fantasai> myles: If you do it on both sides, then alignment won't look good on either side<br> <fantasai> jfkthame: We're putting the space equally makes for a less-bad result than you will get than if it's all on one side<br> <fantasai> jfkthame: in practice, I don't think this is a feature that should be used for a large adjustment<br> <fantasai> jfkthame: it's for fine-tuning the metrics of a fallback font to match another font<br> <fantasai> jfkthame: so the adjustment is going to be a small fraction of a glyph width. Not too bad.<br> <fantasai> myles: I suggest leaving it undefined<br> <chris> we should put that wording from jfkthame into the spec - fine adjustments, not major ones. fine tuning<br> <fantasai> myles: Major point is that it makes text more/less compact<br> <fantasai> myles: Might be worth getting impl experience<br> <fantasai> jfkthame: Wrt trimming space at line boundaries, I'd be opposed.<br> <fantasai> jfkthame: This is effectively about modifying the metrics of the font<br> <fantasai> jfkthame: if you modify metrics of a glyph, should be everywhere that glyph occurs, not different based on position in the line<br> <Rossen_> ack fantasai<br> <TabAtkins> q+ to remind that we're trying to better solve a case where people are *already* doing letter-spacing<br> <astearns> AFAIK this feature is NOT about making things look good, it’s merely about reducing layout shift once a font loads<br> <fantasai> fantasai: Slight tangent, but<br> <fantasai> fantasai: This feature has a lot of badness to it<br> <fantasai> fantasai: First, as we've been discussing, it distorts alignment<br> <fantasai> fantasai: Second, it breaks complex and cursive writing systems<br> <fantasai> fantasai: Third, because it introduces uneven amounts of spacing between pairs of characters, it distorts the rhythm of the text and hence impacts readability in a negative way<br> <fantasai> fantasai: None of these problems apply if the font is scaled in both axes instead of adding space between characters<br> <fantasai> fantasai: And I think it would be harmful if we ship this feature without also shipping a scaling-factor descriptor that could be used in any cases where that would be usable in place of advance-override<br> <fantasai> jfkthame: Strongly agree with that.<br> <Rossen_> q?<br> <Rossen_> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to remind that we're trying to better solve a case where people are *already* doing letter-spacing<br> <xiaochengh> q+<br> <fantasai> TabAtkins: Keep in mind, the goal is not to define a new typographic feature for text. It's to replace existing hacks that people use to reduce layout shift when fonts load<br> <fantasai> TabAtkins: if we can reduce layout shift, even if it looks bad, still successful<br> <fantasai> TabAtkins: Want it to look good and make it work across writing systems<br> <fantasai> TabAtkins: but if not ideal, that's fine, because that's not the point<br> <fantasai> TabAtkins: should be for fonts that not there for very long, will be replaced by the real font later<br> <fantasai> TabAtkins: Want a solution that works across scripts and works OK, better than current hacks<br> <Rossen_> ack xiaochengh<br> <fantasai> xiaochengh: Regarding scaling / font-size override<br> <fantasai> xiaochengh: we have prototyped in Chrome, and found it tricky to nicely specify<br> <fantasai> xiaochengh: This might affect ascent-override etc.<br> <fantasai> xiaochengh: they have a %, which font-size do these resolve against? resolve against the font-size property value of the element or used font size?<br> <fantasai> xiaochengh: Either way going to surprise some users<br> <fantasai> xiaochengh: since our main focus is to reduce layout shift, wouldn't want to introduce a blocking issue on top of advance override<br> <TabAtkins> fantasai: To reply to TAb, I udnerstand this is for reducing layout shift<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: But there's different way to do that, and I think in many cases scaling outlines without affecting resolution of length units would also have that affect<br> <TabAtkins> fantasai: wrt using it as a fallback, what happens if the other font doesn't load<br> <TabAtkins> fantasai: This isn't "onlya pplies in a fallback font"<br> <TabAtkins> fantasai: People on slow connections, etc are stuck with a font that's not just non-ideal but also has weird spacing<br> <TabAtkins> fantasai: And this doesn't work for complex or cursive script as specified today.<br> <TabAtkins> fantasai: You can handle those scripts if you scale, not if you intro space.<br> <fantasai> TabAtkins: if your fallback font plus scaling advance looks terrible, you chose a bad fallback font<br> <fantasai> TabAtkins: we don't need to protect author from that. They should tweak it to be closer.<br> <fantasai> TabAtkins: If it is, it's a bad page.<br> <jfkthame> instead of `font-size-override`, suggest something like `glyph-scale-factor`, then it's clearer that it doesn't affect anything else<br> <fantasai> myles: What is the exist for this discussion? We've talked about several issues here.<br> <myles> s/exist/exit/<br> <fantasai> TabAtkins: Trying to figure out how to fix this for awhile<br> <myles> s/exit/exit criteria/<br> <fantasai> TabAtkins: keep getting objections that it's not ideal<br> <fantasai> TabAtkins: but nobody is helping making a better solution<br> <fantasai> TabAtkins: we did exploration with scaling, it doesn't lookg good<br> <fantasai> TabAtkins: maybe we need to scale on some scripts<br> <fantasai> TabAtkins: but essentially just letter-spacing works well<br> <fantasai> fantasai: letter-spacing applies evenly<br> <fantasai> fantasai: and if it's supposed to apply for temporary font, should shut off if you're not loading another font and sticking with this one<br> <fantasai> TabAtkins: but then you have a layout shift<br> <fantasai> fantasai: If downloading is turned off, then no layout shift<br> <fantasai> myles: rogue character with accent in the middle of a paragraph causes ...<br> <fantasai> Rossen_: Proposed path forward... not hearing a clear consensus around a) where the adjustment should take place or b) should we even have that<br> <fantasai> Rossen_: I think we resolve in backwards order<br> <TabAtkins> summary of myles: also useful if you have a fallback used for certain characters, which has an oddly different character size - this lets you adjust the fallback characters to feel better<br> <fantasai> Rossen_: First question, should we still pursue this?<br> <chris> OK so close this discussin with "needs proposal"?<br> <fantasai> fantasai: I can live with having this plus a scaling factor, but not having just this one, because if only have a broken option that's not good enough<br> <fantasai> myles: I think we should have both, changing scaling factor makes a lot of sense<br> <fantasai> TabAtkins: Not hearing any objections to what we're doing here, other than fantasai's point.<br> <fantasai> Rossen_: so no objection to continuing on this<br> <fantasai> Rossen_: So specific proposal here, fantasai mentioned adding scaling factor and then we have to decide where space is added<br> <fantasai> Rossen_: My proposal is to take back to the issue and iron it out there<br> <Rossen_> ack fantasai<br> <fantasai> fantasai: suggest to take a resolution on a) adding a scale-factor descriptor that only affects the glyph outline b) add space on both sides, maybe *allow* (MAY) UAs to do one side only if it's an implementation problem c) apply it to all glyphs in all writing systems, d) warn about how that can break things in certain writing systems / if too much space is added<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5983#issuecomment-790190011 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 March 2021 00:37:15 UTC