Tried to use the pdfium based 'Insert as image' for a PDF exported from 24.2 or 25.2 builds. Both had the passwords "open" and "permission" set for the PDF Security dialog. When insert as image was attempted to Draw canvas or Writer document: was expecting a password prompt to allow pdfium read of the PDF stream. Instead LO responds with 'Image filter not found' error. The encryption stanza inside the PDF shows /Filter/Standard/V 2/Length 128/R 3/ So is that choking the pdfium filter? Or does the pdfium insert just not know what to do with a password encrypted PDF? =-tested-= Version: 7.6.6.3 (X86_64) / LibreOffice Community Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 24.2.5.1 (X86_64) / LibreOffice Community Build ID: 2ccb78ad6bdfe3f3356a7a7f294ec388775c5816 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b61a0737e3600aadf42f28a15c70aface9ab61e CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Same LO document exported to PDF without password/encryption makes the round trip "Insert as image" with no issue. @Miklos, * Is this an issue with our V2 level PDF export, or a limitation of recent pdfium lib handling (we claim PDF 1.7 but encrypt V2)?
And should have noted that the password "protected" PDF does open into Draw with either the "owner" or the "user" password provided at the LO 'Enter Password' popup. So we can read it, filter import it back into draw with poppler. And this is just affecting the pdfium based insert.
(In reply to V Stuart Foote from comment #2) > And should have noted that the password "protected" PDF does open into Draw > with either the "owner" or the "user" password provided at the LO 'Enter > Password' popup. > > So we can read it, filter import it back into draw with poppler. And this is > just affecting the pdfium based insert. Likewise when opened into Chrome browser, where either the open or the permission pw is parsed when prompted and entered. So seems pdfium can handle it when fully configured.
Hi, a sample file to insert as image, could be of help.
Created attachment 196291 [details] 24.2.5 PDF exported with user and permissions pw, for testing 'Insert as image' user - 1234 permissions - 4567
Reproducible Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b61a0737e3600aadf42f28a15c70aface9ab61e CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Right, probably just nobody implemented an interaction handler while opening a PDF as an image, so you fail without a password. Sounds like adding this small feature is a matter of somebody doing the work. :-)
(In reply to Miklos Vajna from comment #7) > Right, probably just nobody implemented an interaction handler while opening > a PDF as an image, so you fail without a password. Sounds like adding this > small feature is a matter of somebody doing the work. :-) OK, now an enhancement to do so...
Hi Dave, if you've got the cycles, another facet for our PDF password handling but for the pdfium as graphic filter via the 'Insert...' dialog. attachment 196291 [details] has protected PDF has both user pw and permissions pw, "1234" and "4567" respective. Either will import open the PDF, into draw or writer depending on the filter selected. But unable to insert the PDF as an image/graphic, regardless of module for each attempt get the Warning "Image filter not found". Inserting non-protected PDF we have no issue in any module. Assume the recent PDF v2 pw handling has not improved things for the insert filter. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e4fb32ffef1630ceaf5a0a77307e02ae93c9f8f4 CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Hi, Yeh I can have a look - but I've not delved into the insert-as-image code so far, there are quite enough bugs in the other importer to keep me busy :-) but I'll have a look and see if I can find it.
vcl/source/filter/ipdf/pdfread.cxx ImportPDFUnloaded() is the entry point for the insert-as-image PDF code, I think. I have to confess I find encrypted PDF images a bit strange, though. :-)
Thanks. just confirmed I can reproduce it easily here; warn:vcl.filter:857088:857088:vcl/source/pdf/PDFiumLibrary.cxx:625: PDFiumImpl Error: 'Incorrect password or password is required' Error number: 4 warn:vcl.filter:857088:857088:vcl/source/filter/ipdf/pdfread.cxx:111: ImportPDF: empty PDF data array I'll have a look.
Oh yeh, that ain't going to work: RenderPDFBitmaps std::unique_ptr<vcl::pdf::PDFiumDocument> pPdfDocument = pPdfium->openDocument(pBuffer, nSize, OString()); ^^^^^^^^^ that'll be why it doesn't work, password goes there :-)
OK, started looking this in detail. Essentially there are two things that need doing: a) Routing an interactionhandler down b) Grabbing the password a) is probably best done by a set of filteroptions like it's done in the PDF code and in the filter export path - which also gives us somewhere to stash the password, which I think we need to do because there are two places that open the document in the filter; I guess one is a test and the other is the real open like in the poppler based path. b) Hmm well, there's sfx2::RequestPassword() and there's sdext/source/pdfimport/misc/pwdinteract.cxx's set - they're a bit different; perhaps I should move the sdext one to somewhere shared (suggestions where?)
This is of course a bit more subtle than expected; there's ~3 places the ipdf code uses pdfium to open the pdf, curiously the RenderPDFBitmaps is not the first one. That's actually 'convertToHighestSupported' in pdfcompat.cxx There's some stuff I don't understand; if you insert a PDF and look at the odg it has stored the pdf and a png of the rendered image; if you reopen the odg it rerenders the PDF rather than using the image - which then means we also have a problem about what happens to the password. (A double oddity here is that if I load that odg with Fedora's build which doesn't have pdfium linked in to LO, it renders as a white rectangle; not using the image I can see in the odg) I'm hoping that the way convertToHighestSupported works is that it resaves the pdf after a conversion to a given version, so if it reads it OK then it might reexport without the password, so everything else is done on the stored, decrypted pdf. (Third oddity; I could swear there used to be a way to save the original PDF after inserting as image, but I can't find it in the GUI)
Hmm it's more complex for some reason I've not figured out yet; I've got convertToHighestSupported now asking for a password, and it now resaves what I *think* is an unpassworded version; but the rest of the code isn't using it - it's still referencing the original PDF; and also importantly it's the original PDF that gets saved into the odg file as well. I've got to follow to see what the whole point of convertToHighestStupported is, if it's output isn't used for the rest of it.
I think convertToHighestSupported() is about a use-case where you insert a PDF image using PDF 1.7, but the LO PDF export would emit PDF 1.6, so you need to downconvert the PDF image to an older PDF markup. I believe this was initially added in core.git 37bdf1659ddb11d8706289511623cc7c8b0d264b
(In reply to Miklos Vajna from comment #17) > I think convertToHighestSupported() is about a use-case where you insert a > PDF image using PDF 1.7, but the LO PDF export would emit PDF 1.6, so you > need to downconvert the PDF image to an older PDF markup. I believe this was > initially added in core.git 37bdf1659ddb11d8706289511623cc7c8b0d264b OK, I hadn't appreciated that there was any link between import and export; I'd assumed this import just stashed the image and that was what the export ended up exporting. So now we have at least 3 things in play: a) The original PDF b) The 1.6 downconverted version for export c) The images That downconversion for export is actually the 1st pdfium call that we do on import, but then nothing else uses the result of that (except I guess the export?!) - which is a pain, since having fixed it to ask for the password, the converted copy would now be great for it to use everywhere else. I also need to make sure the version that's saved into the odf is decrypted. OK, so I'll go and hunt down where the next PDFium open calls are coming from; and understand where (a) and (b) above are both stored in.
> That downconversion for export is actually the 1st pdfium call that we do on import Hmm, I imagine that idea was that vcl::pdf::createBinaryDataContainer() does the conversion once, instead of storing the original bytes and then downconverting again and again. And that "binary data container" is attached to the Graphic, so other code actually gets the data from there. Anyhow, just an idea: what if you ask for the password during insertion (as part of the UI), so the doc model never has an encrypted PDF? I'm also a bit unsure if anybody would be concerned that now we store something decrypted that was previous protected by a password...
(In reply to Miklos Vajna from comment #19) > > That downconversion for export is actually the 1st pdfium call that we do on import > > Hmm, I imagine that idea was that vcl::pdf::createBinaryDataContainer() does > the conversion once, instead of storing the original bytes and then > downconverting again and again. And that "binary data container" is attached > to the Graphic, so other code actually gets the data from there. That is what I was hoping was going to happen having wired it up. > Anyhow, > just an idea: what if you ask for the password during insertion (as part of > the UI), so the doc model never has an encrypted PDF? That's my intention; I just need to go and follow it all through to understand which copy of the PDF is stored where and which ones the different PDFium calls use. > I'm also a bit unsure if anybody would be concerned that now we store > something decrypted that was previous protected by a password... Yep; but in the end we can't perform magic.
OK, a little further; I've now got it correctly displaying the decrypted pdf. It turns out that by default if PDFium loads a password encrypted PDF and you ask it to save it again it reencrypts it - and that happens during the code I'd previously patched. Now, the one bit that doesn't work for me is that when I save the odg/odt it writes the encrypted stream in there, and on loading doesn't ask for the password.
Right, I seem to have that working, https://gerrit.libreoffice.org/c/core/+/185759 is my WIP; I wouldn't review it yet until I clean it up.
OK, everything has passed, but I've had to rebase for an android/meson/python thing that I've not touched, so the other ones will trickle in.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c1cdf4cd9cb2dbebe53fd7100ccc8f5ee46fbbb7 tdf#162826: vcl: Plumb InteractionHandler down It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4d653db5c6b3fe32e3f3b527a7e2acf866cae69c tdf#162826: sfx2: Get InteractionHandler It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/894fccf8c518ecc12e6430a6ff93c27a4967255b tdf#162826: vcl: ipdf: Plumb InteractionHandler through ipdf It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/32534b76eaa95fde79435ff0c325f24234cbe84d tdf#162826: Move pdf pwdinteract It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8521a05c3aa2266106e2eb1c3084518fe272630e tdf#162826: Ask for pass in convertToHighestSupported It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/87ba2a139af771e459f08ceccc8b52f7f69b926d tdf#162826: sw: Get InteractionHandler It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/aa5629a48b0c181e02c26f6f0f25d99c5797bffa tdf#162826: vcl: pdfium wrapper: add 'remove security' option It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b0cb139e4fab79f8c818cf7f13f526486692cd03 tdf#162826: Add logging in save flow It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/865237bc3d646500a26f6ebb0487ce06332bab87 tdf#162826: vcl: ipdf: Clean up isCompatible It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bb8fccd3655dca712d6dd414cc274861bd7b0462 tdf#162826: ipdf: Convert for encrypted, correctly versioned, files It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/72efc1d55d546dee49f732432299810f6be5529c tdf#162826: ipdf: Route bEncrypted up It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1f30bcbbddf0677450ba167ba74c75b57527b505 tdf#162826: vcl: Make readPDF stash unencrypted pdf It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
OK, with that pile in, I think we're done. It could do with a test adding (which would be insert->save->load check we've still got the PDF) There's also a suggestion during a review that it might be good to somehow warn the user that they're going to be saving the unencrypted PDF in the LO file; if anyone can think how to do that we can add it.