W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2014

Re: Feedback on the bbox changes

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 10 Feb 2014 16:29:15 +1100
Message-ID: <52F863AB.2040205@mcc.id.au>
To: Erik Dahlström <ed@opera.com>
CC: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Erik Dahlström wrote:
> Please update this to align with
> http://www.w3.org/TR/SVGTiny12/coords.html#BoundingBox (which uses the
> tightest fitting bbox for paths). It's possible to compute these tight
> bboxes in the "fast" way (aka the convex hull of the control points) in
> most cases, and to employ a slightly more expensive algorithm only when
> necessary. We never found this to be a bottleneck in Presto.

Done this now.

> Also, the term "bounding box" should be linked to the new algorithm,
> https://svgwg.org/svg2-draft/intro.html#TermBoundingBox.
> http://www.w3.org/TR/SVGTiny12/intro.html#TermBoundingBox could probably
> just be copied across with a few minor changes to the links.

And this.

> Please add a term 'glyph cell' and state for bbox whether this is a
> tight cell around the glyph geometry or not. Previously this has been
> assumed to be a "full glyph cell", see e.g
> http://www.w3.org/TR/SVGTiny12/coords.html#BoundingBox.

I've copied over the wording in that section about the full glyph cell. 
  I'll wait until text.html gets rewritten some more before ensuring 
glyph cell has a term I can link to.

> For the bbox algorithm for container elements and 'use', the same values
> for space, fill, stroke, markers are propagated to the (shadow) children
> of that element. But I'm wondering, is there ever a chance you'd want to
> apply some values only to the parent, and not to the children?

There's a possibility.  Same for if there's just a descendant <g> that 
you want to treat differently, I think, though.

> For the embedded elements and foreignObject, have we ruled out using css
> for the size/position instead/in addition to plain attributes?
> Especially because most of these elements have not been in svg before
> (at least not in this form), we don't yet have to worry about legacy
> content that would break. In html it is possible to set the size using
> css, so why not in svg?

I don't think we've discussed it, except in the context of other 
elements like 'rect', where it brings up the whole "what do we do with 
'x' and 'y' issue".
Received on Monday, 10 February 2014 05:29:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:55 UTC