W3C home > Mailing lists > Public > www-svg@w3.org > December 2000

Re: Are centimeters second class units?

From: Jon Ferraiolo <jferraio@Adobe.COM>
Date: Mon, 11 Dec 2000 20:37:18 -0800
Message-Id: <4.2.2.20001211202656.025e7940@mailsj.corp.adobe.com>
To: "Jon Ferraiolo" <jferraio@Adobe.COM>
Cc: Elliotte Rusty Harold <elharo@metalab.unc.edu>, www-svg@w3.org
Elliotte,
I am following up with some sample code:

<svg x="0" y="0" width="1cm" height="1cm"
         viewBox="0 0 1000 1000"
         style="overflow:visible">
   <rect x="1000" y="1000" width="3000" height="3000" style="fill:red"/>
</svg>

The above code is just one way to approach the problem. I'll explain what 
the above code does:

The first line:
     (a) specifies (via the 'width' and 'height' attributes) a viewing 
region that is 1cm by 1cm
     (b) specifies (via the 'viewBox' attribute) that user coordinate (0,0) 
maps to the top/left of the viewing region and user coordinate (1000,1000) 
maps to the bottom right of the viewing region (i.e., the location that is 
1cm down and to the right of the origin)
     (c) specifies (via overflow:visible) that there should be no automatic 
clipping at the bounds of the viewing region

Note that the <rect> draws a square with each side 3cm long.

Jon

At 04:51 PM 12/11/00 -0800, Jon Ferraiolo wrote:
>Elliotte,
>
>At 08:34 AM 12/11/00 -0500, Elliotte Rusty Harold wrote:
>>I'm still working my way through the SVG spec so I'm hoping I've missed 
>>something and someone will correct me. However, I've been through the 
>>coordinate section several times, and it's beginning to look to me like 
>>pixels have a very privileged place in the SVG universe. In particular 
>>paths, polylines, polygons and probably some other things are all 
>>effectively defined in terms of pixels. The non-dimensional units used in 
>>the points attributes of these elements are all defined in user 
>>coordinates, and user coordinates are pixels. There are a lot of times 
>>when it would be much more convenient to define these quantities in terms 
>>of real-world units like cm or mm or in.
>
>The SVG working group is aware of the fact that paths, polylines and 
>polygons don't allow for CSS units.
>
>
>>I can use various transforms to stretch or compress the coordinate system 
>>and thereby scale the connection between user coordinates and screen 
>>pixels. However, what I want to do, and can't seem to figure out how to 
>>do; is map-like scaling; e.g. I want to say that one kilometer in local 
>>coordinates equals one centimeter on the screen. For instance, if I draw 
>>a line that's 10000 cm long I'd like it to take up 1 cm on the screen. I 
>>can't seem to do this without an intermediate transformation into pixels, 
>>which introduces questions of local screen resolution. I want to specify 
>>everything in terms of units that don't change from one monitor to the 
>>next. The renderer knows how many pixels there are per inch when it draws 
>>a picture. I don't know that, and indeed I can't know that because it 
>>will be different from system to system.
>
>The Adobe SVG Viewer has logic to determine how large a screen pixel is, 
>but it gets its information from the operating environment, whose accuracy 
>varies. Note that most monitors have controls that allow you to squeeze or 
>expand the area on the screen onto which the system draws. These 
>adjustments are not currently known to the Adobe SVG Viewer. Thus, the 
>best you can get is an approximation.
>
>But if you are willing to accept those limitations, then you might be able 
>to do what you want. If you have a standalone SVG file (i.e., not embedded 
>inside an HTML page), then set the 'width' and 'height' attributes to some 
>know dimension in cm. The Adobe SVG Viewer (and other conforming 
>implementations) should attempt to render into a viewport of exactly the 
>size you specify. Then, place a 'viewBox' attribute to achieve the desired 
>scale factor. For example:
>
>    <svg width="20cm" height="30cm" viewBox="0 0 20000 30000">
>
>The picture will be shown in an area that is 20cm-by-30cm, but scaled by 
>1000, so 1000 units in your drawing will render as 1cm on the screen.
>
>
>>There are some related issues I've encountered too. For instance, I tried 
>>to use a viewBox in Batik that had a width and height of 10 each in an 
>>svg element that was 10cm square so that 1 in the user coordinates would 
>>equal 1 cm. However, the user coordinates seemed stuck with at most one 
>>pixel per user coordinate. That is, although each unit in the user 
>>coordinate space should have mapped to roughly 30 pixels, it in fact 
>>mapped to exactly one pixel. In other words the ratio of 
>>pixels/coordinate is less than or equal to 1. I'm not sure if this is a 
>>flaw in Batik or in my understanding of SVG.
>
>I'm not sure I understand. But did you try this in the Adobe viewer?
>
>
>>If SVG really doesn't allow me to describe shapes with arbitrary 
>>precision fixed units of known length like cm and in, rather than the 
>>very ambiguous pixel unit, then it seems seriously underpowered and 
>>unsuitable for many tasks. Some of the basic shapes like rect and circle 
>>let me use real units, but the most fundamental path element does not. 
>>How can I define a path that's a certain number of centimeters long? Any 
>>ideas? Am I missing something here?
>
>I gave one idea above. Does this help?
>
>Jon Ferraiolo
>SVG Editor
>jferraio@adobe.com
>
>>--
>>
>>+-----------------------+------------------------+-------------------+
>>| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
>>+-----------------------+------------------------+-------------------+
>>|                  The XML Bible (IDG Books, 1999)                   |
>>|              http://metalab.unc.edu/xml/books/bible/               |
>>|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
>>+----------------------------------+---------------------------------+
>>|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
>>|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
>>+----------------------------------+---------------------------------+
Received on Tuesday, 12 December 2000 11:59:41 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:19 GMT