Are you sure the file placed in gdrive (https://drive.google.com/open?id=1S5ElqImAC19ydF4Es3rTkecYYZKcFTWd) contains these attachments?
When I open it in Document Viewer (3.34.1, evince package 3.34.1-1) I don’t see any attachments, nor in gdocs itself (unless gdrive modified it and let me download only what it sees). FYI: you can use evince in Lubuntu too.
I just tested qpdfview version 0.4.18 in the latest Focal (Lubuntu) daily iso and had no problems with opening a pdf file with attachment. In order to open the attachment you have to right click on the attachment icon and select save and open.
Hope this helps.
Thanks Teward. Worked in Okular as you described.
Hi Leok, in qpdf I do not even see any attachments. Can you show where to right click ? May be i need to upgrade my qpdf.
Hi Guiverk. Yes, the file I shared via google drive is indeed the correct file with attachments.
Sorry – not right click but left click …on the attachment icon in the pdf you opened…see my screen capture:
you can see it if you scroll down the page
Leok, you may see my qpdf screenshot in previous posts wherein the embedded attachments thumbnail itself can not be seen, therefore evidently no way to access such attachments. My qpdf version is as follows:-
i would suggest updating qpdf to version 0.4.18 and retry.
I can concur the example file provided by the OP does not work in the most recently released version of qpdfview (also can we please stop confusing this with qpdf which is a thing but is a command line program). Why don’t you provide your example that does seem to work, @leok? It would help for an upstream bug report.
I agree we should refer to qdpfview and not the command line program.
I have retested this several times and the strange thing is that it works sometimes but not always. I tried this with embedded pdf and also jpg files.
I am going to play a bit more with this … and will report later.
Sounds good. I think an example of a file that works and an example of one that doesn’t (even despite the inconsistency, which is really a separate issue) would be sufficient enough to write a bug report which is what should ultimately come out of this. Given that there is support for embedded files or whatever we want to call them, this really isn’t a feature request but an actual bug in intended behavior, so it should get higher priority than a wishlist item.
Here’s an example PDF (from some other open source project, interestingly) that does work consistently in qpdfview.
It does seem to be hidden in an annotation indicated by a 
icon so when you first mouseover, you see “text file” and need to click on it:
Then the icon will be replaced with a 
icon which you can then click to see the save options:
As aforementioned, “Save and open…” will open up the file (called utf8test.txt) which is indeed a text file in Featherpad.
For the purposes of better understanding what we’re dealing with and how to make sure we’re comparing apples and oranges, I took the time to run a hexdump -C against the PDF and you can see how the text file (a stream) is hidden in the annotation.
Here we can see an object of type EmbeddedFile which is of size 4834, which can be confirmed with stat --format='%s':
00004dc0 65 6e 64 6f 62 6a 0a 39 20 30 20 6f 62 6a 0a 3c |endobj.9 0 obj.<|
00004dd0 3c 20 2f 54 79 70 65 20 2f 45 6d 62 65 64 64 65 |< /Type /Embedde|
00004de0 64 46 69 6c 65 20 2f 46 69 6c 74 65 72 20 2f 46 |dFile /Filter /F|
00004df0 6c 61 74 65 44 65 63 6f 64 65 20 2f 4c 65 6e 67 |lateDecode /Leng|
00004e00 74 68 20 32 36 34 39 20 2f 50 61 72 61 6d 73 20 |th 2649 /Params |
00004e10 3c 3c 2f 53 69 7a 65 20 34 33 38 34 3e 3e 20 3e |<</Size 4384>> >|
00004e20 3e 20 73 74 72 65 61 6d 0a 78 9c a5 58 4b 77 13 |> stream.x..XKw.|
Here’s an indication of an object of type Annot (annotation) that has a subtype FileAttachment:
00005880 8d dd 0a 65 6e 64 73 74 72 65 61 6d 0a 65 6e 64 |...endstream.end|
00005890 6f 62 6a 0a 37 20 30 20 6f 62 6a 0a 3c 3c 2f 54 |obj.7 0 obj.<</T|
000058a0 79 70 65 20 2f 41 6e 6e 6f 74 20 2f 53 75 62 74 |ype /Annot /Subt|
000058b0 79 70 65 20 2f 46 69 6c 65 41 74 74 61 63 68 6d |ype /FileAttachm|
000058c0 65 6e 74 20 2f 52 65 63 74 20 5b 32 34 30 2e 39 |ent /Rect [240.9|
Here’s the “text file” string that’s appears in the tooltip:
000058d0 34 34 38 38 32 20 37 35 31 2e 31 38 31 33 33 39 |44882 751.181339|
000058e0 20 32 35 35 2e 31 31 38 31 31 30 20 37 36 35 2e | 255.118110 765.|
000058f0 33 35 34 35 36 37 5d 20 2f 43 6f 6e 74 65 6e 74 |354567] /Content|
00005900 73 20 28 fe ff 00 74 00 65 00 78 00 74 00 20 00 |s (...t.e.x.t. .|
00005910 66 00 69 00 6c 00 65 29 20 2f 50 20 31 31 20 30 |f.i.l.e) /P 11 0|
There’s even a reference to the pushpin:
00005990 20 38 20 30 20 52 20 2f 4e 61 6d 65 20 2f 50 75 | 8 0 R /Name /Pu|
000059a0 73 68 50 69 6e 3e 3e 0a 65 6e 64 6f 62 6a 0a 31 |shPin>>.endobj.1|
And later after some XML metadata, there’s a catalog which defines the name of the attached file:
00006db0 36 20 30 20 6f 62 6a 0a 3c 3c 20 2f 54 79 70 65 |6 0 obj.<< /Type|
00006dc0 20 2f 43 61 74 61 6c 6f 67 20 2f 56 65 72 73 69 | /Catalog /Versi|
00006dd0 6f 6e 20 2f 31 2e 37 20 2f 50 61 67 65 73 20 31 |on /1.7 /Pages 1|
00006de0 20 30 20 52 20 2f 4e 61 6d 65 73 20 3c 3c 20 2f | 0 R /Names << /|
00006df0 45 6d 62 65 64 64 65 64 46 69 6c 65 73 20 3c 3c |EmbeddedFiles <<|
00006e00 2f 4e 61 6d 65 73 20 5b 20 28 75 74 66 38 74 65 |/Names [ (utf8te|
00006e10 73 74 2e 74 78 74 29 20 38 20 30 20 52 20 5d 3e |st.txt) 8 0 R ]>|
Hopefully that helps us dissect whta we’re dealing with.
That said, I’ve seen cases before where PDFs are viewable in one PDF reader but not in others. My feeling about this is that it seems like there are PDF creators out there that make PDFs that do not strictly adhere to the PDF format, but some readers cheat and let them slide. Perhaps they’re using deprecated features? That might be another explanation for why one thing works and another doesn’t.
I’m working at tackling the original example but since it’s not so simple of a file it’s a lot harder to manage
So the most interesting thing I find about this file that doesn’t work is that it doesn’t include any portion of the “EmbeddedFile” type, nor any reference that I can find to the names of the two embedded files:
001. INDEX SHEET.pdf002. PLEADING.pdfDespite that, it looks like it’s pretty standard software (indeed the canonical PDF creator) creating the file:
006de900 20 20 20 20 20 20 20 20 20 3c 78 6d 70 3a 43 72 | <xmp:Cr|
006de910 65 61 74 6f 72 54 6f 6f 6c 3e 41 64 6f 62 65 20 |eatorTool>Adobe |
006de920 41 63 72 6f 62 61 74 20 50 72 6f 20 39 2e 30 2e |Acrobat Pro 9.0.|
006de930 30 3c 2f 78 6d 70 3a 43 72 65 61 74 6f 72 54 6f |0</xmp:CreatorTo|
006de940 6f 6c 3e 0a 20 20 20 20 20 20 3c 2f 72 64 66 3a |ol>. </rdf:|
That tells me that this might be harder than we think to figure out.
Ok I found mutool (from the mupdf-tools package) which seems to be helping with parsing via mutool show /path/to/file.pdf grep.
The good file has, among other things, clearly defined references to the embedded file.
example_041.pdf:7: <</Border[0 0 0]/Contents<FEFF0074006500780074002000660069006C0065>/CreationDate(D:20150802122217+00'00')/F 4/FS 8 0 R/M(D:20150802122217+00'00')/NM(0001-0000)/Name/PushPin/P 11 0 R/Rect[240.94489 751.18136 255.1181 765.35458]/Subtype/FileAttachment/Type/Annot>>
example_041.pdf:8: <</EF<</F 9 0 R>>/F(utf8test.txt)/Type/Filespec>>
example_041.pdf:9: <</Filter/FlateDecode/Length 2649/Params<</Size 4384>>/Type/EmbeddedFile>>
⋮
example_041.pdf:16: <</Lang<FEFF0065006E>/Metadata 15 0 R/Names<</EmbeddedFiles<</Names[(utf8test.txt)8 0 R]>>>>/OpenAction[11 0 R/FitH null]/PageLayout/SinglePage/PageMode/UseNone/Pages 1 0 R/Type/Catalog/Version/1.7/ViewerPreferences<</Direction/L2R>>>>
Looking at our problem child it doesn’t look so problematic after all, though the definitions are different and there’s JavaScript, which is odd, but it seems to be the thing that warns about the embedded files (e.g. in okular):
ITA-560-2005.pdf:97: <</Desc<>/EF<</F 29 0 R>>/F(001. INDEX SHEET.pdf)/Thumb 34 0 R/Type/Filespec/UF(001. INDEX SHEET.pdf)>>
ITA-560-2005.pdf:98: <</Desc<>/EF<</F 30 0 R>>/F(002. PLEADING.pdf)/Thumb 33 0 R/Type/Filespec/UF(002. PLEADING.pdf)>>
⋮
ITA-560-2005.pdf:136: <</EmbeddedFiles 68 0 R/JavaScript 137 0 R>>
ITA-560-2005.pdf:137: <</Names[(ADBE::FileAttachmentsCompatibility\000)138 0 R]>>
ITA-560-2005.pdf:138: <</JS(var v = app.viewerVersion;\nif \(v < 7\)\n{\n\tvar n = 0;\n\tif \(this.dataObjects != null\)\n\t\tn = this.dataObjects.length;\n\tif \(v >= 5 && v < 6 && n > 0 && \(app.viewerVariation == "Full" || app.viewerVariation == "Fill-In"\)\)\n\t{\n\t\tif \(this.external\)\n\t\t\tapp.alert\("This document has file attachments. To view the attachments, click the Save button to save a copy of the document, open the copy in Acrobat, and use the File > Document Properties > Embedded Data Objects menu.", 3, 0\);\n\t\telse\n\t\t\tapp.alert\("This document has file attachments. Use the File > Document Properties > Embedded Data Objects menu to view the attachments.", 3, 0\);\n\t}\n\telse if \(v >= 6 && v < 7\)\n\t{\n\t\tif \(n == 0\)\n\t\t{\n\t\t\tvar np = this.numPages;\n\t\t\tsyncAnnotScan\(\);\n\t\t\tfor \(var p = 0; p < np && n == 0; ++p\)\n\t\t\t{\n\t\t\t\tvar annots = this.getAnnots\(p\);\n\t\t\t\tif \(annots != null\)\n\t\t\t\t{\n\t\t\t\t\tfor \(var i = 0; i < annots.length; ++i\)\n\t\t\t\t\t{\n\t\t\t\t\t\tif \(annots[i].type == "FileAttachment"\)\n\t\t\t\t\t\t{\n\t\t\t\t\t\t\tn = 1;\n\t\t\t\t\t\t\tbreak;\n\t\t\t\t\t\t}\n\t\t\t\t\t}\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t\tif \(n > 0\)\n\t\t{\n\t\t\tif \(this.external\)\n\t\t\t\tapp.alert\("This document has file attachments. To view the attachments, click the black triangle at the top of the document window's vertical scrollbar and choose File Attachments.", 3, 0\);\n\t\t\telse\n\t\t\t\tapp.alert\("This document has file attachments. Use the Document > File Attachments menu to view the attachments.", 3, 0\);\n\t\t}\n\t}\n}\n)/S/JavaScript>>
Using pdfinfo from the poppler-utils package (qpdfview uses Poppler libraries for PDF processes), it seems that there aren’t any other glaring differences and they are indeed using the same PDF version (1.7). Finally using pdfdetach -list on both files shows the correct filenames as being attached to the PDF.
I also tested further and as far as I can see the big difference in the OP file (ITA-560-2005.pdf) is that it is an Adobe Portfolio created file. I do not know if this significant but I created several pdf files with added attachments (made in Adobe Reader) and not Portfolio files and I could open them in both qpdfview version 04.17.99 and 04.18.00.
@leok I think you mean Pro not Portfolio (see “Creator” in pdfinfo). Anyways I wouldn’t expect THE canonical PDF tool to create non-standard PDFs.
I found some other example files mentioned here. I actually looked at the containing folder of the example files and found a few more. They’re almost all made in Acrobat PDFMaker for Word (again, canonical tool) and except for the one with the file hidden in the annotation, none of them work in qpdfview (well the embedded videos show but they don’t play; that might be a different issue).
Long story short, I think we can safely conclude that embedded files are not working properly in qpdfview unless they are defined to somehow show in the PDF itself. So I think we have a well defined bug report. You want to file it @leok or should I?
@wxl - Actually I was referring to Adobe PDF Portfolio (created by Adobe Pro ) which are according to Adobe “multiple files assembled into an integrated PDF unit” as opposed to a pdf file containing an attachment (independant pdf file).
I will file the bug report in the morning. 
Cool, thanks! Please post a link here.
@leok in what way (given the likes of pdfinfo, mutool, or some other tool) can someone verify that a particular PDF is in this Portfolio format? I mean besides that image that gets displayed, which might actually be a false positive.
@wxl - I am not sure but will look into it. I notice that if the files in my example in the bug report are opened in Adobe Reader - selecting “view” from the drop down menu includes the selection"portfolio" for the file ITA-560 but not in the file “test1.pdf” .
Maybe we should take a good look at this info from Adobe:
(http://www.adobepress.com/articles/article.asp?p=1688701)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.