Apache OpenOffice (AOO) Bugzilla – Issue 69741
PDF export fails to include any font information after many export operations
Last modified: 2007-03-06 14:02:10 UTC
We are using OO.o Writer 2.0.3 on Solaris (sparc) to generate PDF files as a reporting engine, using the Java-UNO bridge API, and JooReports (http://jooreports.sourceforge.net/). We are running headless, using xvfb, but suspect the same problem would occur with a full X server. We first encountered a problem in 2.0.2 where PDF files are being exported with nothing in the /Font group. This causes Acrobat and Ghostscript to give errors when the file is opened. The problem happens at various times - once in production it happened within a few PDF exports after OpenOffice was started. Other times it takes a lot of PDF exports. But once a bad PDF is created, OO.o stays in this state and creates only bad PDF's thereafter. See forum thread for more detailed debugging output: http://www.oooforum.org/forum/viewtopic.phtml?t=43487 Will attach a single-java-file application that reproduces the issue. We ran this overnight, it created 15449 good PDF files before getting into the bad state and creating 3006 bad ones. uname -a: SunOS 5.9 Generic_118558-21 sun4u sparc SUNW,Sun-Fire-V240 X Window System Xvfb & Xnest Virtual Display Servers: Version 6.6.1.5800,REV=0.2002.04.05
Created attachment 39285 [details] This is a PDF that was saved with no font information
Created attachment 39286 [details] This is what the PDF should look like, this was exported before the problem occurred
Created attachment 39287 [details] The Java application that reproduces the issue, with a shell script to run it and the .odt file
Reassigned to HI.
We have installed the same product stack on Fedora Core 4 Linux (Linux 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 i686 i386 GNU/Linux). The problem has NOT occurred on Linux. We generated 13K + PDF files using the same test app attached to this ticket, and they were all fine. Hopefully this narrows down the possibilities. Unfortunately there are some logistical issues preventing us from just deploying on Linux instead as a workaround for this issue.
I'm working with "Herringbone" on this issue. We have downloaded the OOo source and looked over it to get a better understanding of how the system works and how the error could manifest itself. * m_aEmbeddedFonts (from pdfwriter_impl.cxx) has the list of embedded fonts that needs to be rendered into the pdf. If a font is missing from here, then it would not make it into the pdf. However, if a font is missing from m_aEmbeddedFonts then the font dictionary references would probably be sequential, which they are not in the corrupt pdf (although they remain ordered). * PDFWriterImpl::emitFonts() iterates over the list of fonts (m_aEmbeddedFonts) and calls PDFWriterImpl::emitEmbeddedFont on each font. If emitEmbeddedFont fails then the font is not added to aFontIDToObject, which populates the font dictionary. * PDFWriterImpl::emitEmbeddedFont(...) contains a giant if block whose execution depends on the result of PspGraphics::DoGetEmbedFontData (by way of PspGraphics::GetEmbedFontData). DoGetEmbedFontData uses the PrintFontManager, which is a singleton, to get information about the font. If the PrintFontManager fails, the problem would roll all the way back up the stack to PDFWriterImpl::emitFonts(), which would then omit the font from being embedded into the PDF. There are several calls to the PrintFontManager in the DoGetEmbdedFontData. Since once the problem happens in an instance of OpenOffice, once it happens all future requests are corrupt, and is fixed by a restart, it would make sense that a singleton (PrintFontManager in this case) has gotten into a bad state. We'll start taking a closer look at the PrintFontManager, and the other case, which is aEmbeddedFonts is not populated correctly in the first place. Also, this would not explain why we have only been able to reproduce the problem on a Solaris box.
I've been working with OOo 2.0.3 on a Solaris (Sparc) machine running SunOS 5.9 and have seen the same problems occur when performing batch PDF exports. The system will export PDFs correctly at first but then at some point it will start exporting corrupt PDFs. The PDF corruption is the same as listed above with the Font objects containing no information. Restarting OOo fixes the problem but after extended use it begins generating corrupted PDFs again. After further testing it doesn't appear that any one file in particular causes the PDF exporter to hit a bad state. Instead it seems to simply be an eventuality when processing large numbers of files.
HI->PL: Please have a look.
You are running out of file handles due to a bug in OOo's resource system which would leave files open. This was fixed in CWS vcl74 which just got integrated (and will be in a 680m206 build). *** This issue has been marked as a duplicate of 70956 ***
closing