RE: Debugging Fonts Not Being Validated Issue with IF Format.
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: mandr...@jabber.org skype: adlm0608 ---
Re: Debugging Fonts Not Being Validated Issue with IF Format.
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: mandr...@jabber.org skype: adlm0608 ---
Re: Debugging Fonts Not Being Validated Issue with IF Format.
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 ---
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 directoryd:\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.e...@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
RE: Debugging Fonts Not Being Validated Issue with IF Format.
(wow dead list on the weekend :)) -Original Message- From: Martin Edge [mailto:martin.e...@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 directoryd:\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.e...@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
Re: Debugging Fonts Not Being Validated Issue with IF Format.
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.e...@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 directoryd:\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.
Hey Andreas, On 05/07/2009, at 12:51 AM, Andreas Delmelle andreas.delme...@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.e...@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 directoryd:\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
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