|
»
»
« 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 10:27, Martin Edge wrote:
Hi Martin
> (wow dead list on the weekend :))
Especially if you're on the other side of the planet, since you have
to wait until the europeans are awake and have taken care of their
basic human needs first...
We need more contributors/committers from the southern hemisphere! :-)
> -----Original Message-----
> From: Martin Edge [mailto:Martin.Edge@...]
>
> There is a few faults I've isolated via my debugging..
>
> - First fault
> This one seems to affect all output renderers from the IF format
> where if I
> am using a font which does NOT exist, it is not overridden to the base
> any,any font, which in turn makes the related renderers fall over
> because
> the font selected is not within the internal collection.
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)
> 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 formats?
> So I guess what I need to understand is how I could (or could
> someone) go
> about implementing the same font check during the IF -> Output
> rendering
> process.
>
> - Second fault (which actually worked to my benefit)
> It seems the auto-register method is AUTOMATICALLY activated during
> PCL
> rendering - my fop conf for PCL is;
>
> <renderer mime="application/vnd.hp-PCL">
> <fonts>
> <directory>d:\dev\pdfbin\fonts\</directory>
> </fonts>
> </renderer>
>
> I can see by outputting the font list via:
> FontInfo fontList = parent.getFontInfo();
> String test = fontList.getFonts().toString();
>
> That there is windows installed fonts being returned.
see below for the explanation.
>
> - Third Fault
> Even if auto-detect is turned on within the font configuration for
> the PDF
> renderer, the collection available to the PDFPainter is only the
> base FOP
> fonts.
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.
Regards
Andreas
Hi Martin
> (wow dead list on the weekend :))
Especially if you're on the other side of the planet, since you have
to wait until the europeans are awake and have taken care of their
basic human needs first...
We need more contributors/committers from the southern hemisphere! :-)
> -----Original Message-----
> From: Martin Edge [mailto:Martin.Edge@...]
>
> There is a few faults I've isolated via my debugging..
>
> - First fault
> This one seems to affect all output renderers from the IF format
> where if I
> am using a font which does NOT exist, it is not overridden to the base
> any,any font, which in turn makes the related renderers fall over
> because
> the font selected is not within the internal collection.
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)
> 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 formats?
> So I guess what I need to understand is how I could (or could
> someone) go
> about implementing the same font check during the IF -> Output
> rendering
> process.
>
> - Second fault (which actually worked to my benefit)
> It seems the auto-register method is AUTOMATICALLY activated during
> PCL
> rendering - my fop conf for PCL is;
>
> <renderer mime="application/vnd.hp-PCL">
> <fonts>
> <directory>d:\dev\pdfbin\fonts\</directory>
> </fonts>
> </renderer>
>
> I can see by outputting the font list via:
> FontInfo fontList = parent.getFontInfo();
> String test = fontList.getFonts().toString();
>
> That there is windows installed fonts being returned.
see below for the explanation.
>
> - Third Fault
> Even if auto-detect is turned on within the font configuration for
> the PDF
> renderer, the collection available to the PDFPainter is only the
> base FOP
> fonts.
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.
Regards
Andreas
« Return to Thread: Debugging Fonts Not Being Validated Issue with IF Format.
| Free embeddable forum powered by Nabble | Forum Help |
