RE: Comments

Art,

At 09:40 AM 9/30/99 -0500, Hundiak, Arthur wrote:
>I realize what I am trying to do is a bit outside of the main intent of svg
>but hey if it works then great.  Just to clarify the big picture, I'd like
>to end up with an xml file which can be used for at least two things.  The
>first is to feed a steel cutting system.  The second is to allow the user to
>examine the plate using a standard browser (or an application built on top
>of a standard svg viewer). 
>
>For this project, I can work around the issues raised in my email.  But I do
>think that many core SVG users would want some means of breaking path
>vertexes into single objects.  
>

Chris's original response didn't mention a couple of things which might be
helpful to you. First off, you can insert newlines into path data, thereby
isolating individual vertices onto individual lines. (This probably doesn't
meet your needs, but I thought I would mention it anyway.)

Potentially more valuable is the SVG DOM. Even though the SVG language
packs all of the vertices inside of a single "d" attribute, there is DOM
access to individual vertices. Take a look at Appendix B.

Incidentally, Adobe has stated publicly that it will be providing a
downloadable SVG browser plugin for NN and IE. This SVG browser plugin (not
yet available, but it will be at some point, I promise) also works as an
SVG ActiveX control on Windows. As such, it can be used outside of web
browsers. For example, we already have it working with Microsoft Office. If
you are doing your work on Windows, you might be able to leverage this SVG
ActiveX control to give you SVG parsing and SVG DOM access. When Adobe
finally does announce some sort of public beta program for our SVG browser
plugins, you might want to check all of this out.

>And I think circular arcs are common enough
>that they should be supported directly.

The path data syntax in chapter 10 includes a general elliptical arc
facility, which indeed can do circular arcs.

For example, the following draws a red quarter circle (top-right quarter)
with the top of the circle at (100,100) and the right edge of the circle at
(200,200):

<path style="fill:none; stroke:red" d="M 100,100 A 100,100,0,0,1,200,200" />

Yes, the "A" command is nearly indecipherable (don't blame me!). We will
improve the descriptions in the spec, but it likely that the command will
stay as it is now.

If this will help, the terms are as follows:

rx=ry=100 (because rx=ry, the ellipse turns out to be a circle)
x-axis-rotation=0 (doesn't matter with a circle)
large-arc-flag=0, sweep-flag=1 (read the spec for descriptions)
(endx,endy)=(200,200) (the end point for the circular arc segment)

Jon Ferraiolo
SVG Editor
Adobe Systems, Inc.


>
>Thanks
>
>>"Art Hundiak Wrote"
>> 
>> 1. The <path> object is fatally flawed by requiring all the vertex
>> information be contained in one "d=..." attribute.  I have read the emails
>> and the arguments about why it was done this way but the sad fact is that
>> you need some kind of object for the vertexes.
>
>>>"Chris Lilley Wrote (and Art cut out most of it)"
>
>>>XML applications choose what aspacts of the universe to model and at
>>>what granuklarity. In the case of SVG, the basic element is the shape;
>>>be that a path or a basic shape like a rectangle, etc.
>
>>  You can easily have a path
>> with several hundred (or thousand) vertexes. 
>
>>>Yes.
>
>>  You can't rely an attribute
>> being able to store all the information. 
>
>>>Yes you can. SGML had capacity limits and fixed-sized buffers; XML does
>>>not. We actually had a limit on attribute size at one point, and were
>>>told by XML experts to remove it.
>
>XML may not have a limit but I suspect many parsers and applications may
>have.  Even the IBM SVGViewer and the CISRO SVGViewer treat the d=""
>attribute differently.  I know this is not SVG's fault but I just don't
>trust the idea of a single attribute being several hundred thousand bytes
>long.  
>
>>  As it stands now, we would
>> probably have to use a nested path approach in which each vertex becomes
>> it's own path object.  
>
>>>I'm not sure how that follows.
>
>I'm thinking about doing something like this
><path d="M 0,0">
>	<path d="M 0,0 L 0,1"></path>
>	<path d="M 0,1 L 1,1"></path>
>	... as many vertexes as required ...
></path>
>
>This should display right, will keep the attributes small and still be
>reasonably easy to decode by the cutter.  Makes the file bigger but for my
>app that's ok.
>
>> 2.  A great many legacy cad oriented systems get along just fine with line
>> segments and circular arcs.  Please reconsider adding a circular arc to
>the
>> basic shapes as well as a circularArcTo for the path object.  Arcs defined
>> by three points are easy to generate and easy to decode.
>
>>>But difficult to line up properly with other shapes. The present arc
>>>formulation in the path data was specifically designed so that it had
>>>defined start and end points which are part of the arc definition.
>
>A circular arc can be defined with three points, the start point, the end
>point and one point on the arc itself somewhere between the other two
>points.  Typically, this would be the mid point of the arc but doesn't have
>to be.  It's quite easy to take such a representation and approximate it
>with a bezier curve for display purposes. In fact, I added an arcTo to my
>own viewer and it works just fine.
>
>The key word above is approximate.  Cutting machines do understand arcs.  If
>you have a 100 mm arc somewhere then you want the number "100mm" stored
>somewhere.  Judging from the amount of email concerning arcs (on this and
>other boards) I really think that most users would rather let the software
>convert an arc to a bezier instead of doing it themselves.  
>
>
>> 3. Adding a "point" to the basic shapes would also be nice.  Reference
>> points are quite common.
>
>>>That sounds like toy want to join up to the point or share the point or
>>>something. But a point by itself does not generate any output (except in
>>>low resolution devices if the painting model is one of "paint any pixel
>>>thatwas touched). SVG has an integral opacity model, so a point would
>>>generate miniscule coverage and the pixel containing it would not change
>>>color.
>
>I would want to wrap attributes around the point so the user could know what
>the point was for.  And I can work around this by using another shape.  I do
>disagree with the idea that a point by itself should not generate output.  A
>line has zero width but displays just fine.  
>
>> 
>> 4. There seems to be quite a bit of debate concerning the wisdom of
>putting
>> multiple lists of attributes into one attribute value.  style="fill:none;
>> stroke:black; stroke-width:100" is an example.  Maybe there is some
>strange
>> reason why this makes sense 
>
>>>Compatibility with CSS syntax (also used in the style element and in
>>>external stylesheets linked via a stylesheet PI)
>
>> but please do us old timers a favor and give us
>> the option of doing things like style_fill="none" style_stroke="black".  I
>> really don't see the point of having to write a parser inside of a parser.
>
>>>You need one anyway to do the style element and to parse external style
>>>sheets. Or are you suggesting removing all styling? I can see that a
>>>metal cutter doesn't really care what color the path it is cutting is,
>>>but in that case just use the default/initial values, ie leave off
>>>explicit style information.
>
>I'd still want to control some of the style (color and line type) for when
>the plate is being viewed.  Also, at this stage in the process, I'm
>converting the xml file to a dxf file.  I preserve certain style elements
>for debugging purposes. It just seems strange to me to have to have each
>application manually parse this attribute instead of letting xml do it.  If
>CSS needs a different format then let it build it.  Not a big problem.
>

Received on Thursday, 30 September 1999 16:02:06 UTC