xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Graphics2D implementations (was: Release coordination in XML Graphics)
Date Thu, 13 Apr 2006 15:51:22 GMT

On 13.04.2006 17:11:37 Peter West wrote:
> On Thu, 2006-04-13 at 16:37 +0200, Jeremias Maerki wrote:
> > On 13.04.2006 16:19:08 Peter West wrote:
> > <snip/>
> > > > The Transcoders use the Graphics2D implementations to render the basic
> > > > graphic elements. Special elements like links, text and more can
> > > > optionally handled using special "bridge" classes (SVG/Batik-specific).
> > > > 
> > > Text which uses either the base14 or embedded fonts seems to be
> > > rendering without invoking the bridge classes.  In general, text should
> > > be able to be rendered through Graphics2D.  For the base14 fonts, some
> > > extra work is required, but for fonts which are being embedded, the
> > > bridge should not be required, should it? In fact, for base14, it is
> > > only the co-ordination with the font configuration that's required,
> > > isn't it?
> > 
> > Not quite. All text from Batik is normally painted by internally
> > converting it to shapes. This is done using the fonts that are available
> > to the Java2D subsystem and has nothing to do with font configuration
> > provided by FOP.
> > 
> > Only when we register a bridge class for text painting can we select
> > simple-enough text elements that we can paint using native operators.
> > Only in this case will base 14 fonts (or configured fonts - the
> > PDFTextPainter doesn't really care) be used. That's when our own font
> > system kicks in.
> > 
> Let's back up a step. That's text from Batik. 

Right. Should have said that.

> But is Batik needed to render text in a PDFGraphics2D?

No, it shouldn't be like that. See below.

> Can FOP render text as well as graphics without involving Batik?

Yes, actually I forgot a little detail before: PDFGraphics2D implements
the two drawString() variants and uses native text commands there. These
methods are never called by Batik, but other applications might use them.

This is actually one of the reasons I factored out the TextHandler
interface in the PSGrahics2D in Commons. So that I didn't take the font
subsystem dependecy over, yet. Especially, since FOrayFont will
come into play at some point. Factoring out text painting makes the
transition easier while still keeping all doors open and it concentrates
all text handling in a shorter class.

The PDFTextPainter currently simply delegate the actual text painting to
the drawString() methods, while PSTextPainter now uses the TextHandler
interface (which doesn't exist for PDF, yet).

There's certainly room for improvement in this area and it is all
work-in-progress but for most purposes everything works fine ATM.

Jeremias Maerki

Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message