Description: i was sent a pdf that someone tried to open in libreoffice draw and failed to. the pdf opens cleanly in evnice or okular so the problem is in libreoffice. while opening it says, "version incompatibility. incorrect file version." then second dialog box that says "general error. general input/output error" and draw closes. i tried to use safe mode but same thing FILEOPEN Steps to Reproduce: 1. open file in okular or evince or any pdf reader 2. open file in draw 3. Actual Results: draw crashes always Expected Results: pdf should open in draw Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Flatpak Calc: threaded
Created attachment 173735 [details] class notes
Confirmed on Version: 7.2.0.1 (x64) / LibreOffice Community Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Get the indicated error: 'Version Incompatibility. Incorrect file version' And, when opened in Adobe Acrobat, PDF properties show: PDF producer: OpenOffice.org3.1 PDF Version: 1.6(Acrobat 7.x) Which of course is bogus, and kind of makes makes this NOTOURBUG (would need more detail about the producer of the PDF to take it further). Otherwise the pdfium based Insert -> Image filter works just fine, a page at a time. Perhaps split the PDF and just use that.
(In reply to V Stuart Foote from comment #2) > Confirmed on Version: 7.2.0.1 (x64) / LibreOffice Community > Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc > CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: CL > > Get the indicated error: > > 'Version Incompatibility. Incorrect file version' > > And, when opened in Adobe Acrobat, PDF properties show: > > PDF producer: OpenOffice.org3.1 > PDF Version: 1.6(Acrobat 7.x) > > Which of course is bogus, and kind of makes makes this NOTOURBUG (would need > more detail about the producer of the PDF to take it further). > > Otherwise the pdfium based Insert -> Image filter works just fine, a page at > a time. Perhaps split the PDF and just use that. i don't mind that. i tried a few online pdf manipulators and the file worked fine there. i used smallpdf.com to "compress" the file and downloaded with "basic" setting they show on the website. that compressed pdf file worked just fine in draw so if this file can open on smallpdf.com or in a regular pdf reader, isn't it a problem of draw that isnt opening it? i am saying this pdf should open in draw and currently it isnt because of something in draw itself. how is it NOTOURBUG?
(In reply to V Stuart Foote from comment #2) > Confirmed on Version: 7.2.0.1 (x64) / LibreOffice Community > Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc > CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: CL > > Get the indicated error: > > 'Version Incompatibility. Incorrect file version' > > And, when opened in Adobe Acrobat, PDF properties show: > > PDF producer: OpenOffice.org3.1 > PDF Version: 1.6(Acrobat 7.x) > > Which of course is bogus, and kind of makes makes this NOTOURBUG (would need > more detail about the producer of the PDF to take it further). > > Otherwise the pdfium based Insert -> Image filter works just fine, a page at > a time. Perhaps split the PDF and just use that. you probably would be surprised to know i got this from a friend who found this in his backup somewhere. this file really is old like his records indicate he got the file back in 2015 which was old even at the time so openoffice must have been used to make this file. same for the other few bugs i have raised today. all came from the backup of these old files
I can confirm this issue with the latest Arch Linux compilations of LO (libreoffice-fresh and libreoffice-still affected). Opening PDF files with Draw fails with a general input/output error.
504 0 obj << /Filter /Standard /V 4 /R 4 /Length 128 /StrF /StdCF /StmF /StdCF /CF << /StdCF << /AuthEvent /DocOpen /Length 16 /CFM /AESV2 >> >> (snip) << /Size 505 /Root 199 0 R /Info 200 0 R /ID [ <CF45F72AB728764BB00FDAC0DE12B30F> <CF45F72AB728764BB00FDAC0DE12B30F> ] /DocChecksum /F5A9B059D948568B44B739E345CFE935 /Encrypt 504 0 R >> https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1311 https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1212 I'm not so familiar with PDF stuffs, and I don't know whether LibreOffice is doing things correctly.
sdext/source/pdfimport/wrapper/wrapper.cxx:1023: xpdf_ImportFromFile(...) calls sdext/source/pdfimport/wrapper/wrapper.cxx:894 checkEncryption(...) which further checks encryption in line 913: if( pPDFFile->usesSupportedEncryptionFormat() ) and fails. PDFFile::usesSupportedEncryptionFormat() is in: https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1212 bool PDFFile::usesSupportedEncryptionFormat() const { return m_pData->m_bStandardHandler && m_pData->m_nAlgoVersion >= 1 && m_pData->m_nAlgoVersion <= 2 && m_pData->m_nStandardRevision >= 2 && m_pData->m_nStandardRevision <= 3; } For this PDF document: (gdb) p m_pData->m_bStandardHandler $5 = true (gdb) p m_pData->m_nAlgoVersion $6 = 4 (gdb) p m_pData->m_nStandardRevision $7 = 4 So m_nAlgoVersion is not <=2 and m_nStandardRevision is not <= 3, thus does not "usesSupportedEncryptionFormat". m_pData is of struct type PDFFileImplData in https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1015 It's m_nAlgoVersion, m_nStandardRevsion etc are set in PDFFileImplData* PDFFile::impl_getData() in https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/pdfparse/pdfentries.cxx?r=776a1b9b#1015. Based on comment 6 the version numbers m_nAlgoVersion (4) and m_nStandardRevision(4) seems correct. So the problem would be the newer (?) decyption algorithm are "not supported" (?) by our sdext.pdfimport. However, a quick search in poppler (i.e. the upstream lib used by libreoffice to parse the pdf into xpdfimport tokens and then further assembled into an ODF draw document), it already added support for "version 5 + revision 6 documents" in year 2016: https://cgit.freedesktop.org/poppler/poppler/commit/?id=69ffeb71a79b686d5c79d20832c4666c498098e8 So it seems the code in sdext/source/pdfimport/pdfparse/pdfentries.cxx need to be updated. Actually I see in line 1345 that it seems to accept m_nAlgoVersion >= 3: if( m_pData->m_nAlgoVersion >= 3 ) Actually the version limitation there has not been touched since the very beginning in year 2008: https://cgit.freedesktop.org/libreoffice/core/commit/sdext/source/pdfimport/pdfparse/pdfentries.cxx?id=a00669b8cb4843acaea59dedc68a4dac8e016fc7 ====== Poppler `pdfinfo` output of this file: ====== Author: Studynama.com Creator: Writer Producer: OpenOffice.org 3.1 CreationDate: Wed Aug 17 21:23:43 2011 CST ModDate: Tue Sep 29 08:11:35 2015 CST Custom Metadata: no Metadata Stream: no Tagged: no UserProperties: no Suspects: no Form: none JavaScript: no Pages: 60 Encrypted: yes (print:yes copy:yes change:no addNotes:no algorithm:AES) Page size: 612 x 792 pts (letter) Page rot: 0 File size: 325547 bytes Optimized: no PDF version: 1.6
And I suspect the other bugs related to draw not opening encrypted PDF file may be the same cause.
back to new as the patch was abandoned due to license issue.
*** This bug has been marked as a duplicate of bug 55425 ***