- From: Tavmjong Bah <tav.w3c@gmail.com>
- Date: Thu, 09 Jan 2014 15:48:55 +0100
- To: Erik Dahlström <ed@opera.com>
- Cc: 'www-svg' <www-svg@w3.org>, Brian Birtles <bbirtles@mozilla.com>
On Thu, 2014-01-09 at 13:46 +0100, Erik Dahlström wrote: > On Thu, 09 Jan 2014 03:37:41 +0100, Brian Birtles <bbirtles@mozilla.com> > wrote: > > ... > >> Issue 3: What bounding box to use for (b)? > >> Proposal: The stroke bounding box as defined in SVG2[2] (which, by the > >> way, includes markers). > >> Rationale: It's nearly always more desirable than the geometric bounding > >> box, at least for simple use cases which is what (b) is aimed at. > > > > Alex Bell agrees to using stroke bounding box.[2] No other feedback yet. > > Note: "(b)" refers to "SVG fragment identifiers" when an svg is referenced > from somewhere. > > I would prefer this to be taking into account all possible things that > extend the rendered shapes, and I'm not sure the stroke bounding box > considers anti-aliasing. I would not expect that to be clipped away > because then things at the edges could potentially look bad. Using the > stroke bounding box will just give us the same issue later on, and there's > also clipping, masking and filters that can affect the resulting "rendered > bbox". I think at least the option to use the 'geometric' bounding box should be offered. Think of a a triangle with a moving dash pattern on the stroke, as the dashes move, the 'stroke' bounding box changes. See the animation at the bottom of: http://tavmjong.free.fr/blog/?p=821 > An alternative might be to add support for overflowing the svg viewport, > though this may only provide the desired result in some cases. Svg used as > a tiled css background-image is one example where it might be problematic, > or when there's overlapping content and you need the svg to be fully > contained. I would support this alternative. Tav
Received on Thursday, 9 January 2014 14:49:26 UTC