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 (?)


Andreas Delmelle
jabber: mandr...@jabber.org
skype: adlm0608


Reply via email to