Skip to content

[css-inline-3] Define rounding behavior of lines in block direction for leading-trim #4045

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

Open
kojiishi opened this issue Jun 20, 2019 · 5 comments
Labels
css-inline-3 Current Work

Comments

@kojiishi
Copy link
Contributor

Forking from #3978 (comment)

@litherum proposed to consider defining rounding behavior for the leading-trim property, and possibly for other future properties.

@kojiishi kojiishi added the css-inline-3 Current Work label Jun 20, 2019
@kojiishi
Copy link
Contributor Author

/cc @fantasai

@kojiishi
Copy link
Contributor Author

kojiishi commented Jun 20, 2019

ried to look for the past discussions/investigations but could not find one, so from my memory.

I think it's best for the font rendering engine to make the baseline (glyph origin) at the pixel boundary, so rounding should be applied to the baseline position, not to each metrics.

In terms of the direction to round to, IIRC, in a discussion with someone in Edge team, he recommended to floor descent. i.e.; among the two options:

used-ascent = floor(ascent), used-descent = ceil(height) - used-ascent
used-descent = floor(descent), used-ascent = ceil(height) - used-descent
that someone preferred option 2. @atanassov do you have ideas?

I think @dbaron and @eaenet have expertises on this topic, any advices are appreciated.

Note, the above two options become a little more complex when we start sub-pixel block positioning. In that case, we would like to snap the baseline (glyph origin) to physical pixel instead of ceiling height. We had some discussion on this, but not really started yet.

A bit of concern is that maybe standardizing too much details of this can prevent innovation, but we can probably start from saying like "if UA is going to round, do this direction"?

@kojiishi
Copy link
Contributor Author

Found the feedback: crbug.com/938612. The designer says Blink floors half-leaging on the over side while other apps round it, but it's not clear whether the reporter knows the exact algorithm of other apps or just observing differences.

@dbaron @jfkthame do you know how Gecko round it?

@SashimiEthan
Copy link

SashimiEthan commented Jul 2, 2019

Hey guys, before giving any suggestions, I ran into a question. Since I'm not an expert on the technical aspect of this, please bear with me if the question is silly.

Does this have anything to do with the font? I tried other fonts, it seems like Blink is only flooring for Segoe, but not for other fonts that I tried? I calculated the baselines of several fonts in the table below when the font size is set to 14px. The line heights are set to around 20px to make sure the rounding result is not equal to the flooring result.
Group 10

And please see the screenshot below for the comparison between Figma & Chrome (an engineer I talked to at Figma confirmed they are using rounding). Interestingly Segoe is the only one that seems to be floored? It makes me wonder if the font itself has anything to do with it?
Screen Shot 2019-07-16 at 5 04 45 PM

@fantasai
Copy link
Collaborator

CC @jfkthame

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-inline-3 Current Work
Projects
None yet
Development

No branches or pull requests

3 participants