- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 12 Sep 2011 21:31:39 -0700
- To: Jeremie Patonnier <jeremie.patonnier@gmail.com>
- Cc: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, www-svg@w3.org
- Message-ID: <CAGN7qDCKWNZUxkFniwLTwY9U+__9jerqCosYT1x+QRJVgD1jZw@mail.gmail.com>
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 UTC