Re: Comments

"Hundiak, Arthur" wrote:

> I'd like to take advantage of xml's namespace capabilities and swap out the
> vector and text portions of our file format with the svg equivalent.

That sounds quite possible (modulo any special constraints about minimum
internal diameter of curves due to cutter radias and so on that are
specific to cutter systems. Not everything that can be drawn with a
zero-sized pen can be cut).

>  Here are some of the problems that I have encountered.
> 
> 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.

I accept that you might, but it is not true to say that this is needed
in general.
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.

This is a similar level of granularity to most (but not all) text
markup, which has separate elements for major block structures and for a
few inline elements which are expected to be styled differently in
visual media, but does not have separate elements for nound, verbs,
adjectivea and adverbs (with XLinks from subject to object and verb to
adverb, etc) far less elements for every syllable.


>  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.

>  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.


> 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.

>   It would make life
> so much easier for people who don't care about bezier curves. 

But SVG has to care about them; and so do all SVG import and SVG display
systems.

> At the very
> least, put something in the spec recomending the best way to deal with
> circular arcs.

Certainly. We plan to add some derivations from common representations.
Acrually the most common derivation we have been asked for is how to
convert elliptical arcs to bezier curves (since those folks claim that
Beziers are all you need and why have everything else .... )

> 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.

> 
> 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.

> 5. I'd like to see a layer="xxx" attribute to specify a drawing layer.
> Almost all cad systems support the notion of layers so this would help when
> moving files from one system to another.

Use groups (the g element). Not only does this allow laters, but also
nested layers.

Do cutters use layers? How does that affect the end result? 

--
Chris
> 
> Art Hundiak
>

Received on Wednesday, 29 September 1999 19:24:32 UTC