First of all, the SVG handling code in FOP (except for the XMLHandlers)
among other stuff will move out of FOP. See here:
http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents

I assume this will happen after the first preview release and after you
finish your work on FOrayFont integration so we don't complicate this
more than necessary and so we don't delay the first FOP release
unnecessarily especially since XML Graphics Commons would need to be
released, too, prior to making a FOP release. And Commons as still empty.
:-)

On 12.09.2005 15:27:03 Vincent Hennebert wrote:
> I'm about to convert the SVG library to FOrayFont. But the Batik side seems 
> to 
> be reluctant to see the transcoders converted to FOrayFont [1].
> How should I handle that? I guess I should leave existing files as is and 
> provide new files corresponding to the FOrayFont implementation? How should I 
> name them? Perhaps a new subpackage?

Let's identify the problem points first:
PDFGraphics2D and PSGraphics2D: drawString() methods
PDFDocumentGraphics2D and AbstractPSDocumentGraphics2D: font setup code

The TextElementBridges and the TextPainters are no problem because they
are plug-ins already and are thus optional for Batik. We can have
multiple implementations of the TextBridges if necessary. Without the
TextElementBridge Batik will paint all the text as shapes and thus use
Java2D's font subsystem.

For the drawString() methods we can create simple plug-ins much like the
TextElementBridges which are called by the drawString() methods. Two
implementations of the plug-in interface: One to paint using the new
font subsystem and one that uses the Java2D font subsystem which
should probably paint the text as shapes. The latter implementation can
be done later when necessary as Batik paints all text through the
TextBridge as far as I could see.

For the DocumentGraphics2D classes can simply be subclassed to add font
subsystem-specific code. PSDocumentGraphics2D and PSTranscoder can be
removed entirely IMO. EPS should be enough for all cases, I think. The
only use case for the PSTranscoder I can think of is for "SVG Print",
but that's easily done later again if someone really needs it again.

ATM, don't bother changing any packages. All classes will be repackaged
during the move to XML Graphics Commons. I can only see a few new
classes in the existing packages.

> For pdf, does it concern other files than those in the svg subpackage?

No.

> Which files in the render.ps subpackage are concerned?

PSGraphics2D, AbstractPSDocumentGraphics2D, PSDocumentGraphics2D,
PSTextElementBridge, PSTextPainter, AbstractPSTranscoder and PSFontUtils,
I think.

> What about the pdf library?

That's the big question mark for me. The PDF library should be made
as font subsystem agnostic as much as possible, so Batik can use the PDF
library without a mandatory dependency on FOrayFont. I haven't
investigated any details here, yet.

The same point obviously apply for the PS generation code of which
mainly PSFontUtils has a reference on the font subsystem. At least,
PostScript will be a lot easier to handle than PDF.

> All this is still a bit unclear in my head.
> In two words: please help...

Well, I hope this helps a bit. I'll look a little more closely into the
PDF library.

Jeremias Maerki

Reply via email to