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

Curt,
In my opinion, this is a good bit of analysis. Most likely you have 
identified a common set of requirements and usage patterns. However, I 
aware of other sets of requirements and usage patterns which would not be 
satisfied by your proposal. In particular, the ability to have object 
attributes (position, size, stroke-width, font-size) invariant across 
zooming was a feature that various users requested early and often as SVG 
was formulated. In fact, that was the requirement that the SVG working 
group attempted to address with its earlier approach to CSS units, not the 
particular capability which you are trying to address.

What the SVG working group came to realize was that: (1) any attempt to 
deal with device units or invariance across zooming which satisfactorily 
addresses everyone's needs was too much to bite off in the SVG 1.0 
timeframe, and (2) the approach that was in early draft specifications had 
major problems, particularly implementability. Speaking for myself and not 
necessarily the SVG working group, after going round and round on the many 
sides of these issues, I am convinced that addressing these needs requires 
a comprehensive, lengthy analysis, followed by implementation and trial, 
followed by adjustments based on feedback. I think we need a whole major 
language revision cycle to pull this off. Therefore, my opinion is that the 
W3C should put more coordinate system and units flexibility on the list of 
items for SVG 2.0. Your analysis is great and should help with that process.

Speaking on behalf of an implementer of SVG, I agree that your proposal is 
likely to be at least a little easier to implement than the earlier rules 
for units, but I'm not sure how much easier, and I'm not sure what the 
impact would be on performance. Special unit processing at viewport 
boundaries was one of the main factors that made implementation difficult 
and which provided a barrier to fast performance.

Jon Ferraiolo
SVG Editor
jferraio@adobe.com


At 12:42 PM 12/19/00 -0700, Arnold, Curt wrote:
>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.
>
>
>-------------------------- eGroups Sponsor -------------------------~-~>
>eLerts
>It's Easy. It's Fun. Best of All, it's Free!
>http://click.egroups.com/1/9699/0/_/68048/_/977255356/
>---------------------------------------------------------------------_->
>

Received on Friday, 22 December 2000 11:30:38 UTC