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 [EMAIL PROTECTED] FontConsumer} implementation that
is
* requesting the AWT Font.
* @param fontSize The font size, in millipoints.
* @return The related [EMAIL PROTECTED] 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
