Created attachment 47997 [details] a faulty pdf If I export a pdf with the PDF/A option from LO 3.4 RC2, such file cannot be opened in acroread. A Linux acroread does not say anything meaningful, A Windows one complaints about invalid color space. The pdf can be opened by evince, okular and gv. If the PDF/A option is not checked, the file opens without problems. I do not have this problem with OOO 3.3.0 on Windows. Milos
NOT reproduced with Ubuntu 10.04.2 LO 3.4 Product of both PDF and PDF/A-1a export opens in acroread normally. Attached file does not opens in acroread, but opens in Evince.
(In reply to comment #1) > NOT reproduced with > > Ubuntu 10.04.2 > LO 3.4 > > Product of both PDF and PDF/A-1a export opens in acroread normally. > Attached file does not opens in acroread, but opens in Evince. Ok, I tested that today with LO3.3.3: no problem with acroread OOO3.4: no problem with acroread LO3.4.1: the problem exists, tested with acroread9 (Linux), acroread9(XP), acroread10(Win7) I would say it is a problem of LO3.4 The fact, that the file onens in evince does not mean anything - PDF/A reading might be in evince not implemented Milos
Milos Sramek, could you please post the Writer file that when exported to PDF, demonstrates this problem?
Created attachment 48407 [details] ODF file which, if exported by LO3.4 to pdf with the PDF/A feature turned on, cannot be opened by Acrobat reader
Milos Sramek, as per https://bugs.freedesktop.org/show_bug.cgi?id=35431 this issue was fixed in LibreOffice 3.4.0 DEV300m103(Build:5). However, you noted this problem was reintroduced in the 3.4.1 version. Which version of 3.4.1 more specifically?
(In reply to comment #5) > Milos Sramek, as per https://bugs.freedesktop.org/show_bug.cgi?id=35431 this > issue was fixed in LibreOffice 3.4.0 DEV300m103(Build:5). However, you noted > this problem was reintroduced in the 3.4.1 version. Which version of 3.4.1 more > specifically? I think this bug is not related to https://bugs.freedesktop.org/show_bug.cgi?id=35431 It is related only to PDF/A export and has nothing to do with fonts. Moreover, there are no problems with PDF/A with LO3.3.3 PDF export in LO3.4 with the PDF/A option not set is OK. So, the problem version is: LibreOffice 3.4.1 OOO340m1 (Build:101)
I wish to confirm that I can reproduce this bug with LibreOffice 3.4.2 on a 64bit Ubuntu 11.04 machine. However, the problem does not arise on my 32bit Ubuntu 11.04 machine. Both computers have full updates. Both tests were performed with fresh accounts (i.e. with no ~/.libreoffice directory). Both computers run the same exact version: OOO340m1 (build 203). Please find the files in attachment. On one machine, acroread gives the following error message: "There was an error processing a page. Invalid ColorSpace." I would agree with Milos Sramek, the behaviour is not similar to that described in bug 35431.
Created attachment 50239 [details] Faulty PDF, produced by LO3.4.2 on 64bit Ubuntu
Created attachment 50240 [details] Writer 3.4.2 file creating faulty PDF/A-1a on 64bit Ubuntu
Created attachment 50241 [details] Valid PDF/A-1a produced by LO3.4.2 on 32bit Ubuntu
Created attachment 50242 [details] Writer 3.4.2 file, creating valid PDF/A-1a, Ubuntu 32bit
Same problem here: * PDF/A exported from LO 3.4.2 Linux 64 bit fails to open on acroread with colorspace message. Same document, same export settings work on LO Windows. Non-color document, just b&w text, no graphics. * PDF/A exported from LO 3.4.2 Linux 64 bit is invalid PDF/A according to the standard. The Solid Documents verifier (convert@validatepdfa.com, http://www.validatepdfa.com/en/online.htm) says <issues> <colorSpace> <problem severity="error" clause="6.2.2" standard="pdfa">OutputIntent object has an incorrect parameter or invalid color profile</problem> </colorSpace> <catalog> <problem severity="error" clause="6.2.3" standard="pdfa">Device-specific color space used with incorrect or missing OutputIntent</problem> </catalog> </issues> LO is all about standards and portable documents, so this needs a fix (I'm bound to PDF/A...).
Still present in LibreOffice 3.4.3 Linux 64 bit. That's a LO 3.4.* blocker for me, going back to 3.3. The ability to generate PDF documents is the main reason for using LO here, if LO can't produce PDF's which can be opened by Acroread and conform to PDF/A, LO is of no use to us.
I think this may related to: <https://bugs.freedesktop.org/show_bug.cgi?id=35431> [Files exported to PDF with certain PDF/A-1a embedded fonts show dots in Adobe Reader] PDF/A-1a seem borked in LO.
(In reply to comment #14) > I think this may related to: > <https://bugs.freedesktop.org/show_bug.cgi?id=35431> > [Files exported to PDF with certain PDF/A-1a embedded fonts show dots in Adobe > Reader] > PDF/A-1a seem borked in LO. 1.) Looking at what's broken in the resulting PDF/A, these are definitely two different bugs. The validator says that all the embedded fonts are fine in my PDF/A, only the color table is invalid. Both bugs might result from the same kind of problem in the code, but I don't believe that. 2.) Did you validate the broken PDF/A in 35431 with the PDF validation service at convert@validatepdfa.com (see comment #12)? What's the exact error? 3.) LO PDF/A is not broken in general: * 32 bit Windows LO 3.4.* generates correct PDF/A (viewable by Acroread) for exactly the same document, same PDF/A settings and same LO version which fails on 64 bit Linux (I tried both). Hence, LO's PDF/A code is basically correct, at least on some platforms, it only fails for certain platforms. * 64 bit Linux LO 3.3.* also produces valid PDF/A from the same document for the same settings. Hence, this is a regression introduced with LO 3.4.*, and I believe it's something simple. So, just some wild guesses, without actually looking at the code: * Are there some type casts or some file writes which produce different results on 32 and 64 bit platforms (due to different sizes of the native types)? * Are there any unions used for type conversion which suffer from different alignment on 32 and 64 bit platform, or are there any big endian / little endian conversions which fail for the same reason on 64 bit? * Does configure mis-guess something on Linux 64 bit builds?
Can anyone point me to the piece of code which generates the faulty color tables? Maybe I can find some time for a quick look at it...
*** This bug has been marked as a duplicate of bug 39355 ***