Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-fonts] font-synthesis-style is too blunt #9390

Open
frivoal opened this issue Sep 21, 2023 · 5 comments
Open

[css-fonts] font-synthesis-style is too blunt #9390

frivoal opened this issue Sep 21, 2023 · 5 comments
Labels
Agenda+ F2F css-fonts-4 Current Work i18n-afrlreq African language enablement i18n-alreq Arabic language enablement i18n-hlreq Hebrew language enablement i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.

Comments

@frivoal
Copy link
Collaborator

frivoal commented Sep 21, 2023

(this is a follow up from #8914 (comment))

The main use case for font-synthesis-style: none is to be used in conjunction with font-style: italic, when the author does not want to get a oblique font as a fallback.

However, while it generally works for that purpose, it does a little too much, and a little not enough:

  • if there is a non-synthetic oblique font face, is will be used as a fallback from italic regardless font-synthesis-style. This is unlikely to be what the author want.
  • font-synthesis-style: none also turns off the fallback from font-style: oblique to synthetic oblique. This might be desired in some cases where the author is extremely picky, but unlike with italic, which is a distinctive style, synthetic oblique fonts are often close to indistinguishable from non-synthetic ones.

What we have is a system where, if italic is missing, we always fall back to oblique, but within oblique, we can turn off synthesis, regardless of whether oblique was specifically requested or is being used as a fallback.

What I think we need is a system where if italic is missing, authors can chose whether to fall back to oblique or not, and if yes, synthetic oblique is always acceptable when non-synthetic oblique is not available. Also, we might want an ability to turn off synthetic oblique when font-style: oblique has been requested, though I doubt there's much demand for that.

Even though I'd probably name such a switch differently if we were doing it from scratch, for compat reasons, I'd suggest repurposing the existing font-synthesis-style: none to become this request not to fallback from italic to oblique. That's what it's being used for anyway.

If we do need the extra switch for turning off synthetic oblique when font-style: oblique has been requested, I'd suggest expanding the syntax of that property to font-synthesis-style: auto | none || no-oblique or some such.

@svgeesus
Copy link
Contributor

authors can chose whether to fall back to oblique or not, and if yes, synthetic oblique is always acceptable when non-synthetic oblique is not available. Also, we might want an ability to turn off synthetic oblique when font-style: oblique has been requested, though I doubt there's much demand for that.

Yes, but we also need to take into account the case where a variable font oblique is available, but the range does not encompass the requested angle and we don't want to synthetic-oblique the already-obliqued face to get that value:

@svgeesus
Copy link
Contributor

@frivoal any thoughts on the intersection of your proposal and the need to not use outside-variable-range values?

@drott @jfkthame comments on the proposed change would be welcome

(@astearns removing too-eager Agenda+as there has been insufficient discussion to take it to a call)

@svgeesus svgeesus removed the Agenda+ label Mar 14, 2024
@frivoal
Copy link
Collaborator Author

frivoal commented Mar 15, 2024

any thoughts on the intersection of your proposal and the need to not use outside-variable-range values?

I'd include that in as part of the behavior of the value that turns off the generation of synthetic oblique.

@jfkthame
Copy link
Contributor

jfkthame commented Apr 6, 2024

I think I'd agree that font-synthesis-style: none should disable fallback from italic to oblique, whether "real" or synthetic. It should also disable synthesis of oblique angles outside the available range supported by the font.

(So if no oblique face is available, and font-synthesis-style is turned off, font-style: oblique will have no effect.)

@drott
Copy link
Collaborator

drott commented Apr 11, 2024

What I think we need is a system where if italic is missing, authors can chose whether to fall back to oblique or not, and if yes, synthetic oblique is always acceptable when non-synthetic oblique is not available. Also, we might want an ability to turn off synthetic oblique when font-style: oblique has been requested, though I doubt there's much demand for that.

Generally, I am not sure how urgent of an issue this is, if authors control the content, they can control that just with providing the right web fonts, attributing the web fonts with the correct font-style: descriptors and setting font-synthesis-style: none; and then using either only italic or oblique for styling. I have not seen more than one font family (and that was a test font) that both has an oblique and an italic style.

I am not in favor of re-purposing font-synthesis-x: for influencing font matching, I find that an architecturally strange side effect of a property. Fallback is not the same as synthesis. In that case, I'd rather see us make a choice and change the font matching algorithm to not perform fallback from italic to oblique, even if that's a breaking change. Perhaps we can assess the impact of that.

Agree that font-synthesis: none should not add slant when the variable axis range is exhausted - but I think that's already spec'ed.

@github-project-automation github-project-automation bot moved this to Unsorted regular in Feb 2024 Agenda Aug 26, 2024
@r12a r12a added i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. i18n-alreq Arabic language enablement i18n-afrlreq African language enablement i18n-hlreq Hebrew language enablement labels Oct 11, 2024
@plehegar plehegar changed the title [css-font] font-synthesis-style is too blunt [css-fonts] font-synthesis-style is too blunt Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Agenda+ F2F css-fonts-4 Current Work i18n-afrlreq African language enablement i18n-alreq Arabic language enablement i18n-hlreq Hebrew language enablement i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.
Projects
Status: Unsorted regular
Development

No branches or pull requests

6 participants