Enhancement: add an action type that allows referring to a non-PDF embedded file.

[faceless2]

We recently hit a PDF for remediation which had a 150MB file attached as a data URL in a goToURL Action - the file was stored as a String.

I suspect we can all agree is this is not a good approach! But actually, it's not currently clear if we have a method in PDF to select a non-PDF embedded files - even if select just means display it in the File Attachment tab, or open a prompt to save it to disk.

• Launch take a file specification, but seems intended for external files rather than internal. It's also disallowed in PDFA.
• GoToE works with embedded files, but only PDF files: a D array defining the destination in that file is required.

The ongoing project to handle email archiving in PDF will likely find value in being able to refer to a non-PDF attachment. So I think there is a good case for either adding another action type which selects the embedded file, or ensuring that the Launch action is refreshed (ie. the documentation and/or properties are updated) to ensure it's clear that launching an embedded file is allowed.

I have a slight preference for a new action, because (eg) a LaunchE action could be allowed in PDF/A-5 whileLaunch remains disallowed. Another possibility is relaxing the requirements on GoToE so that the D array is optional, and linking to a non-PDF file is allowed, although we then have the question of whether such a file would be valid in PDF/A-3 or A-4.

For reference I attach one of my tests - the first link is a GoToE action to the embedded PNG file, the second is a Launch action to the same. Neither work in the PDF viewers I tested, although I think the Launch action is technically valid.

embedded-link.pdf

[lrosenthol]

Launch works with all forms of file spec dictionaries, including embedded files. It's been used for decades as way to have a button (or other UX element with action attached) that would open up an embedded file.

That said, there are certainly security concerns here with some of the "auto-actions" (e.g. doc open, page open) could case this to happen and so some well known implementations either block Launch or bring up UX for users to approve it.

Since there is no requirement for a processor to offer a UX listing attachments (except in PDF/A-3 and PDF/A-4), having an action that "selected the file" would be problematic.

GoToE, just as with the other GoTo actions are strictly for PDF files - Launch is the equivalent for non-PDFs.

[faceless2]

Well that's great, but as it's not working in "some well known implementations" you can see how I came to the conclusion new functionality was required - there was no UI response from the click at all. I presume the author of the software that generated the attachment as a goToURI came to the same conclusion.

Bugs aside, if that's an intended use of Launch and you want to close this that's OK by me. In that case a slightly different question is: should we consider allowing Launch for embedded files only in a future revision of PDF/A? There's no risk of link rot with an embedded file, and presenting a "Save" dialog doesn't seem to come with any egregious security concern.

[lrosenthol]

should we consider allowing Launch for embedded files only in a future revision of PDF/A?

Now that we have embedded files as a more standard concept in PDF/A - that seem like a reasonable conversation!

[faceless2]

Great that's good news, thanks Leonard.

Although just to follow up my original point, I've now tested a larger sample. Of the six PDF viewers that have UI support for opening or saving attachments, not one of them supports doing this via a Launch action.

So if Launch is indeed the way to do this, that fact is not getting through to developers - and as I'm including our own PDF viewer in this list, I'm one of them. There might be a case for a note explicitly stating this is one of the purposes of Launch in the spec.

[bdoubrov]

Discussed at PDF/A TWG and decided this is not for the dated revision.