Created attachment 82317 [details] Test Writer data Problem description: In Windows environment, Adobe reader says a PDF exported by Writer 4.1 rc2 is wrong and can't read. We can see by Evince under Ubuntu 13.04 but lots of warnings found. Steps to reproduce: 1. Open an attached Writer document (test3.odt) 2. Export as PDF with default settings as file test3-4.1.pdf (also attached) Current behavior: Windows Adobe Reader XI says the PDF is wrong, and can't open. Evince under Ubuntu 13.04 can open it, but lots of warnings happen. Expected behavior: We get right PDF file. NOTE: In Ubuntu environment, we get good result; but these are different font installed. Operating System: Windows 7 Version: 4.1.0.2 rc Last worked in: 4.0.4.2 release
Created attachment 82318 [details] PDF file exported by Writer 4.1 rc2 under Windows 7 (bad result)
Created attachment 82319 [details] PDF file exported by Writer 4.0 under Windows 7 (works fine)
Created attachment 82320 [details] PDF file exported by Writer 4.0 under Ubuntu 13.04 (works fine)
Created attachment 82321 [details] Evince warnings when open the test3-4.1.pdf file.
NOTE: We have no problem with Writer 4.1 rc2 under Ubuntu 13.04, and Writer 4.0.4 under Windows.
Hi Naruhiko Ogasawara, Thanks for the report and examples. Do I get it right that a special font is involved? When I open test3.odt on Ubuntu and export it, it opens fine. So I may have the font needed? Also, the file test3-4.1.pdf (from 4.1.0.2 on WIn7) opens fine here. Regards, Cor
Hi Cor, Sorry for misleading, I have not tried Adobe Reader on Ubuntu. This problem might be reproduce only with Acrobat Reader on Windows. My original ODT file is made under Windows 7 Japanese environment, but it only uses English fonts; Arial and Times New Roman. In my Ubuntu box, pdffonts says: ---------------------- % pdffonts test3-4.1.pdf Syntax Error (239864): Warning: name token is longer than what the specification says it can be Syntax Error (17755): Warning: name token is longer than what the specification says it can be Syntax Error (17755): Warning: name token is longer than what the specification says it can be Syntax Error (716529): Warning: name token is longer than what the specification says it can be Syntax Error (471282): Warning: name token is longer than what the specification says it can be Syntax Error (471282): Warning: name token is longer than what the specification says it can be Syntax Error (239864): Warning: name token is longer than what the specification says it can be Syntax Error (716529): Warning: name token is longer than what the specification says it can be name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- BAAAAA+TimesNewRomanPSMT TrueType WinAnsi yes yes yes 9 0 CAAAAA+Arial-BoldMT TrueType WinAnsi yes yes yes 14 0 ----------------------- Naru
Hi Naru, It's not that your info was mislieading, maybe more that I did not get it right ;) I set the bug to New Maybe I can test on a Windows VM And I would think a bit more precise summary would be great. Something as " Wrong PDF export in Windows Japanese environment though it only uses English fonts" ??
.
Hi Cor, Thanks for picking my report up really quickly. > And I would think a bit more precise summary would be great. Something as " > Wrong PDF export in Windows Japanese environment though it only uses English > fonts" ?? I'm not sure we only have the problem on Japanese Windows or not, but I change summary as you mentioned. Naru
(In reply to comment #10) > Thanks for picking my report up really quickly. You're welcome! Sometimes it works like this. But it is no guarantee for a quick fix of course. Though regularly that happens lightling fast too :) In the mean time, I can say that test3-4.1.pdf (from 4.1.0.2 on WIn7) does not open on my Win7 with Acrobat x11 ... (Will try FoxIt too later)
test3-4.1.pdf (from 4.1.0.2 on WIn7) does open on my Win7 with Foxit Reader. Should summary be e.g. : " PDF: Acrobat cannot handle PDF export in Windows (Japanese environment though it only uses English fonts) " or somesuch ?
(In reply to comment #12) > test3-4.1.pdf (from 4.1.0.2 on WIn7) does open on my Win7 with Foxit Reader. > > Should summary be e.g. : > > " PDF: Acrobat cannot handle PDF export in Windows (Japanese environment > though it only uses English fonts) " > or somesuch ? My additional result is: 1) Ghostscript on Ubuntu 13.04 - NG % gs -dNOPAUSE -dBATCH test3-4.1.pdf GPL Ghostscript 9.07 (2013-02-14) Copyright (C) 2012 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 **** Error reading a content stream. The page may be incomplete. **** Error reading a content stream. The page may be incomplete. **** File did not complete the page properly and may be damaged. **** This file had errors that were repaired or ignored. **** The file was produced by: **** >>>> LibreOffice 4.1 <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. 2) Evince 3.6.1 on Ubuntu 13.04 - OK (shown above) but I got lots of warnings (attached log) 3) Adobe Reader 9 Japanese on Ubuntu 13.04 - NG I'm not a professional of PDF but according to result of Ghostscript and Evince, the PDF seems some kind of problem (specification mismatch). Some applications accept it, and another applications (not only Adobe Reader, but also Ghostscript) can't. So I want let current summary as is and continue to investigate. How do you think?
have fixed one problem, which was noticed by an assertion complaining about string truncation; turns out that a string conversion commit introduced a bug in Windows specific code which causes font names to be omitted from the generated PDF. after fixing this i now get "Arial-BoldMT" and "TimesNewRomanPSMT" written in the file. i'm not sure if this fully fixes the problem (don't have Acrobat installed), please try the daily builds and report if there is still a problem.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=82f742f65d35896c69be38fa3b1c78a22226f71c fdo#66811: vcl: fix broken OUString with length STRING_LEN The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6089121ebd075bb6422d33d6bff69dff2e88efb2&h=libreoffice-4-1 fdo#66811: vcl: fix broken OUString with length STRING_LEN It will be available in LibreOffice 4.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 82466 [details] Test with 7-15 nightly build of master (works fine)
Comment on attachment 82466 [details] Test with 7-15 nightly build of master (works fine) I tried 7-15 nightly build of latest master branch: http://dev-builds.libreoffice.org/daily/master/Win-x86@6-debug/2013-07-15_22.52.29/master~2013-07-15_22.52.29_LibreOfficeDev_4.2.0.0.alpha0_Win_x86.msi and seems good. Adobe Reader X can open the PDF and Evince (on Ubuntu) has no warning. I can test with 4.1.x branch if we already have nightly build patched shown as comment #16.
great, let's call it fixed then.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-1-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf352cd0ed5a94859f9163fcaa2089a93c9e938e&h=libreoffice-4-1-0 fdo#66811: vcl: fix broken OUString with length STRING_LEN It will be available already in LibreOffice 4.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.