Hi Andres,
Andres Toussaint wrote:
I have made some tests trying to promote a quadratic to a cubic, by
adding a duplicate control point. The resulting curve is different,
consider the following two elements, they should be identical, if we
could promote simply by adding a control point, but they are not:
The proper way to promote is to multiply the delta between
the first and middle and end and middle by 2/3 to construct
the new control points:
Quadradic = (1-t)^2*Pq1 + 2*t(1-t)*Pq2 + t^2Pq3
Cubic = (1-t)^3*Pc1 + 3*t(1-t)^2*Pc2 + 3*t^2*(1-t)Pc3 + t^3Pc4
Pc1 = Pq1
Pc2 =(Pq1 + 2*(Pq2-Pq1)/3)
Pc3 =(Pq3 + 2*(Pq2-Pq3)/2)
Pc4 = Pq3
If you substitute into the cubic eqn and simplify you will
end up with the Quadradic.
Absolute or Relative Arc (A,a) --to--> Absolute sequence of
Lineto segments (L)+
I notice the example in the spec text but I wonder if this
was really thought through, once again the _much_ more common
thing would be to replace the arc with cubic curves (one per
quadrant of the ellipse).
>
As with the above example, I guess there is a whole complex mathematical
problem behind this. We should take into account that there are other
graphical formats (such as WMF) that usually flatten complex paths into
segments, so i can assume the normalized approach is taken from this.
But will look into options for transforming Arcs and Quadratic curves
into Cubic without modifying the shape path.
There is not a 'perfect' mapping here. But the normal thing
would be to have one Quadradic (or promote to Cubic) per quadrant
with the start and end at the middle of the sides of the bounding box
and the control point at the corner of the bounding box. To support
'sub arcs' you would probably have to divide the curve (the
classes in ext.awt.geom have support for subdividing cubic curves).
You need to be careful when a property is read only it means you
can't assign something to it but it does not mean that the object
returned is read only. So you can't change the actual PathSegList
but you can completely replace the path seg list's contents
(using replaceItem, etc).
Thanks for the insight, exactly what i had feared.
It isn't real terrible given the support already in the base classes
for notifying you that the attribute has changed, you just have to
re-parse the 'd' attribute.
/Also, arising from this, one item that is unclear is where and
how to define the flatness threshold for normalizing, i.e. how
accurate the conversion of the curve to lines is. This is
usually a double value that indicates the distance allowed from
the tangent to the curve until you need a next point. The spec
has no clear reference to this item.
Yes, without a flattening parameter it is impossible to do this
properly (and even with it, the result is ugly). It would be much
better to use cubic curves (still not perfect but much better).
The result may be ugly, but usually that is what you expect when
flattening a curve. Java 2D flatteningPathIterator only returns movteto
and lineto segments. I think that the SVG spec took one little step
ahead allowing cubic curveto elements.
If it were 'flattening' then I would agree with you but since it
is 'normalizing' I think that an implementation should use cubics
where reasonable. Personally I think this is a real hack of an
interface, Adobe's preference for Cubics is showing (True Type
only has quadratics), a flattening interface would IMHO make more
sense (with a flattening value of course). It is in fact odd that
you have less of an idea what you will get back from the 'Normalize'
method than the unnormalized method... *heavy sigh*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
