[go: up one dir, main page]
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.

Sign up for GitHub

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

Jump to bottom

[css-fonts] Default angle for font-style:oblique should conform to host platform #2295

Closed
jfkthame opened this issue Feb 9, 2018 · 5 comments
Closed

[css-fonts] Default angle for font-style:oblique should conform to host platform #2295

jfkthame opened this issue Feb 9, 2018 · 5 comments
Labels
Closed Accepted by CSSWG Resolution css-fonts-4 Current Work Needs Testcase (WPT)

Comments

@jfkthame
Copy link
Contributor
jfkthame commented Feb 9, 2018

Currently the Fonts 4 draft says that if the optional <angle> is not specified for font-style: oblique, this "represents an angle of "20deg"". However, in my experience the angle used for synthetic-oblique font styling -- which has long been provided by most platform text-drawing APIs, when asked to draw "Italic" text with a font family that only provides Regular -- varies significantly between platforms, with (for example) Windows applying a more pronounced slant than macOS.

In order to better match the "native" text rendering of the platform, therefore, Firefox currently uses a platform-specific value when applying a synthetic-italic/oblique effect. I would suggest that this is appropriate behavior for font-style: oblique when no explicit <angle> is given, and rather than mandating a specific angle in this case, the spec should say something along the lines of "if an <angle> is not specified, the user agent should use a slant angle that harmonizes with the platform's typical text rendering behavior."

Moreover, if we must specify a default here, rather than allowing the browser to follow platform conventions, I think 20deg is too large. Current Firefox behavior -- which was designed to harmonize with host platform behavior -- uses an angle between 11.3deg and 16.7deg. Checking the italicAngle field in a sampling of actual italic/oblique fonts shows values that cluster around 11°-12°, with occasional outliers as small as 6° or as large as 16.3°.

[1] https://drafts.csswg.org/css-fonts-4/#valdef-font-style-oblique-angle
@svgeesus svgeesus added the css-fonts-4 Current Work label Feb 9, 2018
@svgeesus
Copy link
Contributor

Checking the italicAngle field in a sampling of actual italic/oblique fonts shows values that cluster around 11°-12°, with occasional outliers as small as 6° or as large as 16.3°.

Interesting data, which itself indicates that 20deg is too large.

Current Firefox behavior -- which was designed to harmonize with host platform behavior -- uses an angle between 11.3deg and 16.7deg

Could you clarify which angle is used on which platform?

In general I dislike platform-dependent or UA-dependent behaviour, but in this case there is no particular downside to interop (stylesheet authors can always select the value they want, this handling of unspecified value is just for backwards compat). It does makes default-angle testing a bit harder. But I would not oppose this if that is what we decide.

@litherum
Copy link
Contributor

Oh, I picked 20deg because I rendered some characters in a couple non-variable fonts which I thought were representative, took a screenshot, and used a compass and rulers to figure out what their angle was. It’s totally possible that either

  1. The rendered angle doesn’t match the information in the font file
  2. My fonts were not representative

I’m all for correcting the measurements I’ve made.

Making the threshold be platform-specific is problematic, because it can cause a totally different font to be chosen for the same input. For example, if there are fonts on the site at angles 19deg and 45deg, moving the threshold from 20deg to 18deg will cause an apparent visual shift of 45deg-19deg=26deg. This is a huge visual difference between platforms with only a tiny difference in threshold.

@jfkthame
Copy link
Contributor Author

Current Firefox behavior -- which was designed to harmonize with host platform behavior -- uses an angle between 11.3deg and 16.7deg

Could you clarify which angle is used on which platform?

Gecko implements synthetic-oblique using a "skew factor" defined in https://searchfox.org/mozilla-central/rev/003262ae12ce937950ffb8d3b0fa520d1cc38bff/gfx/thebes/gfxFont.h#61-69:

// The skew factor used for synthetic-italic [oblique] fonts;
// we use a platform-dependent value to harmonize with the platform's own APIs.
#ifdef XP_WIN
#define OBLIQUE_SKEW_FACTOR  0.3f
#elif defined(MOZ_WIDGET_GTK)
#define OBLIQUE_SKEW_FACTOR  0.2f
#else
#define OBLIQUE_SKEW_FACTOR  0.25f
#endif

where this "skew" is the tangent of the resulting oblique angle. So we have (approximately) 16.7° on Windows, 11.3° on Linux, and 14° on macOS.

@css-meeting-bot
Copy link
Member

The Working Group just discussed default angle for font-style: oblique, and agreed to the following resolutions:

  • RESOLVED: Use 14 degrees as the angle for undefined oblique
