Re: bounding box of inline SVG

Hello,

As a Web author, I fully agreed with Rik's vision (especially on how
percentage should be handled).

I wish to give you a bit more insight on how a Web author could benefit of
inline SVG and what behavior he's expected.

In most of the case, using basic shapes or single path are amazingly use
full. Doing the following is an amazing shortcut :

<div>
    <p>Some text</p>
    <rect width="200" height="50" />
    <p>Some text</p>
</div>

In that case, it's really easy, I expect to have a 200x50px rectangle
between the two paragraph like this :

<div>
     <p>Some text</p>
    <svg width="200px" height="50px" viewBox="0 0 200 50">
         <rect width="200" height="50" />
    </svg>
     <p>Some text</p>
 </div>

Now let's imagine something a bit more complex:

<div>
    <p>Some text</p>
    <path d="M10,10 L110,10" stroke="black" stroke-width="1px" />
    <p>Some text</p>
</div>

In that case, I expect something identical to the following:

<div>
     <p>Some text</p>
    <svg width="111px" height="11px" viewBox="0 0 111 11">
         <path d="M10,10 L110,10" stroke="black" stroke-width="1px" />
    </svg>
     <p>Some text</p>
</div>

Ok let's try a trickier case

<div>
    <p>Some text</p>
    <path d="M10,10 L-10,20 L110,10" stroke="black" stroke-width="1px" />
    <p>Some text</p>
</div>

What's happen with that negative value? Well here, there is no good answer.
I can see three behavior here :

First : A truncated viewBox with the path cut off on the left.

<div>
     <p>Some text</p>
    <svg width="111px" height="11px" viewBox="0 0 111 11">
         <path d="M10,10 L-10,20 L110,10" stroke="black" stroke-width="1px"
/>
    </svg>
     <p>Some text</p>
 </div>

Second : A translated shape.

<div>
     <p>Some text</p>
    <svg width="121px" height="11px" viewBox="0 0 121 11"
transform="translate(10)">
         <path d="M10,10 L-10,20 L110,10" stroke="black" stroke-width="1px"
/>
    </svg>
     <p>Some text</p>
 </div>

Third : Something in between.

<div>
     <p>Some text</p>
     <div style="transform:translate(-10px);">
        <svg width="121px" height="11px" viewBox="-10 0 121 11">
             <path d="M10,10 L-10,20 L110,10" stroke="black"
stroke-width="1px" />
        </svg>
     </div>
     <p>Some text</p>
 </div>

In a author point of view all the three answer are understandable if there
are well documented. However, I guess the first one is the easiest to
implement so it could be absolutely ok for authors (even if, on my own, I
find the third answer very appealing)

Hope the will help to understand the authors point of view :)
Cheers
-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

2011/9/12 Rik Cabanier <cabanier@gmail.com>

>
>
> 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.
> 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.
>
>
>>
>> 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.
>
>
>>
>> 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. (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'
>
> Rik
>