You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Martin Edge <Ma...@asmorphic.net.au> on 2009/07/04 06:48:41 UTC
Debugging Fonts Not Being Validated Issue with IF Format.
Hey Guys,
I am trying to get my FOP processing system working with the latest FOP
trunk, using the IF format.
Running tests I have found that when I use a custom font (I use Barcode 3 of
9 and 4 -State) I get a failure when using the FO -> IF -> PCL/PDF which
states fontName must be null.
I am under a reasonable amount of pressure and am happy to try and debug the
issue myself, but any background you could give me on this part of the
system may save me a bunch of time.
I have Eclipse up and running, building the application and I'm able to
start the fop.bat script with my required arguments and initiate debugging
and step through the code.
I notice when I use a font that is not in the default set, the system falls
over with a fontName cannot be null error. It seems that if there was any
prior validation on whether a font could be found or not, this process is
thrown out the window when you go from FO -> IF -> PCL/PDF.
For instance, drawText in PDFPainter.java gets called, but the triplet it's
looking for does not exist in the collection returned by
getFontInfo().getInternalFontKey(triplet);
The stack trace is as follows;
SEVERE: Exception
java.lang.NullPointerException: fontName must not be null
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:239)
at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
at org.apache.fop.cli.Main.startFOP(Main.java:174)
at org.apache.fop.cli.Main.main(Main.java:205)
Caused by: java.lang.NullPointerException: fontName must not be null
at
org.apache.fop.render.pdf.PDFPainter.getTypeface(PDFPainter.java:246)
at org.apache.fop.render.pdf.PDFPainter.drawText(PDFPainter.java:269)
at
org.apache.fop.render.intermediate.IFParser$Handler$TextHandler.endElement(I
FParser.java:487)
at
org.apache.fop.render.intermediate.IFParser$Handler.endElement(IFParser.java
:277)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerI
dentityImpl.java:1101)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
her.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source
I've gotten myself in a bind where I have a job I should have delivered last
week, and I need to be able to perform the job some way or another.
I used to use FO - AT - PCL - but the PCL file was way too large, and using
a PCL Page Counter there seemed to be double the amount of pages than there
should have been (no idea whats going wrong there.). It was recommended to
me by Andreas that due to the speed issues I was having, it might be more
optimal to go for the new IF format, and from review of the XML that does
seem to be the way to go. Additionally, due to the PCL file size being a
problem, I could technically split the IF format into chunks before
transporting to PCL. But alas, I am unlucky, and it doesn't seem to work for
custom fonts properly.
Thanks!
Martin
Re: Debugging Fonts Not Being Validated Issue with IF Format.
Posted by Andreas Delmelle <an...@telenet.be>.
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: mandreas@jabber.org
skype: adlm0608
---
RE: Debugging Fonts Not Being Validated Issue with IF Format.
Posted by Martin Edge <Ma...@asmorphic.net.au>.
Hey Andreas,
Sorry it's taken me awhile to get back to you - seems everyone is draining
my available time lately ;)
> 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)
-- Am in Melbourne - so probably 9hrs (am GMT+10) - cool good to know (c:
>> <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)
OK - but I can't define a mime type in the creation of the IF can i? (or did
I miss that option?)
>>> 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 (?)
It would seem so - when the java2d fonts are loaded, that seems to by
default load the system fonts. Possibly by design?
>> <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.
-- 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.
>
> 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 (?)
-- 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.
Thanks for your help!
Martin
Regards,
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
Re: Debugging Fonts Not Being Validated Issue with IF Format.
Posted by Andreas Delmelle <an...@telenet.be>.
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@jabber.org
skype: adlm0608
---
Re: Debugging Fonts Not Being Validated Issue with IF Format.
Posted by Martin Edge <Ma...@asmorphic.net.au>.
Hey Andreas,
On 05/07/2009, at 12:51 AM, Andreas Delmelle <andreas.delmelle@telenet.be
> wrote:
> 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! :-)
Haha of course - wasn't having a go - just spiralling into a mild
panic - what is the time difference though?
We shall see if I can provide any intelligent input :-)
>
>> -----Original Message-----
>> From: Martin Edge [mailto:Martin.Edge@asmorphic.net.au]
>>
>> 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)
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.
>
>> 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.
>
>> 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.
>
>
Sounds like some extra validation at the IF output layer would remove
this as being a potenntial pitfall.
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.
Thanks,
Martin
> Regards
>
> Andreas
>
Re: Debugging Fonts Not Being Validated Issue with IF Format.
Posted by Andreas Delmelle <an...@telenet.be>.
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@asmorphic.net.au]
>
> 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
RE: Debugging Fonts Not Being Validated Issue with IF Format.
Posted by Martin Edge <Ma...@asmorphic.net.au>.
(wow dead list on the weekend :))
-----Original Message-----
From: Martin Edge [mailto:Martin.Edge@asmorphic.net.au]
Sent: Saturday, 4 July 2009 4:08 PM
To: fop-dev@xmlgraphics.apache.org
Subject: RE: Debugging Fonts Not Being Validated Issue with IF Format.
Hi Guys,
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.
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.
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.
- 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.
Any advice would be awesome (c:
Thanks
Martin.
-----Original Message-----
From: Martin Edge [mailto:Martin.Edge@asmorphic.net.au]
Sent: Saturday, 4 July 2009 2:49 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Debugging Fonts Not Being Validated Issue with IF Format.
Hey Guys,
I am trying to get my FOP processing system working with the latest FOP
trunk, using the IF format.
Running tests I have found that when I use a custom font (I use Barcode 3 of
9 and 4 -State) I get a failure when using the FO -> IF -> PCL/PDF which
states fontName must be null.
I am under a reasonable amount of pressure and am happy to try and debug the
issue myself, but any background you could give me on this part of the
system may save me a bunch of time.
I have Eclipse up and running, building the application and I'm able to
start the fop.bat script with my required arguments and initiate debugging
and step through the code.
I notice when I use a font that is not in the default set, the system falls
over with a fontName cannot be null error. It seems that if there was any
prior validation on whether a font could be found or not, this process is
thrown out the window when you go from FO -> IF -> PCL/PDF.
For instance, drawText in PDFPainter.java gets called, but the triplet it's
looking for does not exist in the collection returned by
getFontInfo().getInternalFontKey(triplet);
The stack trace is as follows;
SEVERE: Exception
java.lang.NullPointerException: fontName must not be null
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:239)
at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
at org.apache.fop.cli.Main.startFOP(Main.java:174)
at org.apache.fop.cli.Main.main(Main.java:205)
Caused by: java.lang.NullPointerException: fontName must not be null
at
org.apache.fop.render.pdf.PDFPainter.getTypeface(PDFPainter.java:246)
at org.apache.fop.render.pdf.PDFPainter.drawText(PDFPainter.java:269)
at
org.apache.fop.render.intermediate.IFParser$Handler$TextHandler.endElement(I
FParser.java:487)
at
org.apache.fop.render.intermediate.IFParser$Handler.endElement(IFParser.java
:277)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerI
dentityImpl.java:1101)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
her.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source
I've gotten myself in a bind where I have a job I should have delivered last
week, and I need to be able to perform the job some way or another.
I used to use FO - AT - PCL - but the PCL file was way too large, and using
a PCL Page Counter there seemed to be double the amount of pages than there
should have been (no idea whats going wrong there.). It was recommended to
me by Andreas that due to the speed issues I was having, it might be more
optimal to go for the new IF format, and from review of the XML that does
seem to be the way to go. Additionally, due to the PCL file size being a
problem, I could technically split the IF format into chunks before
transporting to PCL. But alas, I am unlucky, and it doesn't seem to work for
custom fonts properly.
Thanks!
Martin
RE: Debugging Fonts Not Being Validated Issue with IF Format.
Posted by Martin Edge <Ma...@asmorphic.net.au>.
Hi Guys,
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.
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.
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.
- 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.
Any advice would be awesome (c:
Thanks
Martin.
-----Original Message-----
From: Martin Edge [mailto:Martin.Edge@asmorphic.net.au]
Sent: Saturday, 4 July 2009 2:49 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Debugging Fonts Not Being Validated Issue with IF Format.
Hey Guys,
I am trying to get my FOP processing system working with the latest FOP
trunk, using the IF format.
Running tests I have found that when I use a custom font (I use Barcode 3 of
9 and 4 -State) I get a failure when using the FO -> IF -> PCL/PDF which
states fontName must be null.
I am under a reasonable amount of pressure and am happy to try and debug the
issue myself, but any background you could give me on this part of the
system may save me a bunch of time.
I have Eclipse up and running, building the application and I'm able to
start the fop.bat script with my required arguments and initiate debugging
and step through the code.
I notice when I use a font that is not in the default set, the system falls
over with a fontName cannot be null error. It seems that if there was any
prior validation on whether a font could be found or not, this process is
thrown out the window when you go from FO -> IF -> PCL/PDF.
For instance, drawText in PDFPainter.java gets called, but the triplet it's
looking for does not exist in the collection returned by
getFontInfo().getInternalFontKey(triplet);
The stack trace is as follows;
SEVERE: Exception
java.lang.NullPointerException: fontName must not be null
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:239)
at org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77)
at org.apache.fop.cli.Main.startFOP(Main.java:174)
at org.apache.fop.cli.Main.main(Main.java:205)
Caused by: java.lang.NullPointerException: fontName must not be null
at
org.apache.fop.render.pdf.PDFPainter.getTypeface(PDFPainter.java:246)
at org.apache.fop.render.pdf.PDFPainter.drawText(PDFPainter.java:269)
at
org.apache.fop.render.intermediate.IFParser$Handler$TextHandler.endElement(I
FParser.java:487)
at
org.apache.fop.render.intermediate.IFParser$Handler.endElement(IFParser.java
:277)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerI
dentityImpl.java:1101)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
her.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
Source
I've gotten myself in a bind where I have a job I should have delivered last
week, and I need to be able to perform the job some way or another.
I used to use FO - AT - PCL - but the PCL file was way too large, and using
a PCL Page Counter there seemed to be double the amount of pages than there
should have been (no idea whats going wrong there.). It was recommended to
me by Andreas that due to the speed issues I was having, it might be more
optimal to go for the new IF format, and from review of the XML that does
seem to be the way to go. Additionally, due to the PCL file size being a
problem, I could technically split the IF format into chunks before
transporting to PCL. But alas, I am unlucky, and it doesn't seem to work for
custom fonts properly.
Thanks!
Martin