Created attachment 587716 [details] reproducer file Description of problem: I'm unable to open the attached PDF file in Writer - it asks for password, but there is none. Okular displays the file just fine without asking the password. Version-Release number of selected component (if applicable): libreoffice-writer-3.5.3.2-3.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. lowriter PowerShot_A4000IS_A4050IS_A3400IS_A2400IS_A2300_A1300_A810_UserGuide_CS_v1.0.pdf Actual results: A dialogue asking for password appears: Zadejte heslo k otevření souboru: 0X8zf0 - note that the part "0X8zf0" is different on each try. After entering anything (leaving the field empty) it says the password is wrong and that the file cannot be opened. Expected results: The pdf is imported without any problems, not asking for the password. Additional info: Possibly this is a candidate for an upstream bug - I'm not really sure whether Fedora patches & packaging can have any influence on the program behaviour in this case. Please forward this as needed.
pdfinfo PowerShot_A4000IS_A4050IS_A3400IS_A2400IS_A2300_A1300_A810_UserGuide_CS_v1.0.pdf ... Encrypted: yes (print:yes copy:no change:no addNotes:yes) ... shows that the file is locked for change.
(In reply to comment #1) > pdfinfo > PowerShot_A4000IS_A4050IS_A3400IS_A2400IS_A2300_A1300_A810_UserGuide_CS_v1.0. > pdf > ... > Encrypted: yes (print:yes copy:no change:no addNotes:yes) > ... > > shows that the file is locked for change. then it could be opened read-only "addNotes:yes" - well, Writer *supports* notes, so it can be opened even for working with notes
(In reply to comment #2) > "addNotes:yes" - well, Writer *supports* notes, so it can be opened even for > working with notes PDF files are imported as a series of pages into Draw.
(In reply to comment #3) > PDF files are imported as a series of pages into Draw. ??? - now I'm really confused ... http://www.libreoffice.org/features/extensions/ PDF Import: the PDF Import extension allows you to import and modify PDF documents. Results with 100% layout accuracy can be achieved with the "PDF/ODF hybrid file" format, which this extension also provides. A hybrid PDF/ODF file is a PDF file that contains an embedded ODF source file. Hybrid PDF/ODF files will be opened in LibreOffice as an ODF file without any layout changes. - no mention that it works only in Draw http://www.techsupportalert.com/content/pdf-file-allows-editing-perfect-layout-accuracy.htm "If the PDF file is exported from LibreOffice/OpenOffice Writer, it opens directly in *Writer*." http://www.geektips.info/2011/05/convert-pdf-to-odt-ubuntu/ "Step 1. opens LibreOffice *Writer* ."
the PDF import extension can do 2 different things: 1. import _any_ PDF file into Draw, with (depending on content) some loss of fidelity 2. import a _special_ kind of PDF file, called "hybrid PDF/ODF", which is produced only by OOo derivatives and actually contains an embedded ODF document, into any application, with full fidelity assuming this PDF file is not actually generated by LO, it can only be imported into Draw. so if the file is actually password protected (as claimed in comment #1) then i don't see anything wrong in asking for the password. the bugdoc contains the following (binary data replaced with X): 10747 0 obj <</Length 128/CF<</StdCF<</Length 16/AuthEvent/DocOpen/CFM/AESV2>>>>/Filter/Standard/O(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)/P -1052/R 4/U(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)/V 4/StrF/StdCF/StmF/StdCF>> endobj which looks like it does want to define a password; presumably this is some kind of "password to modify" "feature" that corporate bureaucrats are fond of, and which is apparently implemented in the PDF import, so it looks like it's not a bug to me. but LO still asks for the password when opening the bugdoc read-only, and the only option really is to "cancel", which does seem to be a bug (though i'm not sure how easy it is to do something about that, i.e. is it possible to try to import the document without password, and only fail if there's actually some content that is actually encrypted...).
It uses the PDF 1.6 encryption stuff, which isn't implemented in LibreOffice. presumably it tags certain stuff to be encrypted and other stuff as not, but we just see that its encrypted with something we don't understand and can't pass our PDF-1.4 level checks
The file uses PDF encryption algorithm value 4 which is currently not supported by LibreOffice. For details, see the description of upstream <https://bugs.freedesktop.org/show_bug.cgi?id=55425> "PDF import: support encryption algorithm value 4," which is an RFE to get this missing functionality eventually implemented. However, what is wrong is that LibreOffice keeps asking for a password here. Instead, it should inform the user that the given PDF cannot be opened due to unsupported features. The respective upstream fix <http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3d720b14c0bbfc849f8562d02b471e223e1b0bc> "rhbz#826526 Inform user about unsupported PDF encryption formats" will be incorporated into libreoffice-3.5.6.2-5.fc17.
libreoffice-3.5.7.2-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/libreoffice-3.5.7.2-2.fc17
(In reply to comment #7) ... > will be incorporated into libreoffice-3.5.6.2-5.fc17. well, using 3.5.7.2-2.fc17 now I'm getting the error message: Version incompatibility. Incorrect file version. and after clicking OK: General Error. General Input/Output error. this seems a bit misleading - I'd use "Unsupported" rather than "Incorrect"; and maybe it's just me, but "I/O error" sounds like harddisk failure or so, rather than trying to read file with unsupported features ... however, I wouldn't say its worth reopening this as I'm looking forward for the algorithm value 4 support - thanks for looking into this and for passing the problem upstream
(In reply to comment #9) > Version incompatibility. > Incorrect file version. > > and after clicking OK: > > General Error. > General Input/Output error. > > > this seems a bit misleading - I'd use "Unsupported" rather than "Incorrect"; Yes, that was so that we get a fix in "cheaply" without having to bother about l10n, "with a crudely reused "Version Incompatibility" message box (TODO: improve)" (<http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3d720b14c0bbfc849f8562d02b471e223e1b0bc>). > and maybe it's just me, but "I/O error" sounds like harddisk failure or so, > rather than trying to read file with unsupported features ... That omnipresent "I/O error" is a longstanding annoyance in OOo/LO indeed, but comes from a central location, so is hard to get rid of.
ok, thanks for the info