W3C home > Mailing lists > Public > www-svg@w3.org > September 2011

Re: bounding box of inline SVG

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 12 Sep 2011 21:31:39 -0700
Message-ID: <CAGN7qDCKWNZUxkFniwLTwY9U+__9jerqCosYT1x+QRJVgD1jZw@mail.gmail.com>
To: Jeremie Patonnier <jeremie.patonnier@gmail.com>
Cc: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, www-svg@w3.org
On Mon, Sep 12, 2011 at 2:30 PM, Jeremie Patonnier <
jeremie.patonnier@gmail.com> wrote:

> 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)
>
>
I agree. The third option what you would have to do currently if your SVG's
bbox doesn't have (0,0) as its xMin/yMin.
If you were to move the path, you would have to update the viewBox and the
CSS transform on the DIV.
If there was other content, the width/height would have to be updated as
well. This would be a lot of work...


> 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
>>
>
Received on Tuesday, 13 September 2011 04:32:19 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT