Note that the CSS Fonts 4 spec *requires* the browser to synthesize appropriate scaled/shifted glyphs if the font does not provide them:
> In the case of OpenType fonts that lack subscript or superscript glyphs for a given character, user agents *must* synthesize appropriate subscript and superscript glyphs. (see https://drafts.csswg.org/css-fonts-4/#font-variant-position-prop) On Tuesday, 4 July 2023 at 18:23:14 UTC+1 Munira Tursunova wrote: > We decided to ship font-variant-position without adding a metric measuring > whether the feature is applied against a correct font because of > difficulties determining a stable document state at the shaping level, for > details, see > https://docs.google.com/document/d/1dYiljb9pJmWtEIulsse_jzxJwLh3F14Y_X6WbHfETXg/edit?usp=sharing&resourcekey=0-6TIx4OqLWmKBuzv3yR-qRA > . > > On Wednesday, May 31, 2023 at 5:39:03 PM UTC+2 Daniel Bratell wrote: > >> LGTM3 >> >> /Daniel >> On 2023-05-31 17:38, Mike Taylor wrote: >> >> LGTM2 >> On 5/31/23 10:30 AM, Rick Byers wrote: >> >> Yes, 100%. Very good point, I was definitely over-simplifying the >> measurement challenge. Thanks David! >> >> On Tue, May 30, 2023, 5:47 p.m. David Baron <[email protected]> wrote: >> >>> I was trying to avoid being too specific about what would be worth >>> measuring both because I haven't taken the time to think through all the >>> details, and because other folks on this thread have a lot of domain >>> expertise that can help figure out what makes sense. I just wanted to >>> point out that if you are measuring stuff, it's worth considering that it >>> may be useful to measure something about usage of system versus downloaded >>> fonts in order to understand variation between machines (which I agree is >>> at least mostly variation between platforms). >>> >>> -David >>> >>> On Tue, May 30, 2023 at 11:44 AM Dominik Röttsches <[email protected]> >>> wrote: >>> >>>> Hi David and Rick, >>>> >>>> It's a shame to me to be holding back interop on the case of fonts >>>>> having the superscript or subscript glyphs out of fear for the case where >>>>> they don't. Perhaps we can treat the case of font-variant-position being >>>>> used with fonts that lack the glyphs as a site bug that we can work to >>>>> address independently? Personally, as long as Safari and Chrome behave >>>>> the >>>>> same here, I'm skeptical that the lack of synthesis would turn into a >>>>> non-trivial problem in practice. >>>> >>>> >>>> I think expectations as to what should the browser do vs. what is >>>> reasonably expected of site owners in terms of font selection and visual >>>> delivery is on a spectrum (font fallback being a similar case). >>>> In the case of using font-variant-position, I tend to agree with Rick: >>>> I'd consider using font-variant-position without a suitable font is a site >>>> bug. Safari seems to be of the same opinion by shipping >>>> font-variant-position without synthesis. >>>> >>>> If we were to ship without synthesis, would it be practical to have a >>>>> UseCounter which measures how often we see font-variant-position used >>>>> with >>>>> a font that lacks the glyphs? This would tell us how important the bug >>>>> is. >>>>> If it remains really rare, then IMHO we've probably already wasted more >>>>> energy worrying about it than it's worth. If it becomes more common over >>>>> time then I think we have a variety of options, chiefly implementing >>>>> synthesis, but also raising awareness with devtools features, UKM-based >>>>> site-specific outreach, and possibly even interventions of some form >>>>> (like >>>>> using a fallback font?). >>>> >>>> >>>> It's difficult to measure the visual end result accurately: >>>> Only at shaping time we know exactly which font binary is used. This in >>>> HarfBuzzShaper and we can determine whether the `sups` and `subs` >>>> OpenType features >>>> <https://learn.microsoft.com/en-us/typography/opentype/spec/features_pt#subs> >>>> are >>>> requested (we would need extra code for determining whether these features >>>> were requested through font-variant-position: or font-feature-settings). >>>> Then we can determine whether the font has such a feature in its shaping >>>> tables. The difficulty is: We reach the shaping code lots of times for >>>> every relayout or web font arriving. So initially, we may shape with a >>>> fallback font before the web font arrives, which affects the measurement >>>> result. Measuring in shaping is not synchronized with a stable layout >>>> stage >>>> or something like a "done" state of the page. So we could get to an >>>> approximation, but in shaping we can't currently determine what's the last >>>> state that "stayed" and was perceived by the user. >>>> >>>> David wrote: >>>> >>>>> So if it makes sense to add use counters to understand the >>>>> compatibility implications here, I think it may be worth adding what we >>>>> would need to understand the breakdown of how many sites are using this >>>>> in >>>>> a way that (a) is interoperable across browsers/machines versus (b) is >>>>> broken in some browsers and working on others versus (c) is broken on >>>>> some >>>>> machines and working on other machines, even using the same browser. I >>>>> suspect this would mean something like measuring how often we see >>>>> font-variant-position used with a system font versus a downloadable font. >>>>> >>>>> (This might also need to be recorded along with the data on whether the >>>>> font has or lacks the superscript/subscript glyphs, because the >>>>> intersection of the two might be interesting.) >>>> >>>> >>>> I do agree this feature is most meaningful in combination with web >>>> fonts. Or even more specifically: Selecting font-variant-position needs to >>>> be carefully synced with the selected font and making sure the exact font >>>> has high chances of getting loaded. >>>> Do I understand correctly you suggest measuring font-variant-position >>>> usage with system fonts vs. web fonts because of the differences between >>>> machines? Or did you also mean platforms? >>>> The system font set used from the web is relatively stable between >>>> machines, meaning: Windows fonts are usually similar across machines (when >>>> it comes to those selected from the web), so are Mac fonts. >>>> >>>> In any event, I did a quick check: >>>> Mac: Helvetica, Times, and Courier New on Mac, and as far as I can >>>> tell, neither has a specific superscript or subscript OpenType or AAT font >>>> feature. >>>> Windows: Out of Arial, Courier, Times, Verdana only Verdana has >>>> subscript glyphs (no superscript), the others do not have such a feature. >>>> >>>> Bottom line: >>>> I am with Rick on shipping this and considering a lack of glyph support >>>> up a site bug. >>>> Depending on feedback from API owners, if needed, we can measure an >>>> approximation of selection of the feature vs. support in the font. >>>> >>>> As is, this measurement may read too high (see above: initial shaping >>>> with fallback font), but potentially we can filter that measurement and >>>> only report selection of the feature vs. support in a successfully loaded >>>> web-font. Development of such a measurement takes from 2 days to 9 days, >>>> depending on complexity (very basic, no distinction of >>>> font-feature-settings and font-variant-position, no distinction of system >>>> fonts to complex: distinguish font-feature-settings from >>>> font-variant-position, distinguish system fonts, web fonts). >>>> >>>> >>>> Dominik >>>> >>>> >>>> >>>> On Wed, May 24, 2023 at 5:41 PM Rick Byers <[email protected]> wrote: >>>> >>>>> It's a shame to me to be holding back interop on the case of fonts >>>>> having the superscript or subscript glyphs out of fear for the case where >>>>> they don't. Perhaps we can treat the case of font-variant-position being >>>>> used with fonts that lack the glyphs as a site bug that we can work to >>>>> address independently? Personally, as long as Safari and Chrome behave >>>>> the >>>>> same here, I'm skeptical that the lack of synthesis would turn into a >>>>> non-trivial problem in practice. >>>>> >>>>> If we were to ship without synthesis, would it be practical to have a >>>>> UseCounter which measures how often we see font-variant-position used >>>>> with >>>>> a font that lacks the glyphs? This would tell us how important the bug >>>>> is. >>>>> If it remains really rare, then IMHO we've probably already wasted more >>>>> energy worrying about it than it's worth. If it becomes more common over >>>>> time then I think we have a variety of options, chiefly implementing >>>>> synthesis, but also raising awareness with devtools features, UKM-based >>>>> site-specific outreach, and possibly even interventions of some form >>>>> (like >>>>> using a fallback font?). >>>>> >>>>> Rick >>>>> >>>>> On Fri, Feb 24, 2023 at 9:22 AM David Baron <[email protected]> >>>>> wrote: >>>>> >>>>>> On Fri, Feb 24, 2023 at 5:49 AM Yoav Weiss <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> On Fri, Feb 24, 2023 at 11:27 AM Manuel Rego Casasnovas < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> There's a CSSWG issue about this topic in particular: >>>>>>>> https://github.com/w3c/csswg-drafts/issues/7441 >>>>>>> >>>>>>> >>>>>>> Is this something that can be put on the agenda for the CSSWG to >>>>>>> discuss? >>>>>>> >>>>>> >>>>>> I added this to the group's (long) agenda backlog. >>>>>> >>>>>> (Also, a few other relevant CSSWG issues I found were >>>>>> w3c/csswg-drafts#1888 >>>>>> <https://github.com/w3c/csswg-drafts/issues/1888>, >>>>>> w3c/csswg-drafts#2796 >>>>>> <https://github.com/w3c/csswg-drafts/issues/2796>, >>>>>> w3c/csswg-drafts#5225 >>>>>> <https://github.com/w3c/csswg-drafts/issues/5225>, >>>>>> w3c/csswg-drafts#5518 >>>>>> <https://github.com/w3c/csswg-drafts/issues/5518>, and also some >>>>>> minutes from July 2020 >>>>>> <https://lists.w3.org/Archives/Public/www-style/2020Aug/0006.html#:~:text=vertical%2Dalign%3A%20super%20and%20font%20metrics> >>>>>> >>>>>> and from September 2020 >>>>>> <https://lists.w3.org/Archives/Public/www-style/2020Sep/0023.html#:~:text=should%20we%20add%20the%20super%20and%20subscript> >>>>>> .) >>>>>> >>>>>> One other point that I missed yesterday is that one of the key >>>>>> reasons that these new properties can't be used for the default >>>>>> rendering >>>>>> of <sup>/<sub> elements is that they don't support *nested* >>>>>> subscript/superscript. One of the goals of the 2011 discussion I cited >>>>>> above was to solve that issue in a reasonable way. All of the current >>>>>> ways >>>>>> of doing typographically correct super/subscripts only support a single >>>>>> level of super/subscript, and not nesting. This works for the majority >>>>>> of >>>>>> use cases, but not all. >>>>>> >>>>>> -David >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3ht%3DrZwCtQoUWJXR4avCaY2TvAa9NMiYAfMsdan94wzVw%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3ht%3DrZwCtQoUWJXR4avCaY2TvAa9NMiYAfMsdan94wzVw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fMAG16L3_KweN4FnnSnVsfevxHyH2qfdN1B42ef1Xmg%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fMAG16L3_KweN4FnnSnVsfevxHyH2qfdN1B42ef1Xmg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-SQGewKUSrL0MGTXh_L3DU_RSfah2t8SrS8K3FPaeR2g%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-SQGewKUSrL0MGTXh_L3DU_RSfah2t8SrS8K3FPaeR2g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/447e52a2-cad6-46e9-b8b5-182dca240153n%40chromium.org.
