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