RE: Comments

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.  And I think circular arcs are common enough
that they should be supported directly.

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 10:40:22 UTC