[prev in list] [next in list] [prev in thread] [next in thread] 

List:       batik-dev
Subject:    Re: batik and fop
From:       Bill Haneman <Bill.Haneman () Sun ! COM>
Date:       2001-03-08 13:20:18
[Download RAW message or body]


>As part of using batik in fop I have currently got it generating a 
batik dom
>(in a cvs branch).
>
>So what is the best way to get the rendering part done. ie. reading the 
svg
>data out to convert to pdf.

Hi Kieron:

I am sure that you will get other replies.  But to start
you off -  there are, by design, two approaches supported in
the Batik architecture for doing this:

1) Implement a module that conforms to the Transcoder API;
2) Implement a custom Renderer.

Going direct to the DOM, while possible, is not a favored
approach.  We designed both Transcoder and Renderer to
allow vector output formats - in fact we specifically 
kept pdf in mind as a target.

I would disagree with most of your conclusions about GVT,
particularly in your situation, since you are indeed converting
to another rendering format.  As for requiring a display,
this is a limitation of the JDK which is being addressed in
upcoming revisions of the JVM (right Vincent?).  The display
doesn't have to be a "real" one, as has previously been discussed
on the list.  Also, the rendering occurs not in GVT but
in a separate module, called the Renderer.

The "rendering" of a GVT tree does not require rasterization.
The Renderer interface allows for non-rasterized transcoding
(except, of course, for <image> elements).  It's true that
non-rasterizing implementations of blur filters would be 
non-trivial, but they are possible.  Nonetheless this should 
not be an issue for pdf encoding since I don't believe pdf
has any way of specifying blur and many of the other filter
ops, you will have to rasterize for those features.  One
other sub-interface you will probably want to implement is 
TextPainter, if you don't implement a (custom) pdf-suitable 
TextPainter then the text will render using the default 
TextPainter, but it will be converted to stroke primitives which is 
probably not what 
you want ;-) 

The Renderer interface, which could be implemented by, say,
PDFRenderer, needs to implement the java2d Interface 
Graphics2D methods.  There are no AWT component references 
involved.  These java2d methods are what the "paint" methods
in GVT actually call in their implementations.  So the 
GVT components can "paint" themselves into any compliant
Graphics2D implementation, which need not be rasterizing.
My initial impressions when I looked at the feasibility of
this for pdf were that it would map well onto pdf
for everything but filters and masks (maybe masks are OK too).

If you *really* don't want to use GVT for some reason, you
could still implement Transcoder - Vincent will have more
information on that.

Best regards,

Bill

>The current code can read the DOM directly and (in theory) render the 
pdf.
>The problem is that the batik dom does not implement a number of 
methods
>(throws runtime exceptions).
>
>As I understand it batik uses the bridge to convert to the gvt
>representation. This representation is based on awt components and 
holds all
>the information with awt specific data structures. These objects can be
>rendered to a graphics context by using the paint method.
>
>It seems to me that the gvt is not very suitable for other rendering
>requirements (converting to pdf).
>- rendering is currently done internally in the gvt
>- the information is not readily available
>- information is in a form only suitable for graphics rendering
>- requires a display
>
>Whereas converting from the dom is more straightforward.
>
>Is my information correct?
>
>What is the best way to handle this.
>Should I be looking to render directly from the DOM and therefore need 
parts
>to be implemented.
>Use the bridge to create suitable information for pdf rendering
>Somehow use the gvt to render from.
>
>Thanks for your help.
>
>Sam Ruby wrote:
>
>> I am trying to get all the projects to play nice together (for 
example, I
>> would like xml-fop to use batik), and I can't follow every mailing 
list.
>> However, for the near term, I do plan to follow this list.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: batik-dev-help@xml.apache.org
>

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland 


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

[prev in list] [next in list] [prev in thread] [next in thread]