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

I'm not sure that the use cases are compelling enough for there to be
enough support for allowing lengths in paths.

But if it were to be considered, perhaps an option would be to support
CSS's calc() for all Lengths and for path.
If you only allowed length values in path definitions via a calc() it might
simplify the parsing.

<path id="diamondInTheMiddle" d="M calc(50% - 10), calc(50%) l 10, -10
10,10, -10,10 -10,-10 Z"/>

Paul



On 9 October 2013 13:54, Dugan Knoll <ddknoll@gmail.com> wrote:

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