Created attachment 188015 [details] 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.
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.
Created attachment 188022 [details] Updated testcase - we should not paint horizontal lines.
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.
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.
(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 :)
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 :)
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.
Safari, Firefox, and Chrome all display horizontal lines. I'm not sure there is a bug here.