Re: bounding box of inline SVG

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.
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. 


> 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. 

>
> > 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.  


> > 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.
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.

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 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)


Olaf

Received on Tuesday, 13 September 2011 09:35:08 UTC