109665 2013-02-12 22:32:33 -0800 Stroked patterns paint even when object bounding box is empty 2022-07-15 16:02:16 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 pdr webkit-unassigned bfulgham fmalita schenney zimmermann oldest_to_newest 831648 0 188015 pdr 2013-02-12 22:32:33 -0800 Created attachment 188015 Testcase Patterns do not paint for stroked, horizontal lines, but do paint for almost-horizontal lines. Note: to reproduce you will need to disable your cache. 831673 1 pdr 2013-02-12 23:35:15 -0800 We partially follow the spec here. The pattern should not paint for horizontal lines: "Keyword objectBoundingBox should not be used when the geometry of the applicable element has no width or no height, such as the case of a horizontal or vertical line, even when the line has actual thickness when viewed due to having a non-zero stroke width since stroke width is ignored for bounding box calculations. When the geometry of the applicable element has no width or height and objectBoundingBox is specified, then the given effect (e.g., a gradient or a filter) will be ignored." We are in error when we _do_ show the pattern for horizontal lines! Something is inconsistent because reloading several times makes the pattern show up. 831678 2 188022 pdr 2013-02-12 23:39:33 -0800 Created attachment 188022 Updated testcase - we should not paint horizontal lines. 832348 3 fmalita 2013-02-13 14:31:39 -0800 I think I see the problem. The empty object bounding box logic kicks in only when patternUnits == SVG_UNIT_TYPE_OBJECTBOUNDINGBOX: if (m_attributes.patternUnits() == SVGUnitTypes::SVG_UNIT_TYPE_OBJECTBOUNDINGBOX && objectBoundingBox.isEmpty()) return false; But we are making this decision before updating patternUnits from the element, so we're always seeing SVG_UNIT_TYPE_OBJECTBOUNDINGBOX on the first pass! Later, when the second line gets painted, the pattern attributes get collected and patternUnits is updated to the specified SVG_UNIT_TYPE_USERSPACEONUSE. Then on subsequent repaints the empty bounding box logic no longer kicks in because attributes are up to date. I'll get a patch up tomorrow. 832400 4 schenney 2013-02-13 15:09:58 -0800 Whoa. Slow down folks. The spec is clearly bogus in this regard. It makes no sense at all to suddenly stop drawing a pattern stroke on a line just because it goes horizontal or vertical. The line itself isn't changing, so if it's of zero area when it is in one orientation then it has zero area in any other. And in this context it's area that matters, not the oriented bounding box. Just ignore the spec and draw the patterned line when horizontal or vertical. If you prefer, consider what would happen when the line is animated. If you're rotating a line you don't want it to disappear as it passes through horizontal and vertical. As an aside, the "how would this animate" is an excellent way of deciding what to do with zero-size cases. 832403 5 pdr 2013-02-13 15:14:05 -0800 (In reply to comment #4) > Whoa. Slow down folks. The spec is clearly bogus in this regard. It makes no sense at all to suddenly stop drawing a pattern stroke on a line just because it goes horizontal or vertical. The line itself isn't changing, so if it's of zero area when it is in one orientation then it has zero area in any other. And in this context it's area that matters, not the oriented bounding box. > > Just ignore the spec and draw the patterned line when horizontal or vertical. > > If you prefer, consider what would happen when the line is animated. If you're rotating a line you don't want it to disappear as it passes through horizontal and vertical. > > As an aside, the "how would this animate" is an excellent way of deciding what to do with zero-size cases. Fmalita is fixing the bug so we at least do what we expect we do. In parallel I've emailed www-svg to fix the root issue: http://lists.w3.org/Archives/Public/www-svg/2013Feb/0037.html On IRC they seem amenable, so I have high hopes :) 832408 6 fmalita 2013-02-13 15:20:59 -0800 I'll open a separate bug to track the inconsistent drawing of userSpaceOnUse patterns and leave this one to deal with the inconsistent objectBoundingBox spec :) 832411 7 schenney 2013-02-13 15:31:37 -0800 To be succinct: Think of the users, not the spec. Do what users would expect, particularly for some edge case like this where I can't see anyone depending on the alternate behavior. 1884352 8 bfulgham 2022-07-15 16:02:16 -0700 Safari, Firefox, and Chrome all display horizontal lines. I'm not sure there is a bug here. 188015 2013-02-12 22:32:33 -0800 2013-02-12 23:39:33 -0800 Testcase boundingboxstroke.svg image/svg+xml 563 pdr PHN2ZyB4bWxucz0naHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmcnIHhtbG5zOnhsaW5rPSdodHRw Oi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rJyB2ZXJzaW9uPScxLjEnPg0KPGRlZnM+DQogIDxwYXR0 ZXJuIGlkPSdwJyBoZWlnaHQ9JzEwJyB3aWR0aD0nMTAnIHBhdHRlcm5Vbml0cz0ndXNlclNwYWNl T25Vc2UnID4NCiAgICA8cmVjdCBoZWlnaHQ9JzEwJyB3aWR0aD0nMTAnIGZpbGw9J2dyZWVuJyAv Pg0KICA8L3BhdHRlcm4+DQo8L2RlZnM+DQoNCjx0ZXh0IHg9IjAiIHk9IjIwIj5CZWxvdyB5b3Ug c2hvdWxkIHNlZSBhIGhvcml6b250YWwgbGluZTo8L3RleHQ+DQo8bGluZSB4MT0nMCcgeTE9JzQw JyB4Mj0nMjAwJyB5Mj0nNDAnIHN0cm9rZS13aWR0aD0nMjAnIHN0cm9rZT0ndXJsKCNwKScgLz4N Cg0KPHRleHQgeD0iMCIgeT0iMTAwIj5CZWxvdyB5b3Ugc2hvdWxkIHNlZSBhbiBhbG1vc3QtaG9y aXpvbnRhbCBsaW5lOjwvdGV4dD4NCjxsaW5lIHgxPScwJyB5MT0nMTIwJyB4Mj0nMjAwJyB5Mj0n MTIxJyBzdHJva2Utd2lkdGg9JzIwJyBzdHJva2U9J3VybCgjcCknIC8+DQo8L3N2Zz4= 188022 2013-02-12 23:39:33 -0800 2013-02-12 23:39:33 -0800 Updated testcase - we should not paint horizontal lines. boundingboxstroke.svg image/svg+xml 627 pdr PHN2ZyBwYXR0ZXJuVW5pdHM9J3VzZXJTcGFjZU9uVXNlJyB4bWxucz0naHR0cDovL3d3dy53My5v cmcvMjAwMC9zdmcnIHhtbG5zOnhsaW5rPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rJyB2 ZXJzaW9uPScxLjEnPg0KPGRlZnM+DQogIDxwYXR0ZXJuIGlkPSdwJyBoZWlnaHQ9JzEwJyB3aWR0 aD0nMTAnIHBhdHRlcm5Vbml0cz0ndXNlclNwYWNlT25Vc2UnID4NCiAgICA8cmVjdCBoZWlnaHQ9 JzEwJyB3aWR0aD0nMTAnIGZpbGw9J2dyZWVuJyBzdHJva2Utd2lkdGg9JzEnIHN0cm9rZT0nYmx1 ZScvPg0KICA8L3BhdHRlcm4+DQo8L2RlZnM+DQoNCjx0ZXh0IHg9IjAiIHk9IjIwIj5CZWxvdyB5 b3Ugc2hvdWxkIG5vdCBzZWUgYSBob3Jpem9udGFsIGxpbmU6PC90ZXh0Pg0KPGxpbmUgeDE9JzAn IHkxPSc0MCcgeDI9JzIwMCcgeTI9JzQwJyBzdHJva2Utd2lkdGg9JzIwJyBzdHJva2U9J3VybCgj cCknIC8+DQoNCjx0ZXh0IHg9IjAiIHk9IjEwMCI+QmVsb3cgeW91IHNob3VsZCBzZWUgYW4gYWxt b3N0LWhvcml6b250YWwgbGluZTo8L3RleHQ+DQo8bGluZSB4MT0nMCcgeTE9JzEyMCcgeDI9JzIw MCcgeTI9JzEyMScgc3Ryb2tlLXdpZHRoPScyMCcgc3Ryb2tlPSd1cmwoI3ApJyAvPg0KPC9zdmc+