On 13 Jul 2009, at 16:06, Martin Edge wrote:
Hi Martin
Sorry it's taken me awhile to get back to you - seems everyone is
draining
my available time lately ;)
No sweat. I'm all too familiar with that situation. ;-)
<snip />
[Me:]
Don't know if you noticed the small remark on the web page, but the
same restriction as for the AT XML holds for the new IF: you will
produce an IF file mimicking another output format. If you generate
one for PDF, then it may turn out suboptimal when rendered to PCL
(unless the font metrics would happen to be identical)
OK - but I can't define a mime type in the creation of the IF can i?
(or did
I miss that option?)
Yes you can, although you have to do a close read of the webpage to
find:
"As with the AT XML, there is an important detail to consider:
The various output implementations don't all use the same font sources.
To be able to create the right IF for the ultimate output file,
you need to create the IF file using the right font setup.
This is achieved by telling the IFRenderer (responsible for
converting the area tree into calls to the IFDocumentHandler
and IFPainter interfaces) to mimic another renderer. This is done
by calling the IFSerializer's mimicDocumentHandler() method with
an instance of the ultimate target document handler as the single
parameter."
If I catch correctly, it would currently only be possible via Java code.
I don't see it turn up as an option to pass via the command-line
interface.
OK. So that is actually a fluke (?)
It would seem so - when the java2d fonts are loaded, that seems to by
default load the system fonts. Possibly by design?
Indeed. All renderers based on Java2D, by design, have access to all
system fonts (via AWT).
For the other renderers, like PDF and PostScript, custom fonts or font-
locations should be explicitly registered, or font auto-detection
should be enabled to make use of those.
<snip />
If I were to personally add such validation, I'd still have FOP crash,
and you'd be no further than you are now. The only difference would be
a genuine, meaningful exception instead of a NullPointerException.
-- Yeah, and perhaps under that set of circumstances that is all
that is
required - as a user I had to dig further into debugging the
application to
understand the error.
So noted. I'll see if I can look into that later.
In FOP trunk, the cleanest approach would involve routing the event,
and let the end-user decide whether or not they want to risk it.
If the event does not trigger an exception at runtime, we could then
try to recover by using the "any" font, instead of crashing.
<snip />
-- Really don't know now as everything is working, and I don't
especially
think i've done anything. Once time clears up again I'll try to run
a few
more tests to understand how I experienced the cool-ness I did. As
far as
the different renderer config used - I will try to look at the code
to see
if I can follow it - but it did seem the separate configurations
were used.
FWIW: In between my current tasks, and after having run several debug-
sessions, I'm creating some flowcharts to publish on a Wiki or the
main site. Just so that potential contributors have something to hang
on to. :-)
Thanks for your help!
Always welcome!
Regards
Andreas
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608
---
