You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Peter West <pe...@hp.com> on 2006/04/13 17:11:37 UTC
Re: Graphics2D implementations (was: Release coordination in XML
Graphics)
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. But is Batik needed to
render text in a PDFGraphics2D? Can FOP render text as well as graphics
without involving Batik?
Peter
---------------------------------------------------------------------
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
Re: Graphics2D implementations (was: Release coordination in XML Graphics)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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