Re: Fwd: SVG Path, Polyline, and Polygon data coordinates

I think David and I are seeing the same thing, which is specifically
when "sometimes one wants part of the content to adapt to screen size,
but not all."  In my experience the one path data unit that really
doesn't play well with others is the % unit. There have been a few
cases where I would like to mix fixed units and percents within the
same path.  I see how supporting all of the css units would greatly
complicate parsing and rendering of path data, but maybe it wouldn't
be so bad to only allow percents.

In fact, it may not be necessary to even add percents to polylines and
polygons. These use cases can already be accomplished using a series
of line elements, which support percent for its x1,x2,y1, and y2
attributes.  Adding percent units to path elements could allow greater
flexibility for curved lines and shapes. It should only introduce
minimal parsing and rendering issues, since the percent units could
just be converted to a fixed data point before rendering.

One simple example: a curved arrow that expands based upon the size of
the root svg.  For this curved arrow, you wouldn't want the pointed
end to distort as the svg graphic grows horizontally or vertically,
but the rest of the curve would expand appropriately.

For example's sake, lets draw an arrow starting at the bottom right
corner of an SVG that curves around the bottom up to the pointed end
in the top left corner.  This is how the arrow might ideally be coded:
<path d="M100%,100% C10,100% 10,100% 10,5 L5,10 M10,5 L15,10"/>

Currently, you could roughly accomplish this same graphic using nested
svg elements and coordinate system transformations. As David
mentioned, this solution is messy and does not always work properly.
I think it would be simpler and more effective to allow percents
within the path data.

Would this work for you, David?

Thanks for the response,
Dugan

On Mon, Oct 7, 2013 at 4:40 AM, David Dailey <ddailey@zoominternet.net> wrote:
> I'm not sure. Just this week one of my students ( just learning SVG ) made the same comment as Dugan Knoll. It is a sentiment I have shared on many occasions. Viewboxes are not always the solution, since sometimes one wants part of the content to adapt to screen size, but not all. In http://srufaculty.sru.edu/david.dailey/svg/recent/sliderzoom2.svg the problem is solved by putting <svg> inside <svg> each with its own viewbox, but the hassle is that not all browsers seem to understand nested svg's (look at Safari for Window's horrific response to the above. It seems like whatever code implementers have to handle alternative units for rect, circle, etc. ought to translate pretty well to path. Agreed that path is tricky, and I completely agree about how the extremely short notations -- I wish the programs that generate SVG as output wouldn't use them since they are nasty to try to parse with Javascript.
>
> I remember with great fondness the way that the ASV viewer allowed for both pan and zoom on an SVG, without having to zoom on the whole window the way that most modern viewers do it.
>
> Regards
> David
>
> -----Original Message-----
> From: Dr. Olaf Hoffmann [mailto:Dr.O.Hoffmann@gmx.de]
> Sent: Monday, October 07, 2013 4:24 AM
> To: www-svg@w3.org; ddknoll@gmail.com
> Subject: Re: Fwd: SVG Path, Polyline, and Polygon data coordinates
>
> Hello,
>
> I think, the simpler and better approach you can already use in SVG tiny 1.1 is to use no units at all in the content, but using a viewBox and if required use only units for width and height of the svg root element.
> This scales the complete graphics and you do not have to worry about units within the content at all.
>
> Units in path data may create conflicts with scientific notation, the current commands or commands added in the future, respectively the interpretation of such data will get pretty complex with additional units - resulting maybe in a slowdown for the presentation of path data and everytime a command is added to SVG paths or a unit is added to CSS one has to care about conflicts again, path data parsers have to be changed again with the risk of more bugs than before ...
>
> Already now some viewers have problems to get every possible combination of path commands right and there are even more problems with units or constructs with mixed units.
> Typically authors can avoid a lot of trouble not using units in the content at all. Concerning path data they can avoid trouble, if they only use 'usual' combinations instead of extreme short notations.
>
> Olaf
>
>
>



-- 
Dugan Knoll / Web Developer

319-929-6063/ duganknoll@gmail.com

www.duganknoll.com

Salem Health Office: 503-561-2768
890 Oak Street SE Salem, OR 97301



This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination,
distribution, copying or the taking of any action in reliance on the
information herein is prohibited. E-mails are not secure and cannot be
guaranteed to be error free as they can be intercepted, amended, or
contain viruses. Anyone who communicates with us by e-mail is deemed
to have accepted these risks. Company Name is not responsible for
errors or omissions in this message and denies any responsibility for
any damage arising from the use of e-mail. Any opinion and other
statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the
company.

Received on Wednesday, 9 October 2013 01:18:55 UTC