|
»
»
« Return to Thread: Debugging Fonts Not Being Validated Issue with IF Format.
Re: Debugging Fonts Not Being Validated Issue with IF Format.
by Andreas Delmelle-2
::
Rate this Message:
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: mandreas@...
skype: adlm0608
---
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: mandreas@...
skype: adlm0608
---
« Return to Thread: Debugging Fonts Not Being Validated Issue with IF Format.
| Free embeddable forum powered by Nabble | Forum Help |
