Re: [csswg-drafts] [css-fonts-4] [varfont] font matching algorithm should not favor italic as a fallback for oblique

The Working Group just discussed `font matching algorithm should not favor italic as a fallback for oblique`, and agreed to the following:

* `RESOLVED: If the author specifies oblique, and syntehsis is on, we fall back to synthesized oblique.`
* `RESOLVED: The fallback list for oblique is synth oblique, italic, roman, next font. The synth step is skipped if font-synthesis is turned off.`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: font matching algorithm should not favor italic as a fallback for oblique<br>
&lt;heycam> github:<br>
&lt;heycam> myles: this is pretty straightforward<br>
&lt;heycam> ... I migrated this issue on behalf of jkew<br>
&lt;heycam> ... currently the way the spec is worded, if you say you want an italic font, the algorithm says UAs will try to match oblique ones afterwards<br>
&lt;heycam> ... and vice versa<br>
&lt;heycam> ... Jonathan Kew says this isn't how it used to be<br>
&lt;heycam> ... used to only go in one direction, fallback from italic to oblique<br>
&lt;heycam> chris_: correct, CSS 2.1 just went one way<br>
&lt;heycam> florian: did we change it bidirectional intentionally?<br>
&lt;heycam> ... or just felt like the right thing to do at some point?<br>
&lt;heycam> myles: it was not intentional, don't think it was discussed in the WG<br>
&lt;heycam> chris_: also has a variable fonts interaction, with the italic axis<br>
&lt;heycam> myles: it's somewhat involved, but doesn't fundamentally<br>
&lt;heycam> ... there are italic and oblique fonts, can be expressed with italic axis<br>
&lt;fantasai> jfkthame's position:<br>
&lt;heycam> ... I don't have a particular thought about this<br>
&lt;heycam> ... seems like there are some arguments to change it back<br>
&lt;heycam> ... no arguments from me to keep it as it is<br>
&lt;heycam> astearns: some people on the thread say it should stay as it is<br>
&lt;heycam> ... to avoid synthesizing things<br>
&lt;heycam> chris_: but we also have a property to turn off synthesizing if you want<br>
&lt;heycam> fantasai: [reads jfkthame's position]<br>
&lt;heycam> fantasai: I think it makes a good argument about making a distinction between oblique and italic<br>
&lt;heycam> ... but there are two cases here<br>
&lt;heycam> ... if you don't have oblique, instead of falling back to italic, use slanted normal<br>
&lt;heycam> ... but if we've turned off font synthesis for italics, you can't have a slanted normal face<br>
&lt;heycam> florian: then what?<br>
&lt;heycam> fantasai: only choice for fallback then are use italic or normal<br>
&lt;heycam> chris_: then you fall back to normal face<br>
&lt;heycam> fantasai: which risks losing the distinction between normal and oblique<br>
&lt;heycam> ... more important than the distinction between oblique and italic<br>
&lt;heycam> chris_: risks both ways<br>
&lt;heycam> ... if someone explicitly wants oblique, it's probably in contrast to italic, like in some math<br>
&lt;heycam> florian: they may be<br>
&lt;myles> q+<br>
&lt;heycam> ... probably? not sure<br>
&lt;heycam> myles: I think it would be valuable to know which browsers<br>
&lt;heycam> ... in WebKit italic and oblique are the same<br>
&lt;heycam> ... is that true in other browsers?<br>
&lt;heycam> frremy: Edge does have a difference<br>
&lt;heycam> ... and we can choose the angle<br>
&lt;heycam> eae: Blink is the same<br>
&lt;heycam> fantasai: if you have a family with italic and oblique and normal, if they choose italic or oblique, they should get what they requested<br>
&lt;heycam> ... we have syntax to distinguish them<br>
&lt;heycam> myles: now the spec allows our behaviour<br>
&lt;heycam> frremy: I recall in Firefox it's different<br>
&lt;heycam> emilio: since Jonathan filed the issue, I assume so<br>
&lt;heycam> myles: so WebKit is the only one to treat them the same<br>
&lt;heycam> fantasai: going through Jonathan's logic, there's a preference if you specify oblique, do that, then synthetic second, then what comes third?<br>
&lt;heycam> ... if synthesis is disabled<br>
&lt;heycam> fantasai: I argue fall back to italics at that point<br>
&lt;heycam> [general hmms....]<br>
&lt;heycam> chris_: I'm slightly worried about that, it's a third option nobody is asking for<br>
&lt;heycam> fantasai: nobody was asking about the case of synthesis disabled<br>
&lt;heycam> frremy: does anyone support disabling synthesis?<br>
&lt;heycam> myles: Firefox and WebKit do<br>
&lt;heycam> florian: what's the scope?<br>
&lt;heycam> astearns: in the @font-face rule<br>
&lt;heycam> florian: I think I will argue that if you disable fake italics, you never disable fake oblique<br>
&lt;heycam> myles: I don't believe there's any implementation that modles fake italics as anything other than fake oblique<br>
&lt;heycam> florian: if you asked for oblique, and you've disabled font synthesis, you should still get synthesized oblique<br>
&lt;heycam> myles: no<br>
&lt;heycam> chris_: that's not true<br>
&lt;heycam> ... first, the definition of "fake"<br>
&lt;heycam> ... in variable fonts there's an axis called ital which is the oblquue axis<br>
&lt;heycam> ... that shouldn't be turned off by turning off fake oblique<br>
&lt;heycam> florian: I'm saying you should never be able to disable fake oblique<br>
&lt;heycam> myles: no<br>
&lt;heycam> ... web authors mean it when they say disabled syntehsis<br>
&lt;heycam> ... of everything<br>
&lt;heycam> fantasai: if you have the font you use it no question<br>
&lt;heycam> fantasai: there's a bit difference between what the UA can do and what the designer intended<br>
&lt;heycam> ... [for italics].  for obliques, the difference is much smaller<br>
&lt;heycam> myles: I understand that distinction, every author I talked to [ ....]<br>
&lt;heycam> astearns: I hear if syntehsis is disabled, it means never change the letterforms<br>
&lt;heycam> ... they happen to know that this font family has an oblique face, but the web font package forgot to download it, they still don't want a synthesized oblique<br>
&lt;heycam> florian: for italics I totally buy it<br>
&lt;heycam> ... less convinced for oblique<br>
&lt;heycam> eae: why not make it explicit, for oblique?<br>
&lt;heycam> florian: sure<br>
&lt;heycam> ... but people disabling synthesis in general, I think allowing syntehsizing oblique is ok<br>
&lt;heycam> myles: font-synthesis talks about weight and style<br>
&lt;heycam> astearns: style should block both italic and oblique. if you want to distinguish them, it would need a new value<br>
&lt;heycam> florian: so then what do we display<br>
&lt;heycam> fantasai: there are two proposals.  Jonathan Kew's is, if you don't have oblique, you fall back to syntehsis<br>
&lt;heycam> ... alternative is to fall back to italic if it exists<br>
&lt;heycam> florian: it's arbitrary<br>
&lt;heycam> ... it's possibel tue author is trying to constrast italic and oblique<br>
&lt;heycam> fantasai: can't think of a case when you want to contrast with oblique but not with roman<br>
&lt;heycam> koji: author is specifying oblique explicitly<br>
&lt;heycam> ... I don't think they care what it looks like if synthesis is disabled<br>
&lt;heycam> fantasai: if the author specifies oblique, and synthesis is on, do we fall back to italics or synthesized oblique?<br>
&lt;heycam> frremy: syntehsized oblique<br>
&lt;heycam> chris_: agreed<br>
&lt;heycam> RESOLVED: If the author specifies oblique, and syntehsis is on, we fall back to synthesized oblique.<br>
&lt;heycam> myles: now it's legal in the spec to alias oblique and italics<br>
&lt;heycam> ... I think this would make this impossible<br>
&lt;heycam> astearns: we're reverting back to the CSS 2 definition<br>
&lt;heycam> chris_: so far<br>
&lt;heycam> frremy: I think the spec is very broad<br>
&lt;heycam> ... if you alias both of them, this section doesn't apply<br>
&lt;heycam> ... since you don't have a font that's oblique<br>
&lt;heycam> s/font/font-style/<br>
&lt;heycam> florian: is this lack of distinction you proactively want to preserve?<br>
&lt;heycam> myles: haven't investigated how difficult it would be to get rid of it<br>
&lt;heycam> ... don't know how CoreText differentiates the two<br>
&lt;heycam> ... given Chrome uses CoreText, I guess it's ok<br>
&lt;tantek> I feel like we need more typographer expert opinion to make a more informed decision about these things. We should have discussed this in April when we could have asked a bunch of Typolabs people<br>
&lt;heycam> skk: if oblique is specified, which direction?<br>
&lt;heycam> myles: in horizontal it's well defined<br>
&lt;heycam> skk: in vertical? there's no definition<br>
&lt;heycam> florian: we have an issue open for that<br>
&lt;heycam> dbaron: we spent half a day talking about it once<br>
&lt;heycam> astearns: other part is if font-synthesis for style is turned off<br>
&lt;heycam> chris_: if there is already an italic, do we use that in preference to normal?<br>
&lt;heycam> fantasai: I think we should<br>
&lt;heycam> astearns: I think we should not<br>
&lt;heycam> florian: my preference is synthesize anyway, but I've heard the objections<br>
&lt;dbaron> prior discussion of synthesis direction in vertical text was I think<br>
&lt;heycam> frremy: fall back to normal is my normal<br>
&lt;heycam> chris_: me too<br>
&lt;heycam> astearns: turning something off makes a path available that wasn't there before<br>
&lt;heycam> fantasai: it just means you've got a list of four prefs instead of three<br>
&lt;heycam> ... non-synth oblique, synth oblique, italics, normal<br>
&lt;heycam> astearns: I'm saying when synthesis is on, you don't have a path to get from oblique to italics<br>
&lt;heycam> ... weird to add that path when synthesis is turned off<br>
&lt;heycam> fantasai: you have it by having oblique in the font selection algorithm<br>
&lt;heycam> frremy: there may be a case, if you have a font with a custom font without a normal version, but does have an italic, you can't synthesize ...<br>
&lt;heycam> florian: just put it in your fallback chain<br>
&lt;heycam> fantasai: you can't<br>
&lt;heycam> ... I think Francois' point is good<br>
&lt;heycam> ... there are fonts that only have italic<br>
&lt;heycam> ... so my pref is that we should have italics in that fallback chain, either before or after normal<br>
&lt;heycam> myles: [writes some options on the board]<br>
&lt;heycam> florian: if there is no roman, do you choose italic as fallback<br>
&lt;heycam> fantasai: we can also not decide this now<br>
&lt;heycam> tantek: yes<br>
&lt;heycam> chris_: they will say never synthesize!<br>
&lt;heycam> florian: they typically don't know about fallback on the client side<br>
&lt;heycam> tantek: I don't agree<br>
&lt;heycam> ... Typo Labs people were very away of web ecosystem and how font loads fail<br>
&lt;heycam> ... I think they understand the context<br>
&lt;heycam> florian: fair enough<br>
&lt;heycam> myles: one other issue.  oblique is not the initial value of font-style, so turning on oblique is an author saying "make it not the normal way it looks"<br>
&lt;heycam> ... so probably shouldn't put normal before italic<br>
&lt;heycam> chris_: good point<br>
&lt;heycam> RESOLVED: The fallback list for oblique is synth oblique, italic, roman, next font. The synth step is skipped if font-synthesis is turned off.<br>
&lt;heycam> astearns: let's consult with typo experts to see if it matches expectations<br>
&lt;heycam> chris_: let's put it in the spec and then ask them<br>
&lt;skk> Last Tokyo F2F, people from DTP said no oblique exist in Japanese vertical writing type setting. But recent ebook related people want to use italic/oblique font style.<br>
&lt;frremy> ScribeNick: frremy<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 3 July 2018 04:37:01 UTC