Re: [csswg-drafts] [css-text-3] #8649 Describe ink overflow from hanging glyphs (#9842)

> I don't think the advice provided by this PR is entirely accurate though, and some of the claims it makes lack evidence (might be true, but not obviously so). For instance:
> 
> > Because [=hanging glyphs=] are considered [=ink overflow=], and hence are not included in [=inline box=] geometry, there is no straightforward way to measure their extent
> 
> This doesn't follow from that. Being defined as ink overflow does not make it easier or harder for the UA to measure there extent. There are things that are included within the definition of ink overflow for which determining the extent is hard (as the extend may theoretically be infinite), but this doesn't seem to be one of them, and anyway, which type of overflow it gets included in makes no difference to that problem.
> 
> Or maybe you meant not easy for an author to measure the extent? Not sure that's true either. modulo the subtleties of sub-pixel rendering, glyphs have sharp edges. They're not like blurs or gradients, where there can considerable uncertainty as to where they end. As you point out in a subsequent paragraph, authors can visually measure the extent of the overflow. Sure, they cannot simply auto-size a box to contain the ink-overflow, and ask an API for the size of that box, but doesn't mean the answer to the question is elusive.

Would you be OK with rephrasing it as "no straightforward way for authors to programmatically measure their extent"? That is what I meant to convey.

> > However, any two conforming browser implementations, when rendering a given piece of text content using a given font in a supported format […] will produce identically-sized [=ink overflow rectangles=], within a 2-pixel margin of error.
> 
> * [citation needed] :)

This is based on conversations with @kojiishi and @drott.

> * even if it is true, authors cannot generally rely on the same font being used, so there can be more than 2px of difference

This is perhaps an argument in favor of web fonts.

> * user styles or zoom can affect the font size, so there can be more than 2px of difference

I'm not sure that's true, based on my conversations with @kojiishi and @drott.

> * at the moment, hanging glyphs are limited to...

This PR gives an example of glyph overhang from an italicized 'f':

   <div class="figure" style="margin:0; font-size:10rem; font-family:garamond; font-style:italic">
     <span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span><span style="vertical-align: top;">f</span><span style="display:inline-block; width:1ch; height:1lh; background:green; opacity:0.5"></span>
   </div>

Regarding CJK typography: I would like to avoid including these kinds of specifics because it's impossible to create an authoritative list. I mean for the takeaway to be: text can result in ink overflow, the extent of which is not directly measurable via web platform API's; but there *is* a practical way to achieve de facto interoperability of ink overflow extents from text.
 
> Whether we should add advice at all to the spec, and what that advice should be, is something that should be discussed as a separate issue from #8649, and get WG consensus before we dive into a specific pull request.

I opened #10066 to discuss.

-- 
GitHub Notification of comment by szager-chromium
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/9842#issuecomment-1992749312 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 12 March 2024 23:48:29 UTC