[css-overflow-3] Specify extent of ink overflow

[chrishtr]

The spec defines ink overflow, but does not specify the extent of it, because some effects in CSS, such as blur radius or box shadow radius, are theoretically infinite.

However, issues such as #8597 and w3c/IntersectionObserver#295 are good reasons to define it, for the purpose of knowing the size of an animated image of a DOM subtree for the purpose of creating a bitmap image, or occlusion testing.

I think we can define it in cases of blur or box shadow in a reasonable way, such as defining the ink overflow to go out to a certain specified standard deviation on its Gaussian shape.

[fantasai]

If it's possible, it would be better to find a way to solve these problems without needing to define the extent of ink overflow. The ink overflow extent isn't something that can be made necessarily interoperable (it depends on where you cut infinite blur etc, but also on what fonts are used, and possibly other effects). So pages that depend on it being a certain value could then break... I'd rather not expose it to the Web if we can avoid it.

[szager-chromium]

If it's possible, it would be better to find a way to solve these problems without needing to define the extent of ink overflow. The ink overflow extent isn't something that can be made necessarily interoperable (it depends on where you cut infinite blur etc, but also on what fonts are used, and possibly other effects). So pages that depend on it being a certain value could then break... I'd rather not expose it to the Web if we can avoid it.

I'd like to press on this issue a bit if I may. There are now a couple of in-development specs that would like to rely on ink overflow extent, and it seems like a legitimately useful thing for any visually rich application environment. It isn't necessary, I think, to specify ink overflow down to the pixel; it would be enough to specify the maximum possible extent of any ink overflow, and by that measure many types of ink overflow are already de facto interoperable and specifiable. Glyph overhang is a notable exception, but perhaps there is a way to specify the maximum possible glyph overhang for a piece of text?

If necessary, we could limit the spec language to the lowest-hanging fruit, i.e., types of ink overflow that are trivial to describe. But I'd like to see if we can do something.

[drott]

From the font technology perspective, for OpenType fonts the maximum glyph extent and maximum per-glyph bounding box should be specified in the HEAD table in the xMin, xMax, yMin, yMax fields. Compare here. This a per-font metrics, as opposed to a per-glyph metric.

But: I am not sure if applications are practically limited by that or restricting glyph drawing to the extents of this top-level bounding box. The individual bounding box of a glyph can still be determined by calculating a bounding box of its glyph shape and thus, a drawing backing surface can be allocated for an individual glyph that's potentially larger than what the font specifies in the HEAD table.

I haven't checked a set of fonts on whether they specify reasonable values in there. So what usually happens if relying on a font metrics that's not been used in a strict way before: We may find many existing fonts having incorrect values in these field and if they were used as a strict restriction, glyphs may be cut off.

CC @bungeman @behdad

[jfkthame]

I've definitely seen fonts with incorrect bounding-box data, though I don't recall the specific examples, and this did result in clipped rendering in some context (which is what led to investigating the font data), while in other environments the glyphs rendered fully.

One point to note with regard to OpenType bounding boxes is that they represent the bounding box of the glyph geometry, but do not account for the fact that at rendering time, the effects of grid-fitting and antialiasing may mean that pixels just outside the "theoretical" glyph bounds are actually affected.

And how do the extents in the 'head' table work in the case of variable fonts? Do they indicate the maximum bounding box under any combination of variation settings, or the bounding box of the default instance? The spec does not appear to provide for applying deltas to these fields, AFAICS.

[drott]

And how do the extents in the 'head' table work in the case of variable fonts? Do they indicate the maximum bounding box under any combination of variation settings, or the bounding box of the default instance? The spec does not appear to provide for applying deltas to these fields, AFAICS.

Good point, the spec says further below:

"Also, in a variable font, [...] the xMin, yMin, xMax and yMax values in this table might or might not encompass the derived glyph outlines for an instance. Also, variation deltas are not provided for these values. If an application requires a bounding rectangle that encompasses the glyphs for a non-default instance of the font, the derived glyph outlines for the instance should be processed to determine a bounding rectangle."

So these HEAD table font-level metrics are not particularly reliable and even unusable for variable fonts. Glyph-level determination of bounding boxes is more accurate, and can take variations into account, but is relatively expensive to compute.

[szager-chromium]

@drott I presume all browsers must already compute glyph overhang extent, for the purpose of determining the size of composited layers, no? If I'm not mistaken, here is where chromium does that.

This code is unfamiliar to me, but it appears that chromium iterates over individual glyph bounds rather than relying on xMin etc. for the font. That probably doesn't bode well for the prospect of specifying glyph overhang interoperably.

I'm quite ignorant about font specifications, so I'm asking the most naive questions, but: can you think of any reliable way to describe the maximum possible extent of glyph rendering for a given block of text and a given font across all browsers?