Hi,
Thomas DeWeese a �crit :
Let's begin by the end and drop the hinting/filtering considerationsfor now.
> I am not particularly interested in > replacing all concrete values with 'equations' at least not right > now. That said I must admit I'm not sure I really understand your > intent.
Given the following XML :
<path d="M250 150 L150 350 L350 350 Z" />
I would like to write an XSLT like this :
<xsl:template name="drawTangent">
<xsl:param name="path">
<xsl:param name="at">O%</xsl:param >
<xsl:param name="SegmentLength">200</xsl:variable>
<xsl:variable name="XPointAt" select="svg:MySVGDOM.GetXAtPoint($path,$at)"/>
<xsl:variable name="YPointAt" select="svg:MySVGDOM.GetYAtPoint($path,$at)"/>
<xsl:variable name="SlopeAt" select="svg:MySVGDOM.GetSlopeAtPoint($path,$at)"/>
<xsl:value-of select="svg:MySVGDOM.MakeLineCenteredAt($XPointAt,$YPointAt,$SegmentLength, $SlopeAt)"/>
</xsl:template>
<xsl:template match="/path">
<xsl:copy-of select=".">
<xsl:call-template name="drawTangent">
<xsl:with-param name="path" select="."/>
<xsl:with-param name="at">43%</xsl:with-param>
</xsl:call-template>
</xsl:template>This transformation will give the following XML :
<path d="M250 150 L150 350 L350 350 Z" /> <line x1="aaa" x2="bbb" y1="ccc" y2="ddd"/>
Sorry, didn't have time to compute the line attributes. All that I can say is that line should have a length of 200 units :-)
This should however draw (if embedded in a higher level document) a segment wich is a tangent to the initial path at an offset of 43%.
The thing is that all these calculations are done in the local user coordinate system. So it doesn't matter that eventually they will be drawn at a few pixels.
What if a black suface is rendered in the same pixel as a white one ? Do we have a sequential treatment where the last erases the previous ones or do we get what should IMHO the right thing, i.e. a gray suface ?
This is a little different this would be essentially a maths system. So rather than having a float you would have a number abstraction that would 'store' a whole set of calculations that result in the final value.
Exactly. That's why I could even ignore rendering concerns with concrete coordinates.
This allows for simplifications like (cos^2(theta)+sin^2(theta)) = 1, of course to make use of that sort of thing you need a whole algebra solving system.
This would be useful, but this is definitely not what I'm looking for. I may cope with a division by an N factor immediately followed by a multiplication by the same factor.
Say I have a very precise SVG drawing of a fly with all its eyes facets. I would definitely like to ignore these very little shapes when they are rendered within a 100 x 100 pixels matrix ; I mean that everything wich is less than 1% of the final dimension should be "filtered" (the filtering strategy is another yet interesting matter).Unfortunately often calculating what is/isn't visible
takes longer than rendering it.
Sure, but we may also sacrify time for "beautiful" rendering.
Say I could define some "anchors" points in the glyphes (the point at 43% of a path, 20em units above the top of a circle, the intersection of a tangent to a path and the geometric extension of the Nth segment of a polyline, whatever).
I could then move these "control" points relatively to each other in order to have the best possible rendering.
This is normally done by just tweaking the location of the ends and control points of the cubic beziers.
I'm afraid it's more complicated than this because the curves may (slightly) change when they are hinted ; I mean, not all of the control points are transformed in the same way. Better a "m" with 3 stems than a missing central stem (see a very quick intro at : http://pfaedit.sourceforge.net/overview.html#Hints)
> While a more sophisticated
system might be nice you need to balance the need to render everything a 20-30fps. ;)
Font rendering engines are much faster than this :-)
There is a chance that they could be useful to each other. One thing that is likely to happen shortly (after this batik release) is that FOP and Batik will pull some of the low level graphics support code out into external packages. This might be a good place for your work to happen. Especially since you are targeting XSLT (which fits nicely with the concept of the 'xml-graphics' subproject).
Yeah ! Please keep us informed.
Well, we are implementing a Specification we are supposed to be very close, ideally identical.
Good news ! Do you have a pointer ?
http://www.w3.org/Graphics/SVG/
I thought I would have been given a password to the secret W3C lists :-) More seriously, what are the plans regarding the future of SVG ?
I fully agree on these design principles and not only because *you* are the project's leader :-) So... how to start ?
You can look at the sample extensions in 'o.a.batik.ext.svg'. They don't add much to the DOM but they do create subclasses that are used in the DOM. Note that they live in a separate namespace.
They provide additional shapes but standard SVG shapes are sufficient to me. What I just need are... methods :-)
Would Batik be interested ? How to implement this ? 2 points (cartesian) ? A point and an angle (polar) ? A "slope" ? All of these ?
Well, you are the one who is interested, since these are outside of any spec I am aware of you can mostly do what you want. I would have to see something a bit more complete before I could see where/if Batik would be using them.
Any other advice on this ?
It's becoming interesting :-) But this SVGPoint is in absolute (resolved) coordinates, isn't it ?
It always has a float/double X, and float/double Y. It doesn't have a 'Equation X' that can be evaluated to give an X. I think this is the distinction you are making.
You've got it :-) Call this "parametric coordinates system" if you prefer.
> Well my suggestion would be to play with extension elements a bit > and see what can be accomplished that way as I think most of what you > want can be done that way.
I think so. So, back to my initial quesiotn : does anybody have a code snippet that would show me the shortest path between a parser and a Java 2D Shape ?
Of course, I welcome any other advice about this discussion.
Cheers,
p.b.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
