xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierrick Brihaye <pierrick.brih...@free.fr>
Subject Re: Parsing out of a document scope
Date Sun, 03 Apr 2005 19:35:31 GMT

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" 
   <xsl:variable name="YPointAt" 
   <xsl:variable name="SlopeAt" 

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

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 

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

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



To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message