PDF Export shows accented characters and umlauts as blank, when Type1-Fonts are used. The problem seems to be, that the PDF doesn't include the definition of an encoding vector. Adding "/Encoding /WinAnsiEncoding" to the Font-Object could be a quick fix at least for west european characters. The error is known in Open Office and documented here: http://www.openoffice.org/issues/show_bug.cgi?id=63015
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I tested again with Release 3.5.0. beta and can confirm that the bug has not been resolved. A document with Umlauts in an Adobe Type1 font looses the umlauts when exported to PDF. Cross-Checking by Printing with Adobe's PDFwriter device is working fine. The significant difference in the generated PDF files is that the sequence "/Encoding /WinAnsiEncoding" in the font object is missing in the exported PDF file.
It looks like the bug still exists in 4.1.2.3. Manually adding "/Encoding /WinAnsiEncoding" in the pdf file indeed is a workaround, but certainly no beginner-friendly one.
I found the solution to this. In vcl\source\gdi\pdfwriter_impl.cxx the Line 3494: if( !pFont->IsSymbolFont() && pEncoding == 0) must be changed to: if( !pFont->IsSymbolFont() ) Reason: Without the pEncoding check - "/Encoding/WinAnsiEncoding\n" is added to the pdf file font object which is correct. pEncoding specifies that a ToUnicode stream has to be generated (and it is) and nothing speaks against it because it is only a translation table and doesn't affect the encoding itself. For symbolic fonts WinAnsiEncoding would be wrong because they have there own encoding shipped with. I don't want to upload this myself because I don't intend to do more on libreoffice and it is to tiny to go through the git/gerrit upload process and making a patch for this. So please someone else do this, I don't want any rights on that code submission.
Looks like this has been remedied with LO 4.4.0.1 (which still is RC), while in 4.3.5 the bug is still present.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.