Bug 38347 - Exported PDF/A files cannot be opened in acroreader
Summary: Exported PDF/A files cannot be opened in acroreader
Status: RESOLVED DUPLICATE of bug 39355
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.3 release
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-15 07:16 UTC by Milos Sramek
Modified: 2011-11-11 07:06 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
a faulty pdf (17.26 KB, application/pdf)
2011-06-15 07:16 UTC, Milos Sramek
Details
ODF file which, if exported by LO3.4 to pdf with the PDF/A feature turned on, cannot be opened by Acrobat reader (8.32 KB, application/vnd.oasis.opendocument.text)
2011-06-25 12:17 UTC, Milos Sramek
Details
Faulty PDF, produced by LO3.4.2 on 64bit Ubuntu (25.12 KB, application/pdf)
2011-08-15 10:21 UTC, Guillaume Majeau-Bettez
Details
Writer 3.4.2 file creating faulty PDF/A-1a on 64bit Ubuntu (8.79 KB, application/vnd.oasis.opendocument.text)
2011-08-15 10:22 UTC, Guillaume Majeau-Bettez
Details
Valid PDF/A-1a produced by LO3.4.2 on 32bit Ubuntu (23.53 KB, application/pdf)
2011-08-15 10:23 UTC, Guillaume Majeau-Bettez
Details
Writer 3.4.2 file, creating valid PDF/A-1a, Ubuntu 32bit (8.64 KB, application/vnd.oasis.opendocument.text)
2011-08-15 10:24 UTC, Guillaume Majeau-Bettez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Sramek 2011-06-15 07:16:30 UTC
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
Comment 1 tester8 2011-06-16 13:45:10 UTC
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.
Comment 2 Milos Sramek 2011-06-17 05:30:45 UTC
(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
Comment 3 Chris Peñalver 2011-06-22 10:12:54 UTC
Milos Sramek, could you please post the Writer file that when exported to PDF, demonstrates this problem?
Comment 4 Milos Sramek 2011-06-25 12:17:17 UTC
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
Comment 5 Chris Peñalver 2011-06-25 21:53:28 UTC
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?
Comment 6 Milos Sramek 2011-06-27 01:58:15 UTC
(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)
Comment 7 Guillaume Majeau-Bettez 2011-08-15 10:17:55 UTC
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.
Comment 8 Guillaume Majeau-Bettez 2011-08-15 10:21:11 UTC
Created attachment 50239 [details]
Faulty PDF, produced by LO3.4.2 on 64bit Ubuntu
Comment 9 Guillaume Majeau-Bettez 2011-08-15 10:22:11 UTC
Created attachment 50240 [details]
Writer 3.4.2 file creating faulty PDF/A-1a on 64bit Ubuntu
Comment 10 Guillaume Majeau-Bettez 2011-08-15 10:23:58 UTC
Created attachment 50241 [details]
Valid PDF/A-1a produced by LO3.4.2 on 32bit Ubuntu
Comment 11 Guillaume Majeau-Bettez 2011-08-15 10:24:55 UTC
Created attachment 50242 [details]
Writer 3.4.2 file, creating valid PDF/A-1a, Ubuntu 32bit
Comment 12 Klaus Kusche 2011-08-26 05:18:22 UTC
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...).
Comment 13 Klaus Kusche 2011-09-05 03:53:52 UTC
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.
Comment 14 NoOp 2011-09-05 20:12:04 UTC
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.
Comment 15 Klaus Kusche 2011-09-06 01:23:37 UTC
(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?
Comment 16 Klaus Kusche 2011-10-29 04:03:03 UTC
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...
Comment 17 rpr 2011-11-11 07:06:05 UTC

*** This bug has been marked as a duplicate of bug 39355 ***