[css-fonts-4] [varfont] font matching algorithm should not favor italic as a fallback for oblique #514
Comments
|
If we decide that oblique takes a numerical argument but italic doesn't, then this sounds like a good idea. |
litherum
changed the title
|
See also: #519 |
I don't agree with this. When 'oblique' is requested but no actual oblique is present, I think the better fallback will be the italic face, if available; a synthetically-slanted version of the regular face should always be a last resort. |
I don't agree with this. |
|
The "synthetic" or distorted fonts should be avoided and used as a last
resort because the distortion inherently makes resulting letterforms that
look bad, while crafted obliques or italics will have many subtle changes
that make the letterforms look good. This effects reading performance and
even legibility.
The purpose of a non-normal font-style is to add visual emphasis to the
text. The purpose of designing a non-normal style is to control and match
with the normal style in a way that harmonizes. Distortion can create
visual distinction but not with harmony.
If the CSS author has indicated one kind of emphasis is preferable, but the
font family selected does not have that kind and does have the other kind,
then using the emphasis style which is harmonious is a better choice.
|
|
CSS offers a three-way distinction: The distinctive case is where an author explicitly requests oblique rather than italic. We can assume this is usually a conscious decision by an author, given that tools and common practice all tend towards the italic choice. Indeed, an author who requests oblique may well be wanting to make a distinction between italic and oblique. To use the italic face to fulfill the oblique request will erase this distinction, whereas using an artificially-slanted version of the normal face will maintain it. In addition, while algorithmically generated "styled" faces (e.g. for bold, condensed, or extended) are generally inferior to crafted designs, oblique is one style for which this is less of a concern. A typical upright "normal" face can be algorithmically slanted by a moderate amount with little harm to the design. Therefore, I still believe that |
|
Are you aware of any authors doing this? Would love to see real world examples of that (and examples where oblique is used by itself intentionally) |
|
As one example, Knuth uses /oblique/ text as the style for emphasis in the body text of /The TeXbook/, in contrast to the italics he uses for running heads and for math formulas and math-like material. Looking through a few opening pages from /The Art of Computer Programming/, the convention there seems to be italics for emphasis, while /oblique/ is used for titles in bibliographic references. |
|
The Working Group just discussed
The full IRC log of that discussion<heycam> Topic: font matching algorithm should not favor italic as a fallback for oblique<heycam> github: https://github.com//issues/514 <heycam> myles: this is pretty straightforward <heycam> ... I migrated this issue on behalf of jkew <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 <heycam> ... and vice versa <heycam> ... Jonathan Kew says this isn't how it used to be <heycam> ... used to only go in one direction, fallback from italic to oblique <heycam> chris_: correct, CSS 2.1 just went one way <heycam> florian: did we change it bidirectional intentionally? <heycam> ... or just felt like the right thing to do at some point? <heycam> myles: it was not intentional, don't think it was discussed in the WG <heycam> chris_: also has a variable fonts interaction, with the italic axis <heycam> myles: it's somewhat involved, but doesn't fundamentally <heycam> ... there are italic and oblique fonts, can be expressed with italic axis <fantasai> jfkthame's position: https://github.com//issues/514#issuecomment-335582104 <heycam> ... I don't have a particular thought about this <heycam> ... seems like there are some arguments to change it back <heycam> ... no arguments from me to keep it as it is <heycam> astearns: some people on the thread say it should stay as it is <heycam> ... to avoid synthesizing things <heycam> chris_: but we also have a property to turn off synthesizing if you want <heycam> fantasai: [reads jfkthame's position] <heycam> fantasai: I think it makes a good argument about making a distinction between oblique and italic <heycam> ... but there are two cases here <heycam> ... if you don't have oblique, instead of falling back to italic, use slanted normal <heycam> ... but if we've turned off font synthesis for italics, you can't have a slanted normal face <heycam> florian: then what? <heycam> fantasai: only choice for fallback then are use italic or normal <heycam> chris_: then you fall back to normal face <heycam> fantasai: which risks losing the distinction between normal and oblique <heycam> ... more important than the distinction between oblique and italic <heycam> chris_: risks both ways <heycam> ... if someone explicitly wants oblique, it's probably in contrast to italic, like in some math <heycam> florian: they may be <myles> q+ <heycam> ... probably? not sure <heycam> myles: I think it would be valuable to know which browsers <heycam> ... in WebKit italic and oblique are the same <heycam> ... is that true in other browsers? <heycam> frremy: Edge does have a difference <heycam> ... and we can choose the angle <heycam> eae: Blink is the same <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 <heycam> ... we have syntax to distinguish them <heycam> myles: now the spec allows our behaviour <heycam> frremy: I recall in Firefox it's different <heycam> emilio: since Jonathan filed the issue, I assume so <heycam> myles: so WebKit is the only one to treat them the same <heycam> fantasai: going through Jonathan's logic, there's a preference if you specify oblique, do that, then synthetic second, then what comes third? <heycam> ... if synthesis is disabled <heycam> fantasai: I argue fall back to italics at that point <heycam> [general hmms....] <heycam> chris_: I'm slightly worried about that, it's a third option nobody is asking for <heycam> fantasai: nobody was asking about the case of synthesis disabled <heycam> frremy: does anyone support disabling synthesis? <heycam> myles: Firefox and WebKit do <heycam> florian: what's the scope? <heycam> astearns: in the @font-face rule <heycam> florian: I think I will argue that if you disable fake italics, you never disable fake oblique <heycam> myles: I don't believe there's any implementation that modles fake italics as anything other than fake oblique <heycam> florian: if you asked for oblique, and you've disabled font synthesis, you should still get synthesized oblique <heycam> myles: no <heycam> chris_: that's not true <heycam> ... first, the definition of "fake" <heycam> ... in variable fonts there's an axis called ital which is the oblquue axis <heycam> ... that shouldn't be turned off by turning off fake oblique <heycam> florian: I'm saying you should never be able to disable fake oblique <heycam> myles: no <heycam> ... web authors mean it when they say disabled syntehsis <heycam> ... of everything <heycam> fantasai: if you have the font you use it no question <heycam> fantasai: there's a bit difference between what the UA can do and what the designer intended <heycam> ... [for italics]. for obliques, the difference is much smaller <heycam> myles: I understand that distinction, every author I talked to [ ....] <heycam> astearns: I hear if syntehsis is disabled, it means never change the letterforms <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 <heycam> florian: for italics I totally buy it <heycam> ... less convinced for oblique <heycam> eae: why not make it explicit, for oblique? <heycam> florian: sure <heycam> ... but people disabling synthesis in general, I think allowing syntehsizing oblique is ok <heycam> myles: font-synthesis talks about weight and style <heycam> astearns: style should block both italic and oblique. if you want to distinguish them, it would need a new value <heycam> florian: so then what do we display <heycam> fantasai: there are two proposals. Jonathan Kew's is, if you don't have oblique, you fall back to syntehsis <heycam> ... alternative is to fall back to italic if it exists <heycam> florian: it's arbitrary <heycam> ... it's possibel tue author is trying to constrast italic and oblique <heycam> fantasai: can't think of a case when you want to contrast with oblique but not with roman <heycam> koji: author is specifying oblique explicitly <heycam> ... I don't think they care what it looks like if synthesis is disabled <heycam> fantasai: if the author specifies oblique, and synthesis is on, do we fall back to italics or synthesized oblique? <heycam> frremy: syntehsized oblique <heycam> chris_: agreed <heycam> RESOLVED: If the author specifies oblique, and syntehsis is on, we fall back to synthesized oblique. <heycam> myles: now it's legal in the spec to alias oblique and italics <heycam> ... I think this would make this impossible <heycam> astearns: we're reverting back to the CSS 2 definition <heycam> chris_: so far <heycam> frremy: I think the spec is very broad <heycam> ... if you alias both of them, this section doesn't apply <heycam> ... since you don't have a font that's oblique <heycam> s/font/font-style/ <heycam> florian: is this lack of distinction you proactively want to preserve? <heycam> myles: haven't investigated how difficult it would be to get rid of it <heycam> ... don't know how CoreText differentiates the two <heycam> ... given Chrome uses CoreText, I guess it's ok <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 <heycam> skk: if oblique is specified, which direction? <heycam> myles: in horizontal it's well defined <heycam> skk: in vertical? there's no definition <heycam> florian: we have an issue open for that <heycam> dbaron: we spent half a day talking about it once <heycam> astearns: other part is if font-synthesis for style is turned off <heycam> chris_: if there is already an italic, do we use that in preference to normal? <heycam> fantasai: I think we should <heycam> astearns: I think we should not <heycam> florian: my preference is synthesize anyway, but I've heard the objections <dbaron> prior discussion of synthesis direction in vertical text was I think https://lists.w3.org/Archives/Public/www-style/2013Jul/0065.html <heycam> frremy: fall back to normal is my normal <heycam> chris_: me too <heycam> astearns: turning something off makes a path available that wasn't there before <heycam> fantasai: it just means you've got a list of four prefs instead of three <heycam> ... non-synth oblique, synth oblique, italics, normal <heycam> astearns: I'm saying when synthesis is on, you don't have a path to get from oblique to italics <heycam> ... weird to add that path when synthesis is turned off <heycam> fantasai: you have it by having oblique in the font selection algorithm <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 ... <heycam> florian: just put it in your fallback chain <heycam> fantasai: you can't <heycam> ... I think Francois' point is good <heycam> ... there are fonts that only have italic <heycam> ... so my pref is that we should have italics in that fallback chain, either before or after normal <heycam> myles: [writes some options on the board] <heycam> florian: if there is no roman, do you choose italic as fallback <heycam> fantasai: we can also not decide this now <heycam> tantek: yes <heycam> chris_: they will say never synthesize! <heycam> florian: they typically don't know about fallback on the client side <heycam> tantek: I don't agree <heycam> ... Typo Labs people were very away of web ecosystem and how font loads fail <heycam> ... I think they understand the context <heycam> florian: fair enough <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" <heycam> ... so probably shouldn't put normal before italic <heycam> chris_: good point <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. <heycam> astearns: let's consult with typo experts to see if it matches expectations <heycam> chris_: let's put it in the spec and then ask them <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. <frremy> ScribeNick: frremy |
|
So, this would affect the two lists in the font matching algorithm:
and
in both cases, a new step would be inserted between the current step 2 (checking nearby oblique values in the family) and step 3 (checking italic values). This step would say something like: If |
|
@litherum just looking for a quick sanity check before I make those edits |
This wording makes it sound like setting |
|
Good point. Although in terms of the algorithm, 'match' is used to mean 'success, stop here'. How about: If |
|
Sounds good to me. |
Migrated on behalf of @jfkthame:
Back in the days of CSS2.1, the spec said:
Note that it does not suggest that an italic face should be used when oblique is specified.
However, in CSS Fonts 3, things have changed:
So now, 'italic' falls back to oblique (as before), and 'oblique' falls back to italic (changed behavior).
(This difference is also reflected in the Font Matching Algorithm described in the two spec versions.)
I think this change was a mistake. When 'oblique' is requested but no actual oblique is present, a better fallback than the italic face would be a synthetically-slanted version of the regular face.
According to the reporter in this Mozilla bug, browsers currently differ on this, which leads me to suspect that a spec change here (and corresponding changes to the browsers that follow the current CSS Fonts behavior) will be unlikely to break the web in any substantial way.
(This isn't directly linked with variation fonts, but as we're re-examining the font properties and matching algorithm anyway, and variations do have implications for font-style, it seemed like the right time to bring it up.)
The text was updated successfully, but these errors were encountered: