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.
