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

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

Received on Monday, 7 October 2013 11:41:11 UTC