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

Clarifications and examples needed for Section 7.10 : [Re: Are ce ntimeters 2nd Class and Pixel based width]

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Tue, 19 Dec 2000 12:42:44 -0700
Message-ID: <B2C1451A181BD411B88A00E018C1C19C08A94F@THOR>
To: "'svg-developers@egroups.com'" <svg-developers@egroups.com>
Cc: "'www-svg@w3.org'" <www-svg@w3.org>
I'm sorry, I'm baffled by section 7.10 in the draft and it seems like a better example would be extremely helpful.   I also read the "Are centimeters second class units?" thread on www-svg@w3.org and
the "Pixel based width thread" on svg-developers@egroups.com and things only got worse.

I going to start with a few premises:

a) The author wants to have (almost all) user units represent a real world (not device) dimension.  For example, I may want to establish my user units so that 1 user unit represents 1 meter so that I
could directly take positional data in meters and put it in my SVG file without concern over the screen size, resolution, etc.  User units do not even have to conceptually represent lengths.  For
example, I may be plotting temperature vs time and my user units are established so 1 in the y direction represents an increase of temperature 1 K and 1 in the x direction is an increase of 1 second.

b) The author wants to be able to specify the dimensions of some things (particular line widths, font-sizes) so that they correspond to device measurements like pixels, page position in cm, or
font-size.

c) Zoom and transform invariant widths, font sizes, etc would be nice optional behavior, but should not be the default behavior and are not essential.

d) CSS unit are implemented by assigning each suffix a conversion factor to user units, when a CSS suffix is encounted, the preceding value is multiplied by the conversion factor.  The conversion
factors are constant within a some scope (I think the scope should be viewport but I'm not sure that the spec is clear on this), but may vary from scope to scope.


Unfortunately, since no one has implemented the November spec in regards to this yet, I can't test these scenarios to see what others interpretations are.

A Scenario:

A map of a 10 Km x 10 Km region where 1 user unit represents 1 meter on the ground displayed in a 20 cm x 20 cm SVG drawing with 12 pt font and 1 pixel line width.

This could be represented by:

<svg width="20cm" height="20cm" viewBox="0 0 10000 10000" style="stroke-width:1px; font-size:12pt" preserveAspectRatio="none">
	<!--  middle road's north curb -->
	<d path="M0 4995 L 10000 4995"/>
	<!--  middle road's south curb  -->
	<d path="M0 5005 L 10000 5005"/>
</svg>

[Note: I'll going to try to mark any "device" dimensions with an asterisk]

My intention is that the display area on the device in 20 cm* x 20 cm*, a user unit = 0.002 cm*, and that a pixel, assuming 20 cm* = 1000 pixels, is 10 user units (or 10m on the ground).  Two 1-pixel
(0.02 cm*)
lines should be drawn from 10 cm* (+/0.02 cm*) below the upper left corner to 10 cm* below and 20 cm* to the right of the upper left corner.

That would seem to conflict with the statement:

A px unit and a user unit are defined to be equivalent in SVG. Thus, a length of "5px" is the same as a length of "5".  

and with all the "1pt == 1.25px == 1.25 user units"

The discussion in the following paragraphs use the term "real world units" when they really mean "device units" or "display units".

What I would suggest is that:

1. That the conversion between pixels and user units be set and scoped by viewport creation elements.

2. Conversions from units such as pt, cm, etc, be accomplished by using a device-constant conversion between the unit and pixels and the in scope conversion between pixels and user units.  Conversions
between em's should only be slightly more complicated.

3. The conversion is unaffected by transforms.

<svg width="20cm" height="20cm" viewBox="0 0 10000 10000" style="stroke-width:1px; font-size:12pt" preserveAspectRatio="none">
	<text x="0" y="2000">Displays as 12pt</text>
	<g transform="scale(2)">
		<text x="0" y="2000">Displays as 24pt</text>
	</g>
</svg>

In both cases the font-size is converted to the same user units (roughly 200) so it is equivalent to:

<svg width="20cm" height="20cm" viewBox="0 0 10000 10000" preserveAspectRatio="none">
	<text x="0" y="2000" font-size="200">Displays as 12pt</text>
	<g transform="scale(2)">
		<text x="0" y="2000" font-size="200">Displays as 24pt</text>
	</g>
</svg>

4. Proportional zooming is implemented by manipulating transforms.

5. Differential zooming is implemented by manipulating viewBox's.

If you want to have line widths, font-size, etc retain their same device dimensions while the real world sizes change, manipulate the viewport which will cause the pt or cm's to user units conversion
factors to change.

<svg width="20cm" height="20cm" viewBox="0 0 10000 10000" preserveAspectRatio="none" style="font-size:12pt">
	<text x="0" y="5000">Middle Road</text>
	<!--  middle road's north curb -->
	<d path="M0 4995 L 10000 4995"/>
	<!--  middle road's south curb  -->
	<d path="M0 5005 L 10000 5005"/>
</svg>

No matter what the viewport, the Middle Road label is still displayed as 12pt.  If I change the viewBox to "0 4970 0 5030", the separate curbs are now visible, but the label is still 12 pt.

I would appreciate any comments.  This seems like a pretty reasonable approach to me (of course, everybody thinks their suggestions are), should avoid the messy complexity of the previous
implementations.  Maybe that is what the spec now says, but I can't really figure it out.
Received on Tuesday, 19 December 2000 14:49:26 GMT

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