1149080 - objectBoundingBox units should be based on frame's border box, not visual overflow region

Status: RESOLVED DUPLICATE of bug 1067355

(Core :: SVG, defect)

Description

[Jonathan Kew [:jfkthame]]

Attachment: clip-path testcase with visual overflow

When an SVG clip is applied to non-SVG content, and the clip-path is specified using clipPathUnits="objectBoundingBox", we use a "bounding box" based on the element's visual overflow region; see nsSVGIntegrationUtils::GetSVGBBoxForNonSVGFrame.

I think this is probably wrong. The text at [1] seems to make it clear that the "bounding box" can not be assumed to include all pixels painted by the object.... "The bounding box is computed exclusive of any values for clipping, masking, filter effects, opacity and stroke-width."

(Nor is it necessarily a tight bounding box; note that "The calculations assume that all glyphs occupy the full glyph cell. For example, for horizontal text, the calculations assume that each glyph extends vertically to the full ascent and descent values for the font." So the concept of "bounding box" here is not concerned with ink but with the geometry used for layout purposes.)

So it's more like a "geometry bounding box" than an "ink bounding box". While the difference will often be negligible, there are cases where relying on the visual overflow region may give significantly different (and unexpected) results.

See attached testcase for an example on OS X (it's dependent on the Zapfino font). I think this example would be expected to render both gray-bordered <div>s the same, painting the green background in the lower-left quarter. But the visual overflow regions resulting from Zapfino swash glyphs will disrupt this.

[1] http://www.w3.org/TR/SVG/coords.html#ObjectBoundingBoxUnits

Comment 1

[Robert Longson [:longsonr]]

Is this the same as bug 1067355

Comment 2

[Jonathan Kew [:jfkthame]]

Yes, I think so.