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-text] [css-values] Circular dependency between letter-spacing and x-height #5498

Closed
litherum opened this issue Sep 4, 2020 · 10 comments
Closed

[css-text] [css-values] Circular dependency between letter-spacing and x-height #5498

litherum opened this issue Sep 4, 2020 · 10 comments
Labels
Closed Accepted by Editor Discretion Commenter Response Pending css-text-4 css-values-3

Comments

@litherum
Copy link
Contributor

litherum commented Sep 4, 2020 •
edited
Loading

https://drafts.csswg.org/css-text-3/#letter-spacing-property

When the effective spacing between two characters is not zero (due to either justification or a non-zero value of letter-spacing), user agents should not apply optional ligatures

letter-spacing takes a <length>, which means that it accepts font-relative units, like 2ex for example. Some (all?) browsers can measure the ex length by actually rendering a literal "x" character and inspecting its height (at least in the case where the metrics inside the font appear to be bogus). However, the liga font feature can change which glyph the "x" character renders with, so if we're supposed to not apply optional ligatures, the height of the "x" character can change depending on whether we're disabling ligatures or not. This means that, if someone applies letter-spacing on an element with ex units, we may have to measure a glyph, but in order to know which glyph to measure, we have to know whether that glyph has a height of 0 or not.

It's a weird fiddly corner case that probably wouldn't ever make a difference in real content, but it's probably worth at least considering how to fix it.
@litherum
Copy link
Contributor Author

litherum commented Sep 4, 2020 •
edited
Loading

Note: Allowing letter-spacing to accept font-relative units is useful. Also, disabling ligatures when letter-spacing is nonzero is also required for good typography. Whatever solution we pick shouldn't break either of these things.

@litherum
Copy link
Contributor Author

litherum commented Sep 4, 2020

The best solution is probably "don't run shaping when calculating the value of font-relative units."

@litherum litherum changed the title [css-text] Circular dependency between letter-spacing and x-height [css-text] [css-values] Circular dependency between letter-spacing and x-height Sep 4, 2020
@litherum
Copy link
Contributor Author

litherum commented Sep 4, 2020

... and the ch and ic units should be calculated without letter-spacing applied (which I think is already the case).

@faceless2
Copy link

The best solution is probably "don't run shaping when calculating the value of font-relative units."

Definitely. I would think "liga" is the least of your problems - salt, swsh, smcp and others would have a much bigger impact on units if they were applied, and some of the substitutions could be language dependent too. The metrics really have to be taken from the original glyph as specified by the glyf or CFF tables.

@emilio
Copy link
Collaborator

emilio commented Sep 6, 2020

cc @jfkthame

@fantasai
Copy link
Collaborator

fantasai commented Sep 9, 2020

The spec doesn't define exactly how to find the value of an 'ex' from the font, leaves that up to the UA with some pointers. So I don't think there's anything to fix here wrt the specs? https://www.w3.org/TR/css-values-3/#ex

@frivoal
Copy link
Collaborator

frivoal commented Sep 14, 2020

Right, we could arguably be more precise, but given the current lack of precision, no circular dependency seem mandated.

@fantasai
Copy link
Collaborator

@litherum Shall I close this no change, or is there some change to the spec you want to see here?

@litherum
Copy link
Contributor Author

Can we add a note?

aarongable pushed a commit to chromium/chromium that referenced this issue Jun 24, 2022
@kojiishi
[ic-unit] Add |IdeographicFullWidth|
1d6f40f 
This patch adds |FontMetrics::IdeographicFullWidth|, which
provides the value for the [`ic` unit].

The spec is not very clear as to how to compute the advance,
but further discussion[1] clarified that it should not
require shaping. This is confirmed to be in sync with the
current Gecko and WebKit implementations.

[`ic` unit]: https://drafts.csswg.org/css-values-4/#ic
[1]: w3c/csswg-drafts#5498 (comment)

Bug: 937101
Change-Id: Ia194c08bb93d84b6215b1c5aa49031c931182d59
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3711076
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1017843}
fantasai added a commit that referenced this issue Oct 12, 2022
@fantasai
[css-values-3][css-values-4] Clarify that font-relative lengths are m…
f69413e 
…easured in absence of shaping. #5498
@fantasai
Copy link
Collaborator

fantasai commented Oct 12, 2022 •
edited
Loading

@litherum @kojiishi Added

The [=font-relative lengths=] are calculated in the absence of shaping.

Let me know if you would like some different phrasing.

mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@kojiishi @copybara-github
[ic-unit] Add |IdeographicFullWidth|
0c2aaa8 
This patch adds |FontMetrics::IdeographicFullWidth|, which
provides the value for the [`ic` unit].

The spec is not very clear as to how to compute the advance,
but further discussion[1] clarified that it should not
require shaping. This is confirmed to be in sync with the
current Gecko and WebKit implementations.

[`ic` unit]: https://drafts.csswg.org/css-values-4/#ic
[1]: w3c/csswg-drafts#5498 (comment)

Bug: 937101
Change-Id: Ia194c08bb93d84b6215b1c5aa49031c931182d59
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3711076
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1017843}
NOKEYCHECK=True
GitOrigin-RevId: 1d6f40f434ed7bed90078583695d075f6010e754
@fantasai fantasai closed this as completed Nov 3, 2022
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 Editor Discretion Commenter Response Pending css-text-4 css-values-3
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@frivoal @fantasai @litherum @faceless2 @emilio