FOrayFont, PS/PDFTranscoders and SVG handling

[Vincent Hennebert <vi...@enseeiht.fr>]

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?
For pdf, does it concern other files than those in the svg subpackage?
Which files in the render.ps subpackage are concerned?
What about the pdf library?

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

Vincent


[1] http://marc.theaimsgroup.com/?l=fop-dev&m=112600990201878&w=2

Re: FOrayFont, PS/PDFTranscoders and SVG handling

[Vincent Hennebert <vi...@enseeiht.fr>]

Jeremias and Victor,

thanks for the hints. I keep them under the hand for later, when it is time to 
migrate the stuff into XML Graphics Commons.
For now I just override current implementations with FOrayFont. Anyway it will 
possible to recover them with svn, in case they have to coexist.

Vincent

RE: FOrayFont, PS/PDFTranscoders and SVG handling

[Victor Mote <vi...@outfitr.com>]

Jeremias Maerki wrote:

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

...

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

AFAICT, making the PDF library font-system-agnostic will require either 1)
abstractions within it that must be implemented different ways within the
package itself depending on the font system, or 2) some abstraction of the
font system itself that would allow different font systems to be used by the
same PDF library code, without the PDF code knowing which font system
implementation it uses.

Option 2 strikes me as being infinitely more sensible, and is the motivation
for the axslFont interface. FWIW, the FOrayPDF package (as well as all other
FOray packages) are written to the axslFont interface instead of the
FOrayFont implementation. So, it is easy to avoid dependency on FOrayFont if
you don't mind a dependency on axslFont. That might seem a trivial
distinction. But I know of no other font system abstraction. Otherwise I
would have strongly considered using it instead of creating axslFont.

Don't forget that java.awt.Font can be wrapped inside any org.axsl.font.Font
implementation. In fact, if it is wrapped inside, the java.awt.Font itself
is exposed here:
    /**
     * If this Font has a java.awt.Font associated with it, return it.
     * @param consumer The {@link FontConsumer} implementation that is
     * requesting the AWT Font.
     * @param fontSize The font size, in millipoints.
     * @return The related {@link java.awt.Font} instance, if there is one,
     * otherwise null.
     */
    public java.awt.Font getAWTFont(FontConsumer consumer, int fontSize) ;

The only place I am a little concerned is in the font-configuration side of
things within the FOrayFont implementation. It may be that more work is
needed in font-registration to make sure that Batik gets the wrapped AWT
font instead of some FreeStandingFont. Right now font-configuration can be
configured to only register SystemFonts (AWT) or only register
FreeStandingFonts, or to register both. If more work is needed there, I will
need to rely on you guys to tell me what you need.

Writing to the aXSL interface would allow a simple implementation that only
created wrapped AWT fonts, if that were important.

Also, it may be of interest to know that the FOrayFont implementation is
pretty close to being able to marry FreeStandingFonts with SystemFonts. When
configured this way, the AWT font is created from a font file on disk, using
the same configuration options that allow FreeStandingFonts to be read from
disk now. For those wishing to use only AWT fonts (like Batik and Folio),
this allows them to then embed the font in an output document if they want
to. For Java 1.3 and Java 1.4, only TTF fonts can be created this way. Java
1.5 also supports Type1 fonts.

HTH.

Victor Mote

Re: FOrayFont, PS/PDFTranscoders and SVG handling

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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