Re: bounding box of inline SVG

2011/9/13 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

> Rik Cabanier:
> > 2011/9/12 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
> >
> > > Hello,
> > >
> > > what is the idea, how this should work to calculate it automatically,
> > > if neither the author of the SVG nor the embedding document gives
> > > information
> > > about the intended size of the graphics?
> >
> > If the graphics use absolute coordinates, you can calculate their
> bounding
> > boxes.
>
> Well from my authors point of view - almost all SVG documents have a
> viewBox
> and most have no width and height, therefore there are only local units
> used in my documents and the relation between the available viewport and
> the viewBox determines the scaling.
>
> As already mentioned, current viewers do not manage absolute units
> like cm, mm properly and some do not manage em or ex either for width and
> height, therefore no good idea to use them.
>

true. However, the coordinates in SVG correspond with 'px' in CSS.


> In the few cases of SVG used in XHTML, I think I used a div container
> styled
> and sized with CSS to embed the SVG content. Either it is sized relative
> to the available viewport or - what is typically suboptimal within an XHTML
> environment - in px units - here one practically has to separate XHTML text
> from inline graphics again to manage the coexistence in viewports of
> different sizes somehow.


OK. So a DIV container with sizing took the place of width/height. So, if
you change an SVG element, you would have to update the styling of this DIV.


> > Then by unionizing all the bboxes and account for the transformation
> > matrices, you would come up with the bounding box of the svg element
> > itself. If they use relative coordinates (like '%'), you would calculate
> > the absolute coordinate which allows you to calculate the bbox.
>
> At least for most of my content, the bounding box of all graphical elements
> is not directly related to the viewBox. This has something to do with
> aesthetics and intended impressions, and is therefore some kind of
> subjective, not simple to calculate - therefore it is already a challenge
> to write (PHP)-scripts, that generate SVG documents automatically
> within an acceptable viewBox. Or vice versa to calculate an acceptable
> viewBox automatically for some generated content. At least for many
> documents in my art gallery there is no simple algorithm to calculate
> such a viewBox properly and completely perfect.
> Therefore I don't think, that an automatically calculated viewBox from
> a bounding box will be very useful for many more complex SVGs.
> For serveral of my documents (presenting for example planetary
> systems or troops of moving objects), such a behaviour would be
> pretty contraproductive of even stupid - for them one would need
> to calculate the maximum of the bounding box over an infinite
> presentation time to get a somehow useful result, one still had to add
> some additional margin for stroke and stroke-linejoin, stroke-linecap etc
> to get something meaningful.
>

the viewBox is updated every time there is a change to your SVG DOM.
There is no need to calculate a maximum.


>
> >
> > > Many of my SVG documents have parts of graphical objects out of the
> > > viewBox and for several of them it depends on the preserveAspectRatio,
> > > what is the intention to display, if the aspect ratio of the viewport
> > > does not fit to the
> > > viewBox. Obviously, if the embedding document does not provide
> > > information about size or at least aspect ratio of the viewport, I
> cannot
> > > see how to calculate this automatically.
> >
> > With no 'width' or 'height', viewBox becomes meaningless.
> > It would also need to be calculated on the fly. Not to change the aspect
> > ratio but to change where the (0,0) point will be located.
> >
>
> No, currently if there is no width and height, it means 100%, what is
> typically pretty useful for SVG documents with nothing embedding
> them (typical use case for me) or if the embedding construction has
> a defined size (that is my typical approach to embed it in
> XHTML or XML). If authors provide a size for the embedding
> construction, it should fit perfectly.
>
> But ok there is still the problematic situation, if authors provide no
> information in the embedding construction and no width and height
> in the SVG. In such a situation it is not obvious, which size is
> useful for display. The algorithm to determine the size from CSS
> is not necessarily a useful answer, if no CSS is used at all.
> Therefore the format of the embedding construction should define,
> how to calculate the size in such a problematic case.
> But of course, for the case this did not happen, for example for
> arbitrary XML embedding some SVG content, SVG should define
> this, for example: 'For no width and height use 100% of the available
> width and determine the height according to the viewBox. Without
> viewBox use the same height than width'.  This still causes problems,
> if the viewer just does not know the XML-format and assumes it
> to be arbitrary. For example for LML I defined some rules how to
> determine the size, if an author gives no indication about this.


Again, just mapping the SVG coordinates to straight 'px' would resolve this.


>


> > > On the other hand, for an author of the embedding document it is
> > > typically simple to provide information about the available viewport,
> as
> > > well as for a browser to know the viewport size, if the SVG is not
> > > embedded at all. Or if size matters for the SVG, it should be simple
> for
> > > the SVG document author to provide information about width and height
> > > (apart from the practical problem, that typical browser do not manage
> to
> > > display absolute sizes properly anyway).
> >
> > I believe that in the future, the author will typically create the HTML
> and
> > the inline SVG.
> > We shouldn't think about them as separate worlds.
>
> Concerning coordinates and how to arrange/position content these
> are quite different worlds. In XHTML the text is presented and arranged
> in an optimised way for the preferred font-size indicated by the user and
> the available width of the viewport to get always good readability of text.
> In SVG all elements are positioned as fixed graphics, but the
> user can scale and zoom into the document to see more details, what
> is typically suboptimal for larger amounts of text, where the XHTML
> approach is much better.
>
> I think, these models are so different, that there is no or no trivial
> solution to have both in one document. If you start with XHTML,
> you will always need some kind of somehow sized box to put the
> graphics in and the text can flow around or before and after in a
> flexible way.
>

I don't see why they are different.
I agree that things used to be different in HTML, but with the introduction
of CSS transforms, that is no longer the case.
HTML with 'display:block' and CSS transform is almost the same as SVG
transforms.

I'm not proposing of getting rid of the box model. An SVG circle will still
create a rectangular knockout region.


> Starting with SVG, you need always a somehow positioned
> box (for XHTML or textArea in tiny 1.2) to contain text with
> automatic arrangements with less relevant importance of graphical
> appearance - and you have to take into account problems with
> suboptimal readability of such texts, dependent on magnification.
>

Yes, text and SVG is a problem.
I personally think that reflowable text is better done in HTML...


>
> There should be some defined way to get some output, if
> authors provide no information about sizes for SVG in XHTML,
> but typically the SVG content will be more complex than single
> rectangles, ellipses or circles, therefore one can recommend,
> that authors should always provide information about the
> intended viewBox (and if this matters, about the intended
> size, with the limitation in mind, that viewers typically cannot
> realise absolute sizes properly). Obviously, if there is a
> need to display absolutely sized graphics, there is an
> urgent need as well to improve the capabilities of viewers
> to display absolute sized graphics properly (units cm and mm
> and to fix the related problem in CSS2.1, that currently helps
> developers of viewers only to obfuscate the display of absolute units).
>

I agree that there are many cases where you want your content to scale with
the browser's page size.
An author could do this by calculating a matrix that is applied to the SVG
or we can introduce a new keyword...


>
> > (I think there was
> > consensus about this at the Seattle F2F.)
> > If I move an inline SVG element, I don't want it to be clipped by the
> > parent SVG header unless I specified a 'width'/'height'
>
> You can do this right now.
> You just have to provide a viewBox, that is large enough or
> you can animate the viewBox as well to catch moving objects
> all the time :o)


Thanks for the feedback!
I'm going to think about this some more.

Rik