On 04 Jul 2009, at 23:25, Martin Edge wrote:
Hi Martin
Haha of course - wasn't having a go - just spiralling into a mild
panic - what is the time difference though?
Depends on where in Australia you are based. Just checked the time
zones, and if you're in Perth, then you're 6 hours ahead of me. If
you're on the other side of the continent, the difference is 8 hours.
I'm based in Belgium, in time-zone CEST or GMT+1. Chris is another
hour behind you, since he is based in the UK (practically on the
Greenwich meridian, IIC)
<snip />
I don't seem to be able to reproduce this. If I use an unknown font-
family, and render a sample to the IF, the susbtitution to
'any,any' is done before that, and ends up in the IF file. I'm
concluding that you mean that the font is available when rendering
to the IF, but not when rendering the IF to the eventual output
format. Can you confirm? (May point to a possible cause/solution)
Yeah - that's pretty much it - so I'm thinking if the IF renderer
font configuration differs from the output format then it is
possible to get in this situation. I can try creating the IF file
using a complex font set and out put as a renderer with a limited
font set.
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)
Once I could isolate which font was failing, and installed it
directly into
windows (I did find this strange, because I don't have <auto-
register>
enabled) - the document renders fine.
Strange... and this happens for both output format
No, just noticed it in PCL - the setDefaultFonts method gets called
which grabs the Java2d collection.
OK. So that is actually a fluke (?)
<snip />
I have checked this in the code, and indeed noticed a difference
between
org.apache.fop.render.PrintRendererConfigurator.setupFontInfo()
(used by the PDFPainter) and
org.apache.fop.render.pcl.PCLRendererConfigurator.setupFontInfo()
(used by the PCLPainter)
The latter one adds an InstalledFontCollection on top of the
Base14FontCollection. The installed fonts are obtained via Java
AWT, which may explain why this collection is disregarded by the
PDFPainter, as it uses a different font source.
Sounds like some extra validation at the IF output layer would
remove this as being a potenntial pitfall.
May be. At the very least, it is rather unwise to try to render the IF
using different settings than those with which it was created. That's
just asking for trouble. Note that a simple substitution of the font-
family, -weight and -style is not enough at that level. The layout
will have been completely based on the font that was present when the
IF file was created. Just substituting that with 'any,any,any' if the
font does not exist when the document is rendered, will likely lead to
very ugly results...
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.
In your understanding- which font config is used when?
I would have thought - when generating IF file - the app/if config
is used and when I convert fro
IF to my output format - the app/PDF or app/pcl config is used.
Incorrect, I think. If you create the IF mimicking PDF output, it will
use the app/pdf config. If you create one mimicking PCL, the app/pcl
config section will be the relevant one. AFAIK --but I could be wrong,
here-- specifying a separate config section for app/if has no effect
whatsoever, since there are no settings specific to that format (?)
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608
---