The full IRC log of that discussion <dael> Topic: default angle for font-style: oblique
<dael> github: https://github.com//issues/2295
<dael> myles: When css content says font-style:oblique in a non variation world a font is oblique or not. In a variations world that need to be maped to an angle. Variation axis can go between 0 and 90 degrees. When you say font-style:oblique and you don't have an angle where should it go.
<dael> myles: When I wrot the spec I printed paper with representitive fonts and I measure the angle and it looked like 20 deg.
<dael> ChrisL: Based on Jonathan's data the mid-point is 14deg and that's what OSX uses I think that's reasonable.
<dael> florian: Issue had more details about it being platform dependent.
<dael> myles: Spec says it's not and impl made it dependent.
<dael> florian: FF made it dependent becasue it is outside the browser.
<dael> myles: So options are 1) 20deg, 2)14deg 3) make impl pick something.
<dael> astearns: The algo has a whole set of if it's below this pick this
<dael> s/astearns/chrisl
<dael> fantasai: I think that algo should change to lower then 14 then. It should be a lower end to what's consdered normal.
<dael> florian: That would go against leaving it up to ua because we can't do one that's always lower.
<dael> ChrisL: Yes.
<fantasai> s/14 then/14/
<dael> myles: There's 2 pieces. This issue is what should we pick with no angle and it should be 14
<dael> astearns: Obj to using 14 as the oblique angle?
<dael> dbaron: 14 or 14.06? I mention it because Gecko was storing the tan of the angle so we stored 0.25 and the arctan is 14.06
<dael> astearns: Objectiosn to 14 degrees?
<dbaron> s/14.06/14.036/
<dbaron> 14.036deg is atan(0.25)
<dael> RESOLVED: Use 14 degrees as the angle for undefined oblique
<dael> myles: fantasai should open an issue as to where to put the bounderies.
<dael> fantasai: I suggest 10 for now and then we investigate.
<dael> myles: WE should figure out the answer
<dael> myles: Can we pick 14?
<dael> fantasai: We want it less.
<dael> astearns: I uggest as a part of the resolution edits you say there's an issue and then we can edit in the appropriate thing

@fantasai
Copy link
Collaborator

Filed #2539 on using the lowest reasonably-considered-oblique angle as the threshold below which the font is considered normal (not oblique).

fantasai added a commit that referenced this issue Jun 28, 2018
@fantasai
[css-fonts-4] Use 14deg instead of 20deg as default oblique angle per…
2ed7fb2 
… WG resolution. #2295
fantasai added a commit that referenced this issue Jun 28, 2018
@fantasai
[css-fonts-4] Add issue about oblique search threshold. #2295
94844a1
@svgeesus svgeesus mentioned this issue Jun 30, 2018
Closed
@nt1m nt1m mentioned this issue Oct 28, 2022
Merged
webkit-early-warning-system pushed a commit to nt1m/WebKit that referenced this issue Oct 28, 2022
@nt1m
Fix default angle cases from at-font-face-descriptors.html
3e8ac0a 
https://bugs.webkit.org/show_bug.cgi?id=247172
rdar://101666575

Reviewed by Darin Adler.

The default angle is now 14deg, not 20deg, but even then, I do not think we should treat the default angle specially in this case, given that it changed. We lose information by serializing to the shorter form (did the author intend to mean 20deg or the current default angle?). For clarity, always putting the angle is better.

See: w3c/csswg-drafts#2295

* LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/variations/at-font-face-descriptors-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/variations/at-font-face-descriptors.html:

Canonical link: https://commits.webkit.org/256098@main
mnutt pushed a commit to movableink/webkit that referenced this issue Dec 6, 2022
@nt1m @mnutt
Fix default angle cases from at-font-face-descriptors.html
faf1e31 
https://bugs.webkit.org/show_bug.cgi?id=247172
rdar://101666575

Reviewed by Darin Adler.

The default angle is now 14deg, not 20deg, but even then, I do not think we should treat the default angle specially in this case, given that it changed. We lose information by serializing to the shorter form (did the author intend to mean 20deg or the current default angle?). For clarity, always putting the angle is better.

See: w3c/csswg-drafts#2295

* LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/variations/at-font-face-descriptors-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-fonts/variations/at-font-face-descriptors.html:

Canonical link: https://commits.webkit.org/256098@main
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-fonts-4 Current Work Needs Testcase (WPT)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fantasai @litherum @jfkthame @svgeesus @css-meeting-bot