ForayFont dependency in graphics commons; was: Logging for FOrayFont

[Thomas DeWeese <Th...@Kodak.com>]

Hi all,

    So this is a tricky one.  I really feel like I'm getting in the
way of FOP stuff, but on the other hand as far as I can see the
ForayFont stuff would have almost zero advantage for Batik's use
of the PDF Transcoder.

    This is because Batik has to do all of it's own text layout and
it currently does this using the Java2D Platform Fonts, TrueType
(referenced from CSS), and of course SVG fonts.  Right now there are
a few 'trivial' text cases that are handled by the PDF Graphics2D
'drawString' stuff that might benefit but basically, as far as I
can see, this would - for Batik - be another very low functionality
external dependency.

    That said I know that currently one of the stumbling blocks for
extracting the PDFGraphics2D from the rest of FOP is the the
font subsystem.  There is a bit of an inherent conflict between
using Graphics2D as a 'high level transcoding' API and advanced
font/text handling.  Currently, the list of Java2D fonts (from
GraphicsEnvironment is totally independent of the Graphics2D). Now
of course the current state of text output for PDF is fairly abysmal
from Batik (anything beyond very simple text is done as shapes), but
fixing that would probably be a huge piece of work.

    I personally would lean towards leaving the font-subsystem
as pluggable.

    BTW as far as the PsuedoLogger stuff is concerned this is fine
with me (and is actually my preferred way to handle this).  It doesn't
force any logger on me, yet one can plug it into any existing logging
system with a fairly trivial piece of code.  Although this may not
matter depending on how we approach Font support.

> Jeremias Maerki wrote:
> 
>> I got a little shock when I realized a problem I didn't think of when we
>> discussed moving FOP components over to XML Graphics Commons. We said we
>> would try to remove logging code from these basic components entirely.
>> Now, I forgot to consider the decision to use FOrayFont made earlier.
>> The external dependency on FOrayFont also would be a problem in itself
>> because the Batik side has strong feelings against external dependencies.
>> We need to think about what to do about this WRT the PDF and PS
>> transcoders. Optimized text painting in these two transcoders depends a
>> lot on the font subsystem.

Chris Bowditch wrote:
> Ouch! The FORayFont integration offers a hugh functional benefit over 
> the current Font code, so it would be a real shame to lose it. IIRC 
> Thomas was saying that he was against dependencies that don't yield any 
> functional benefit, i.e. logging and avalon framework. Since FORayFont 
> does have functional benefits for both projects perhaps it won't be such 
> a problem for Batik to include it. But I guess that is up the Batik team 
> to decide.

Re: ForayFont dependency in graphics commons; was: Logging for FOrayFont

[Jeremias Maerki <de...@greenmail.ch>]

Thanks for chiming in, Thomas.

It should be possible to have that pluggable for Batik. After all, the
text bridge mechanism from Batik provides an ideal way to plug that
functionality in.
A few random notes on the topic:
- The PDF library has dependencies on the font subsystem, so we would
need to make sure that Batik without special text handling in PDF will
work without the font subsystem classes present in the classpath.
- Maybe something could be done to embed the fonts of the Java2D origin
as Type 3 fonts. Keiron has left a TODO item about that somewhere.
Shouldn't be that hard to do.
- There IS benefit in painting text as text instead of shapes. You get a
lot of speed and a much smaller file size.
- I have the impression that the FOP-grown text bridges currently
don't work though I haven't investigated closely, yet.

I hope we'll find a good way to handle this. I'll start
copying/migrating components over to Commons as soon as the first FOP
preview release is out.

On 06.09.2005 14:31:38 Thomas DeWeese wrote:
> Hi all,
> 
>     So this is a tricky one.  I really feel like I'm getting in the
> way of FOP stuff, but on the other hand as far as I can see the
> ForayFont stuff would have almost zero advantage for Batik's use
> of the PDF Transcoder.
> 
>     This is because Batik has to do all of it's own text layout and
> it currently does this using the Java2D Platform Fonts, TrueType
> (referenced from CSS), and of course SVG fonts.  Right now there are
> a few 'trivial' text cases that are handled by the PDF Graphics2D
> 'drawString' stuff that might benefit but basically, as far as I
> can see, this would - for Batik - be another very low functionality
> external dependency.
> 
>     That said I know that currently one of the stumbling blocks for
> extracting the PDFGraphics2D from the rest of FOP is the the
> font subsystem.  There is a bit of an inherent conflict between
> using Graphics2D as a 'high level transcoding' API and advanced
> font/text handling.  Currently, the list of Java2D fonts (from
> GraphicsEnvironment is totally independent of the Graphics2D). Now
> of course the current state of text output for PDF is fairly abysmal
> from Batik (anything beyond very simple text is done as shapes), but
> fixing that would probably be a huge piece of work.
> 
>     I personally would lean towards leaving the font-subsystem
> as pluggable.
> 
>     BTW as far as the PsuedoLogger stuff is concerned this is fine
> with me (and is actually my preferred way to handle this).  It doesn't
> force any logger on me, yet one can plug it into any existing logging
> system with a fairly trivial piece of code.  Although this may not
> matter depending on how we approach Font support.
> 
> > Jeremias Maerki wrote:
> > 
> >> I got a little shock when I realized a problem I didn't think of when we
> >> discussed moving FOP components over to XML Graphics Commons. We said we
> >> would try to remove logging code from these basic components entirely.
> >> Now, I forgot to consider the decision to use FOrayFont made earlier.
> >> The external dependency on FOrayFont also would be a problem in itself
> >> because the Batik side has strong feelings against external dependencies.
> >> We need to think about what to do about this WRT the PDF and PS
> >> transcoders. Optimized text painting in these two transcoders depends a
> >> lot on the font subsystem.
> 
> Chris Bowditch wrote:
> > Ouch! The FORayFont integration offers a hugh functional benefit over 
> > the current Font code, so it would be a real shame to lose it. IIRC 
> > Thomas was saying that he was against dependencies that don't yield any 
> > functional benefit, i.e. logging and avalon framework. Since FORayFont 
> > does have functional benefits for both projects perhaps it won't be such 
> > a problem for Batik to include it. But I guess that is up the Batik team 
> > to decide.



Jeremias Maerki