- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 10:33:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts] It should be possible to slant glyphs to the left for italics/oblique`, and agreed to the following: * `RESOLVED; *if* a browser does synthesis of oblique, there SHOULD be at least one synthesized font in each direction` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> addison: This is an observation from gap analysis, maybe let Richard intro this<br> <chris> q+<br> <TabAtkins> r12a: I think florian expanded the qs and info significantly. I'll do a brief intro then pass it.<br> <chris> q-<br> <r12a> https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1649678597<br> <chris> q+ florian<br> <chris> q+<br> <TabAtkins> r12a: If you follow that link, you'll see a picture which'll help follow<br> <TabAtkins> r12a: there are orthographies aroudn the world where if you italicize, in some cases, or definitly oblique text, it doesn't lean to the right it leans to the left - generally the reading direction of that script<br> <TabAtkins> r12a: the way the spec addresses this is problematic atm<br> <TabAtkins> r12a: if there's an italic font available, the browsers tend to switch to that automatically<br> <TabAtkins> r12a: But the italics available don't necessarilly lean to the left, they'll usually lean ot the right<br> <TabAtkins> r12a: So if this font is substituted you don't get what you expect<br> <addison> (btw, I18N+CSS meeting calendar entry: https://www.w3.org/events/meetings/d737b1d9-bb00-4b14-9507-0338465ee8ed/20230926T220000/)<br> <TabAtkins> r12a: So it seems we need to separate more clearly the separation between italic and oblique, and allow you to insist on oblique<br> <myles> q+<br> <TabAtkins> r12a: italicization isn't the same as oblique anyway<br> <TabAtkins> r12a: in a script like cyrillic the letterforms are very different<br> <TabAtkins> r12a: so that's another reason not to munge together italics and oblique<br> <florian> https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1651137267<br> <chris> ack florian<br> <TabAtkins> florian: for full details of what i'll be talking about, this is the original comment<br> <TabAtkins> florian: a few points to make fixes in the spec<br> <TabAtkins> florian: overall it seems the spec is trying to say that falling from italic to oblique is a thing but the reverse isn't, which is reasonable<br> <TabAtkins> florian: but ambiguous<br> <TabAtkins> florian: there are some places taht seem to suggest they're talking about falling back from oblique to italic, we shoudl clarify<br> <TabAtkins> florian: Also there's some bit that takes the closest available angle, it should take sign into account<br> <TabAtkins> florian: Choosing the wrong direction because it's a clsoer angle seems bad<br> <TabAtkins> florian: Also synthesizing italics is problematic. If you synthesize, you generate oblique for it<br> <TabAtkins> florian: We have a control to say *no* synthesis<br> <TabAtkins> florian: But the way this is written, it suggests tha tif you turn it off, it'll turn off *oblique* synthesis as well.<br> <TabAtkins> florian: And that's bad. Oblique synthesis is easy and reasonable - real oblique can be slightly better but it's very close, unlike synthetic italic.<br> <astearns> thinks these should be separate issues, going forward<br> <drott> q+<br> <TabAtkins> florian: So ahving the same control turn off both italic and oblique synthesis seems bad.<br> <chris> q?<br> <TabAtkins> florian: So I think we need to at least not disable oblique synthesis when turning off italic synthesis.<br> <TabAtkins> florian: And *maybe* we need a way to control oblique synthesis, unsure that's needed.<br> <TabAtkins> florian: Anothe rissue, a variable font can have a numeric axis for oblique<br> <TabAtkins> florian: But for non-variable fonts we don't know the lean direction<br> <TabAtkins> florian: Might be useful to have in @font-face a way to indicate the lean direction<br> <TabAtkins> florian: So browsers can know what it has and give the right one<br> <TabAtkins> florian: If we want to give authors this choice, we need to give that info to browsers.<br> <astearns> ack chris<br> <TabAtkins> astearns: This is a great list of issues; after this meeting we shoudl split these up<br> <TabAtkins> chris: some of this wording about italic and oblique dates back to css1<br> <TabAtkins> chris: it's trying desperately to ensure it's different from normal text, no thought about i18n or good typography<br> <TabAtkins> chris: So I think some of that wording can just be backed off<br> <TabAtkins> chris: For closest angle, I think has an easy fix; find the closest angle of the desired lean direction.<br> <TabAtkins> astearns: fantasai suggests we resolve on that<br> <fantasai> scribe+<br> <fantasai> TabAtkins: Should we still pick the wrong direction if you only have one direction?<br> <TabAtkins> drott: We already ahve italic-left vs right control tho<br> <TabAtkins> chris: For varaible fonts, yes. This is for non-variable<br> <TabAtkins> myles: Chris talked about users pref<br> <TabAtkins> myles: Does the angle actually have semantic meaning?<br> <TabAtkins> myles: If we pick the wrong angle, does that change the semantic meaning of the text, or does it just look ugly?<br> <drott> We have control `oblique n deg` which can be positive or negative.<br> <TabAtkins> chris: I think it's actually *wrong*, not just ugly<br> <TabAtkins> chris: If some text leans left and suddenly some leans right it just looks horrible<br> <TabAtkins> myles: Do these langs have a concept of italics historically?<br> <TabAtkins> r12a: Two african scripts in recent use, didn't have italics until font designers started working with them<br> <drott> For italic font-style, we don't have a way to express which direction it should go.<br> <TabAtkins> r12a: They asked the speakers what direction it should lean, and they clearly said it should lean left<br> <TabAtkins> r12a: n'ko [i think i got the name right]<br> <TabAtkins> r12a: For hebrew and some extent arabic, it's a personal choice<br> <TabAtkins> r12a: Some people prefer left, some prefer right<br> <drott> q?<br> <TabAtkins> myles: So my q is if fonts exist that are in the correct direction, why not use that?<br> <TabAtkins> r12a: There's very limited support, N'Ko has like 4, and 2 aren't complete. Noto has just developed a new font based on this discussion.<br> <astearns> ack myles<br> <TabAtkins> r12a: For Hebrew there are fonts that lean both ways<br> <TabAtkins> r12a: that's where florian's suggestion of being able to select a font based on lean direction comes from<br> <TabAtkins> myles: So sometimes it's personal pref, but sometimes it's valid linguistically<br> <TabAtkins> fantasai: I'm not sure I understand<br> <TabAtkins> fantasai: If author requests a slant of -12deg, why would give it a +5deg slant? If you had an option of -20deg or whatever<br> <TabAtkins> myles: Say numbers again?<br> <myles> the relevant part of the spec: https://drafts.csswg.org/css-fonts-4/#ex-ascending-oblique-13<br> <TabAtkins> astearns: I think the proposed resolution is, when searching for the nearest angle, find the angle in the same direction first, then find nearest angle in any direction if there's nothing.<br> <TabAtkins> myles: The spec does that<br> <TabAtkins> myles: If you request positive, it'll search the positives first, etc<br> <TabAtkins> drott: So question is if you want to cross 0 or not<br> <fantasai> astearns: In case where sign of the angle is ... is it better to switch the sign or find the closest on that side<br> <TabAtkins> myles: I thought richard just said neither is semantic<br> <TabAtkins> r12a: correct, but i also said N'Ko speakers would be happy with the wrong lean<br> <florian> q+<br> <TabAtkins> r12a: hebrew speakers would prefer one direction, but would be okay with either better than nothing<br> <TabAtkins> chris: The comparison isn't against nothing, it's against synthesis<br> <TabAtkins> chris: Not clear that wrong direction si better than synthetic<br> <TabAtkins> r12a: If you said you wanted an oblique font, the impls will switch to an italic font if needed, and you can't control the direction of that. That jump can be problematic.<br> <TabAtkins> r12a: So part of the discussion is if you want oblique you should be able to keep it<br> <TabAtkins> astearns: We already have preserving the sign, if possible<br> <TabAtkins> astearns: Coudl open a separat eissue of if there's anything different to do when the choice would change sign<br> <TabAtkins> astearns: Then we can go to the rest of the issue about italic vs oblique<br> <astearns> ack florian<br> <TabAtkins> florian: Even if direction is a pref and both would be fine, issue is the doc is unlikely to be a single font<br> <myles> q+<br> <myles> q-<br> <myles> q?<br> <TabAtkins> florian: If you have, say, bold italic in the middle of non-bold italic, and you have one font but not the other so you synthesize, if the direction clashes it'll look horrible<br> <TabAtkins> florian: Whether you want to switch to another font that you know leans the right way, or synthesize, dunno. But switching direction can be very unacceptable, depending on context.<br> <myles> q?<br> <astearns> ack drott<br> <myles> ack drott<br> <TabAtkins> drott: how important do you find it to be that this is synthetic or not?<br> <TabAtkins> drott: Is you main focus on matching, or synthesizing?<br> <TabAtkins> drott: I think our synthesization doesn't take angle into account<br> <TabAtkins> drott: So q is if angle should key into our choice to synthesize<br> <TabAtkins> r12a: I don't think that's part of what i'm requesting, I was assuming you could set an oblique angle<br> <TabAtkins> drott: So you're more interested in font matching than synthesis?<br> <TabAtkins> r12a: I think so, I'm not a CSS font expert. I'm interested in users getting the behavior they want, leaning left or right.<br> <florian> s/other so you synthesize/you would need to either synthesize or fallback to a font family that does can lean the right way.<br> <TabAtkins> drott: But you'd expect authors to bring fonts for that?<br> <TabAtkins> astearns: For my clarification, when you said synthesis only uses one angle, is it only one direction too? Or can it go left and right?<br> <florian> s/it'll look horrible/it'll look horrible, possibly into unreadable territory as letters colide and overlap<br> <TabAtkins> drott: I'd have to check.<br> <TabAtkins> myles: We have a hardcoded angle with a fixed direction.<br> <TabAtkins> myles: the way the spec phrases synthesis is, in your family you ahve fonts, and if the browser wants to add more, it can do it. as many as they want.<br> <TabAtkins> myles: So the spec is phrased as if the fonts are not created in response to request, they're just *there*<br> <wolfgang> s/ahve/have/<br> <TabAtkins> astearns: Ah so my udn erstanding of richard's concern is that browsers should have synthetic oblique for both left and right. At least those two, even if there's only one angle in each direction.<br> <TabAtkins> myles: I think that's reasonable.<br> <TabAtkins> myles: Digging deeper, users don't care about synthesis they just want it to look right<br> <TabAtkins> myles: From impl, synthesis and selection are very different.<br> <wolfgang> s/udn erstanding/understanding/<br> <TabAtkins> myles: If there's a font with the right angle, everyone gets the right answer.<br> <TabAtkins> myles: Remaining question is if there isn't a correct-direction font we *could* synthesize a good one.<br> <TabAtkins> myles: But right now the spec doesn't have must-level requirements for synthesis at all.<br> <TabAtkins> myles: But I think the spec should *at least* have a should-level note suggesting that if you synthesize, we should have two directions.<br> <TabAtkins> myles: At most a should-level, not must, given the lack of requirement around synthesis right now.<br> <TabAtkins> r12a: You can set negative angle and get synthesis correct in some browsers<br> <TabAtkins> myles: Really?<br> <TabAtkins> r12a: You shouldn't necessarily automatically fall back to a font of *any* type, if you actually want to specify an oblique<br> <TabAtkins> myles: In our impl, those have to be the same, for mechanical reasons, oblique and italic have to be treated the same.<br> <TabAtkins> myles: I agree philosophically it's wrong, our impl just constrains us.<br> <drott> q+<br> <astearns> ack drott<br> <TabAtkins> drott: What I'm gathering is that about fallback, you won't want to fallback in the wrong direction. That's not currently in the matching algo.<br> <TabAtkins> drott: So that brings us back to the "should we cross 0" in fallback.<br> <TabAtkins> drott: The algo currently prefers the correct lean but will change direction if needed.<br> <TabAtkins> astearns: That's a seaprate issue we'll discuss in the future, seeing if there's anything else here we can resolve on.<br> <TabAtkins> astearns: So back to Myles' suggestion about a note saying browsers should synthesize oblique in both directions<br> <TabAtkins> fantasai: I would go further and say *if* the browser is synthesizing, it *must* have both directions. Not sure why we'd allow unidirection if you're synthesizing in the first place.<br> <TabAtkins> drott: We don't have an internal API for that. I can see the utility of it.<br> <TabAtkins> drott: I think it's acceptable.<br> <TabAtkins> astearns: So the value of a note is showing our interest in it being ipmlemented. But not requiring it due to underllying tech stack.<br> <TabAtkins> fantasai: can't put MUST into notes<br> <TabAtkins> astearns: Right, not using 2119<br> <fantasai> TabAtkins: counter-proposal is, normatively state "if you synthesize, you must synthesize both directions"<br> <fantasai> TabAtkins: the main concern was that sythesis was an optional feature, right?<br> <TabAtkins> astearns: And drott didn't want it to be must because currently they can't synthesize both directions<br> <Bert> q+ to ask if there shouldn't be a way to ask left or right leaning, instead of a precise angle.<br> <wolfgang> s/ipmlemented/implemented/<br> <TabAtkins> astearns: So I was sticking with a note to express our preference.<br> <TabAtkins> myles: Might be able to compromise here, start with less strict req.<br> <TabAtkins> myles: I expect we'll implement it, no reason not to. And then we can upgrade to a requirement later.<br> <astearns> ack Bert<br> <Zakim> Bert, you wanted to ask if there shouldn't be a way to ask left or right leaning, instead of a precise angle.<br> <drott> q?<br> <TabAtkins> fantasai: I'm fine with SHOULD for now, cranked to MUST later.<br> <myles> s/I expect we'll implement it/I expect everyone will implement it/<br> <TabAtkins> Bert: In most cases I really just carea bout left vs right, can I avoid specifying a number?<br> <florian> q+<br> <TabAtkins> astearns: I like the idea but it shoudl be a separate issue<br> <astearns> ack florian<br> <wolfgang> s/carea bout/care about/<br> <TabAtkins> florian: I'd filed that in a bunch of bullets, agree to file it. It was convenient to centralize them for a bit, let's split them out.<br> <wolfgang> s/shoudl/should/<br> <TabAtkins> astearns: First, action florian to split out bullets into separate issues.<br> <TabAtkins> fantasai: Agree should file separate issues, don't think that should block us from discussing.<br> <TabAtkins> astearns: Right, dont' think we have a conclusion on that topic (just specify lean direction) but think we can go back to the synthetic q<br> <wolfgang> s/dont'/don't/<br> <TabAtkins> myles: proposed resolution is *if* a browser does synthesis of oblique, there SHOULD be at least two synthesized fonts, one in each direction<br> <drott> yes, lgtm<br> <TabAtkins> astearns: objections?<br> <dbaron> (maybe could be simplified to "SHOULD be at least one synthesized font in each direction", but doesn't matter to me)<br> <TabAtkins> RESOLVED; *if* a browser does synthesis of oblique, there SHOULD be at least one synthesized font in each direction<br> <TabAtkins> astearns: so, fallback for oblique<br> <TabAtkins> florian: Depending on which part of the spec you read it either says oblique->italic is not a thing, or suggests it's okay. I think we should remove the part that suggests it's okay.<br> <drott> q+<br> <TabAtkins> florian: I think there's a part that talks about picking a font for the closest angle, that doesn't seem to differentiate betwen italic and oblique<br> <jfkthame> q+<br> <TabAtkins> drott: I'd be in favor of seaprating italic to oblique, but that's a breaking change<br> <TabAtkins> florian: From italic to oblique, yes, but from oblique to italic?<br> <TabAtkins> myles: For us yes<br> <wolfgang> s/seaprating/separating/<br> <TabAtkins> drott: Similar to what myles says, we don't make an internal distinction between oblique and italic<br> <TabAtkins> fantasai: Worth pointing out the spec currently says, in the space where things are more precise, it runs thru all the obliques in the positive direction, then the italics, then the obliques and italics in the negative.<br> <TabAtkins> myles: I wrote that on purpose to achieve this.<br> <TabAtkins> fantasai: I don't think we want to change this but might want to give some control over this.<br> <TabAtkins> astearns: Q for i18n folks.<br> <TabAtkins> astearns: If author specifies oblique in positive direction, is it acceptable to get italic in positive direction, or would be better to get oblique in negative direction?<br> <TabAtkins> jfkthame: Neither one<br> <florian> q+<br> <TabAtkins> fantasai: My intuition is matching the slant is more than letterform<br> <drott> agree with fantasai<br> <astearns> ack drott<br> <florian> q-<br> <TabAtkins> r12a: don't understand why you'd go for a negative oblique if you asked for positive<br> <astearns> ack jfkthame<br> <TabAtkins> myles: The reason I wrote it this way is if you are using a weird font that leans the wrong way, and the user asks for italic, you want it leaning the wrong way rather than nothing.<br> <TabAtkins> jfkthame: Agree that we shouldn't fall back to italic when oblique is requested. I know it's what we currently do but we shoudl change it, better to synthesize oblique than fallback to italic<br> <TabAtkins> jfkthame: Also think we should synthesize a slant rather than choose a wrong lean.<br> <florian> +1 to jfkthame<br> <florian> q-<br> <florian> q+<br> <TabAtkins> astearns: Is it possible to resolve to remove the italic fallback?<br> <myles> q?<br> <TabAtkins> florian: q for jfkthame<br> <TabAtkins> s/florian/fantasai/<br> <TabAtkins> fantasai: If you don't have synthesis enabled, better to fall back to wrong-direction lean, or upright?<br> <fantasai> s/wrong-direction lean/matching-direction italic/<br> <TabAtkins> jfkthame: I think if you don't have synthesis enabled, you'd end up with<br> <TabAtkins> jfkthame: you'd get the same font you would have got, without synthesis. so no fallback from oblique to italic, not across zero. so font-matching rules would determine what font you get<br> <TabAtkins> TabAtkins: So given elika's question, you'd get upright?<br> <astearns> ack florian<br> <TabAtkins> jfkthame: yes<br> <TabAtkins> florian: I think i agree with jfkthame if the browser is capable of synthesis. In a browser that isn't i'm less sure.<br> <TabAtkins> florian: I agree that if you ahve synthesis, getting italic rather than synthetic oblique is weird.<br> <myles> q+<br> <TabAtkins> florian: But if you can't get synthesis it gets murky<br> <TabAtkins> jfkthame: Is there any browser that does no synthesis.<br> <TabAtkins> florian: Dunno but Myles was mentioning it being optional and that seems important.<br> <TabAtkins> myles: Biggest argument for fallback between oblique and italic. First is just software design, currently hard.<br> <TabAtkins> myles: other is compat<br> <wolfgang> s/ahve/have/<br> <TabAtkins> myles: For us to do it, we'd have to run an experiment (in Firefox?) to implement the new behaior and see if there's complaints<br> <wolfgang> s/behaior/behavior/<br> <drott> Agree<br> <TabAtkins> fantasai: My take is that, on the web, given the wide variety of environs, preserving that there is a slant is probably important in some cases, so having it fallback to italic if you don't have oblique *and* can't synthesize is reasonable default.<br> <drott> ^<br> <TabAtkins> fantasai: Might want to allow turning that off and say "italic only" or "oblique only", but by default having them fallback to each other makes for a more robust behavior.<br> <TabAtkins> myles: My point about compat is if the author happened to always be right, then no need to fallback. only when author gets it wrong does it matter.<br> <TabAtkins> florian: if choice is fallback to italic *or* synthesize oblique, I think synthesize oblique is preferable. fallback to italic is fine if there's no other option.<br> <TabAtkins> florian: And I think that preserves compat reasonable<br> <astearns> q?<br> <astearns> ack myles<br> <myles> q-<br> <florian> s/that preserves compat reasonable/that preserves reasonable compat<br> <TabAtkins> astearns: I think we're done for the moment, should split out the issues and take them bit by bit. Sound okay?<br> <xfq> +1<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8914#issuecomment-1719197652 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 September 2023 10:33:50 UTC