Re: Comment on SVG 19991203

Steve,

At 07:40 AM 2/1/00 +0000, Steve Lay wrote:
>
>Firstly, may I congratulate the working group on a much needed specification!

Thanks.

Regarding your comment below, if and SVG drawing is rendered on a pixel
device (which is everything that I know of today) and the drawing is
position at the top/left of the rendering area, then the origin of SVG's
initial coordinate system is at the corner of this rendering area at the
top/left corner of the first device pixel.

But SVG is designed to be resolution-independent. Theoretically, you
shouldn't care about where pixels are relative to the SVG coordinate system
or how big they happen to be. In reality, this actually works pretty well
if antialiasing techniques are used.

Regarding the example from section 7.3: The reason why the lines have been
pushed inside by 1.5 units has to do with clipping, not pixelization.
Typically, there is an automatic clipping path created around the bounds of
a 'svg' element. If the lines were not pushed in by 1.5 units, then the
stroke width would be clipped at the bounds of the 'svg' element. Thus,
only half of the stroke width would be visible.

It very well could be that this example supplies too much confusion. I'll
make sure that this example gets reviewed before we go final with the
specification. Maybe there is a way to fix the example or maybe we need to
document the current example better or maybe just eliminate the example.

Thanks for the feedback.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated


>
>My comment/question is to do with the definition of a pixel that appears in
>chapter 7.  In particular, I'm concerned about the alignment of pixels to
>the co-ordinate system.  The specification makes no specific mention of
>this issue but the example at the beginning of 7.3 appears to favour an
>abstract model in which co-ordinates align between pixels (like QuickDraw).
>
><svg width="300px" height="100px">
><desc>Example InitialCoords - SVG's initial coordinate system</desc>
><g style="fill:none; stroke:black; stroke-width:3">
><line x1="0" y1="1.5" x2="300" y2="1.5" />
><line x1="1.5" y1="0" x2="1.5" y2="100" />
></g>
>
>This example will clearly encourage people who wish to draw lines one-pixel
>thick along the top boundary of the viewport to use commands such as:
>
><line x1="0" y1="0.5" x2="300" y2="0.5" />
>
>I have no objection to this but I do feel that some notes in this section
>on turning real valued co-ordinates into co-ordinates suitable for an
>integer based graphics package are important.  People used to using
>integer-based graphics packages may not spot the use of "1.5" (or even the
>stroke width) in your example and the diagram appears to fudge the whole
>issue by simply drawing red squares with the following co-ordinates and
>labelling them as indicated:
>
>(x=0, y=0, w=3, h=3) is labelled (0,0)
>(x=297, y=0, w=3, h=3) is labelled (300,0)
>(x=0, y=97, w=3, h=3) is labelled (0,100)
>
>Which weren't even the points that were drawn.  I had to go away and look
>up the default line-cap attribute in order to work out what was going on.
>I think this diagram encourages people to draw boundaries as if pixels are
>centered on co-ordinates which is clearly not what is intended (given the
>origin of the viewport at 0,0 and not -0.5,-0.5).
>
>Keep up the good work.
>
>Steve Lay
>
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>mail:  ITAL Unit             email: S.W.Lay@ucles-red.cam.ac.uk
>       UCLES                 phone: (01223) 552673
>       1 Hills Road            fax: (01223) 552590
>       Cambridge
>       CB1 2EU
>       United Kingdom
>
> www:  http://ital.ucles-red.cam.ac.uk/
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>

Received on Tuesday, 1 February 2000 20:04:53 UTC