Exception in apache.pdfbox/fontbox - null font #224
Comments
|
@rototor I'm getting the same thing. If you get time, could you take a look please? |
|
I see "COSDictionary{COSStream has been closed and cannot be read. Perhaps its enclosing PDDocument has been closed?}" |
|
What font are you using? Can this be reproduced with some of our example files? We call subset() here only as a workaround. Maybe @THausherr has some clue what went wrong here. |
|
"null" is just the name of the font. |
|
"COSStream has been closed and cannot be read. Perhaps its enclosing PDDocument has been closed" happens if you close a document and then read a stream resource. Usually if you use a resource in two documents and close one of them. |
|
Yes it would be useful to have the font to see what happens when doing ordinary subsetting with it. |
|
I put the example here: https://base.etogo.net/_generated.html |
|
Sorry I forgot to include this. Here's the complete code block from the servlet, no other resources are opened or closed: |
|
Not sure, I suppose container would close all resources after servlet thread run is completed. Anyway, I suppose you'll fix it!😉 |
|
Just made some tests, no leaks. I launched it about 20-30 times, it consumes some resources when pdf is generating but after some time of inactivity, the gc returns everything back as I see:
|
|
I found out that the cmap exception also comes if font.subset() is called twice. |
|
I'm running into this problem too. To start off I've had to use TTC files in favor of multiple TTF files to get fonts to work properly at all. This is likely because the multiple TTF files I have are for different styles (normal, bold, italic, bold+italic) but for some reason java.awt.Font#getStyle always returns 0 (java.awt.Font.PLAIN) for all of the fonts. I guess this information is not available in the TTF file? (I'm not an expert on fonts...) So now I've got a TTC font and I can set subset to true or false. If I set it to true, I get the aforementioned At bare minimum I'd say that all of these printStackTrace calls have to be changed to use the logging mechanism provided (in my case log4j) but as I've understood the exception means that file handles may remain open every time a PDF is generated. |
|
It seems to me that the error can be ignored in my use case, because TrueType Collections are closed manually after the loop. See com.openhtmltopdf.pdfboxout.PdfBoxFontResolver#close If this is the case, then the issue can be resolved (at least for me) by passing the error to the com.openhtmltopdf.util.XRLog class. |
|
There have been some recent changes in PDFBox that can be tested by using the latest jar at |
|
Oops! I meant that exception, sorry. I've updated my OP to reflect this. I've also noticed that this only occurs when the com.openhtmltopdf.pdfboxout.PdfBoxRenderer#close is called, which is after the PDF is generated. If I don't close the PdfBoxRenderer object I don't see the exception in my log. This seems to point to an issue with cleanup, not an issue with rendering the PDF. |
|
Is this issue related to #215? |
|
Yes, possibly, it's the same code area, but the issue there has been solved in snapshot, that's why I'd like that it be retested. |
|
I tested the following code with both PDF-BOX 2.0.11 and 2.0.12-SNAPSHOT: public static void main(String...args) throws Exception {
for (int i = 0; i < 100000; i++) {
File hand = new File("/Users/me/Documents/pdf-issues/fonts/JustAnotherHand.ttf");
PDDocument doc = new PDDocument();
PDFont unused = PDType0Font.load(doc, hand);
doc.close(); // Does this close unused?
System.out.println(i);
}
}The result on 2.0.11 was: 2.0.12 completed successfully. So the issue seems to be fixed in snapshot. Big thanks! We can remove our kludgy workaround code as soon as 2.0.12 is released. |
…ith our close font workaround. [ci skip] This really needs a release of PDFBOX 2.0.12 for a proper fix.
|
Yes, the file leak was fixed in https://issues.apache.org/jira/browse/PDFBOX-4242 . |
|
I ran into the same problem, then I checked this post: and tried a bit with FSSupplier, and it's working now:
|
|
Closing now as workaround code removed as fix was published in dependency PDFBOX 2.0.12. Thanks everyone for reporting. |
|
I'm still having the issue in 2.0.18 .. |
|
Better create a new issue with the smallest possible code that reproduces the problem. (Is this related to openhtmltopdf at all? I don't see it in the stack trace) |
|
|
Hi,
Got this, have no idea why:
Probably this Exception#printStackTrace call should be removed, although I don't understand how can font be null:
The text was updated successfully, but these errors were encountered: