W3C home > Mailing lists > Public > www-svg@w3.org > February 2012

Re: path data attribute lacks units!

From: Brian Birtles <birtles@gmail.com>
Date: Thu, 09 Feb 2012 09:01:23 +0900
Message-ID: <4F330CD3.3040104@gmail.com>
To: www-svg@w3.org
(2012/02/09 2:09), Sebastian Kuzminsky wrote:
> The problem is that Path data does not have user-specifiable units.  It is always represented in "px" user units, which have undefined size.  We're currently assuming that the SVG will be viewed/used in a 90 dpi environment, and that is getting us past this obstacle, but it seems an unsafe assumption to make.  We'd much rather have proper units on path data, and remove this ambiguity.

Hi Sebastian,

Thanks for your question and encouragement. There will be others on this 
list who can answer this much better than I but I believe the approach 
most people take is to consider SVG's values that lack a unit 
identifier, "user units", as logical units and then scale the logical 
units to physical units at the <svg> root using a viewBox combined with 
a width and height.

For example:

   <svg width="3cm" height="4cm" viewBox="0 0 300 400">
     <rect width="100" height="50"/>
     <path d="M30 40.... " />

In this example, 1 SVG user unit will be scaled to 0.1mm. The user agent 
will try to take care of the mapping between pixels and centimetres so 
that the result is resolution independent.

Note 1: The aspect ratio of the viewBox should match that of the 
width/height or else the scaling will depend on the behaviour of the 
preserveAspectRatio attribute.

Note 2: I say the user agent will "try" to take care of the mapping 
since sometimes that information is not available[1].

Under such an arrangement you don't need to use unit identifiers at all 
except on the root <svg>. Does that suit your requirements?

Best regards,

Brian Birtles

[1] http://www.w3.org/TR/SVG11/coords.html#Introduction, "(highly 
desirable but not required) a real number value that indicates the size 
in real world units, such as millimeters, of a "pixel""
Received on Thursday, 9 February 2012 00:02:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:34 UTC