Unable to view pdf attachments

[psem]

Hi. I am new to linux and still learning my way around it. I am unable to view a pdf which has attachments on my qpdf viewer on lubuntu but i can view it on ubuntu. Does qpdf not support pdf with atachments ? What alternative software can i use ?

[wxl]

What is a PDF with attachments? Could you provide an example?

[leok]

This works fine for me in qdpf…right click on the attachment in the pdf and select “save and open”.

[psem]

Have uploaded the screenshot. It asks me to install adobe acrobat. Right click shows no worthwhile option to expand contents, whereas on Ubuntu, on the left panel, there is a attachment button upon which if one clicks, the contents can be viewed.

The file can be downloaded here :- https://drive.google.com/open?id=1S5ElqImAC19ydF4Es3rTkecYYZKcFTWd

[wxl]

Upload the file somewhere so we can see. It might be a problem with the file, not the program.

[psem]

Here is a screenshot of the file in Document Viewer in Ubuntu, where the attachments on the left can be seen and can be viewed but i do not find any similar option in qpdf in Lubuntu
The file can be downloaded here :- https://drive.google.com/open?id=1S5ElqImAC19ydF4Es3rTkecYYZKcFTWd

[teward]

I can confirm this issue in the latest daily ISO. qpdfview does not seem to be able to handle the concept of file attachments inside a PDF document (which is something that is becoming more and more common in certain circles and different types of documents that are encrypted).

[psem]

Is there another program I can use on Lubuntu to open such PDFs with attachments?

[teward]

You can install Okular - sudo apt install okular on the command line - it has an Embedded Files option to view Embedded Files (under the “File” menu) which will let you view/open attachments inside PDFs by first saving/exporting them to somewhere else to then open them.

I just confirmed this myself as “working” in the latest development version of Lubuntu while tracing this down.

[guiverc]

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.

[leok]

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.

[psem]

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.

[leok]

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

[psem]

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:-

[leok]

i would suggest updating qpdf to version 0.4.18 and retry.

[wxl]

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.

[leok]

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.

[wxl]

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.

[wxl]

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

[wxl]

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.pdf
• 002. PLEADING.pdf

Despite 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.