link to embedded files?

[pr-apes]

@pgundlach,

there is a PDF feature (extremely handy to help people when dealing with embedded PDF documents): link to embedded PDF documents (or "embedded go-to action" in PDF jargon, https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf#G11.2048909).

Since I would be the only user benefiting from this (at least, before it is implemented), I'm interested in contributing the code.

As always, I'm not sure the code will work or it will be ready to merge as it will be.

But first of all (before starting to imagine how this could be implemented), would you be interested in having such feature in Publisher?

BTW, this only works with Acrobat and with current version of PDF.js in Firefox (Chrome/Edge don't know how to deal with attachments).

As a sample document, you have https://issues.apache.org/jira/secure/attachment/12911235/Sample%20GoToE%20Link.pdf (link to embedded PDF doc the frame on the upper left corner of the page).

The spec offers many possibilities, but I think the only implementation which would reasonably fit in Publisher would be /XYZ destinations to page numbers (with values 0 0 null) to children embedded files (such as in the sample above).

Let me know what you think of this. Many thanks for your help.

[pgundlach]

That would be very cool! Do you think the <A ... > command is a good command to do that? Perhaps <A file="..."> or something?

[pr-apes]

I think <A href="..." should be fine, given the following:

1. href contains no protocol (maybe not having :// or mailto:).
2. The file specified in href exists.

Given that, there could be a line such as (in fact, I have modified this and it works):

    local str = string.format("/Subtype/Link%s/A<</Type/Action/S/GoToE/NewWindow true/D[0 /XYZ 0 0 null]/T<</R/C/N (%s)>> >>",border,href)

The default will be to open a new window (seems reasonable to me to show that this is not another location in the same document).

This implementation only goes to the first page. But there could be two modifiers (according to https://www.rfc-editor.org/rfc/rfc8118.html#section-3), just after the document name (such as in document.pdf#modifier). They are mutually

• page=<integer>: page number of the document (other than one, actual destination value is zero-based).
• nameddest=<named destination>: named destination defined in the embedded document.

Named destinations could be also specified as in PDF32000_2008.pdf#G11.1947713 (no need for the nameddest key).

[pgundlach]

As the command is just linking to an embedded file (which should be attached with <AttachFile>, I think href="..." is not a good choice. For example: <A href="myimage.png">....</A> should point to a local file on the harddrive and not to an embedded/attached file. Perhaps there should be a new scheme like href="embed://filename.pdf" or there should be a new attribute <A embedded="filename.pdf">...</A>.

[pr-apes]

Sorry. @pgundlach, I spend some time cooking a patch to publisher.lua:

--- C:\utilidades\speedata-publisher\sw\lua\publisher.lua
+++ C:\utilidades\other_publisher\sw\lua\publisher.lua
@@ -7173,14 +7173,41 @@
     return url
 end
 
+local function parse_url(url)
+    parsed_url = {}
+    parsed_url.fn = utf8_to_utf16_string_pdf(url:match("^(.+)#") or url)
+    if url:match("#") ~= nil then
+        if url:match("nameddest=") then
+            url_nd = url:match("nameddest=(.+)&") or url:match("nameddest=(.+)")
+        elseif url:match("#page=") ~= nil then
+            url_pg = tonumber(url:match("page=(%d+)")) - 1
+            parsed_url.dest = ("[%s /XYZ null null null]"):format(url_pg)
+        else
+            url_nd = url:match("#(.+)&") or url:match("#(.+)")
+        end
+        if url_nd then
+            parsed_url.dest = utf8_to_utf16_string_pdf(url_nd)
+        end
+    else
+        parsed_url.dest = "[0 /XYZ null null null]"
+    end
+    print(url_nd or url_pg)
+end
+
 function hlurl(href)
     local border = "/Border[0 0 0]"
     if options.showhyperlinks then
         border = string.format("/C [%s]",getBordercolor(options.hyperlinksbordercolor))
     end
+    parse_url(href)
     href = urlencode(href)
     href = escape_pdfstring(href)
-    local str = string.format("/Subtype/Link%s/A<</Type/Action/S/URI/URI (%s)>>",border,href)
+    local str
+    if href:match("://") ~= nil or href:match("@") ~= nil then
+        str = string.format("/Subtype/Link%s/A<</Type/Action/S/URI/URI (%s)>>",border,href)
+    elseif href:lower():match("%.pdf$") ~= nil or href:lower():match("(%.pdf)#") ~= nil then
+        str = string.format("/Subtype/Link%s/A<</Type/Action/S/GoToE/NewWindow true/D %s /T<</R/C/N%s>>>>",border,parsed_url.dest,parsed_url.fn)
+	end
     hyperlinks[#hyperlinks + 1] = str
     return #hyperlinks
 end

On naming conventions, href="embed://doc.pdf#whatever would require embedding the file (if it is not already embedded).

If you think <A embed="doc.pdf">...</A> is the way to go, I cannot evaluate this now.

Just in case it might help.

[pgundlach]

Somehow this works but gives PDF errors:

I need to look into this.

But this is a good start. Thank you.

[pr-apes]

From https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf#G11.2097000:

The name of the file in the EmbeddedFiles name tree.

I do not know how this is handled in PDF-2.0.

The output from one /GoToE entry reads:

  /A <<
    /Type /Action
    /S /GoToE
    /NewWindow true
    /D [ 6 /Fit ]
    /T <<
      /R /C
      /N <FEFF0061002E007000640066>
    >>
  >>

And /Names read:

  /Names <<
    /EmbeddedFiles <<
      /Names [ <FEFF0061002E007000640066> 3 0 R ]
    >>
  >>

Sorry, but if the UTF16 enconded string in /N is considered an array, I only converted the UTF8 encoded string to UTF16 (to get Unicode chars in filenames working).

Just in case it might help.

[pr-apes]

Just for the record, from https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf#page=429:

1 0 obj % Link to a child
   << /Type /Action
      /S /GoToE
      /D (Chapter 1)
      /T << /R /C
      /N (Embedded document) >>
   >>
endobj

I wonder whether what Preflight might be complaining about the /Action dictionary not being indirectly referenced to the link annotation (/Subtype /Link) it belongs to.

Just in case it might help.

[pr-apes]

The Arlington PDF Model requires for the name in the target document when it is child:

fn:IsRequired((@R==C) && fn:InNameTree(trailer::Catalog::Names::EmbeddedFiles)

As far as I know, the condition is met.

I mean, the UTF16 string is exactly the same in /N:

/A <<
  /Type /Action
  /S /GoToE
  /NewWindow true
  /D [ 6 /Fit ]
  /T <<
    /R /C
    /N <FEFF0061002E007000640066>
  >>
>>

As the one in /EmbeddedFiles:

/Names <<
 /EmbeddedFiles <<
   /Names [ <FEFF0061002E007000640066> 3 0 R ]
 >>
>>

This is beyond my knowledge, I must say.

[pr-apes]

BTW /ProcSet seems to be deprecated since version 1.4.

[pr-apes]

Many thanks for your help.

[pr-apes]

It seems that the Arlington PDF had issues validating names for target dictionaries (in /GoToE actions).

Using the latest release of the validator seems to have solved the issue (when compared with older releases [such as this one]).

Many thanks for your help.

[pr-apes]

As for the naming conventions, I would say again href="embed://doc.pdf#whatever would require embedding the file (if it is not already embedded).

In that case, other attributes from <AttachFile> (such as description, name and type).

[pgundlach]

Here is an update (version 4.15.11)

1. I still get errors in Adobe Acrobat using preflight
2. I chose to stay with the combination of AttachFile and A embed="..."
3. Linking to a page seems to work
4. Linking to a named destination does not work with my examples

So this implementaiton is not perfect and not finalized, but maybe a start.

[pr-apes]

Many thanks for the new release, @pgundlach.

1. If Preflight isn't updated (and I have no idea of how it is updated), I think there is no reason not to have the same error message.
2. If <A embed="…"> requires <AttachFile>, I think that <A embedded="…"> makes more sense. Sorry, but the link is to a file which has been embedded, not to a file that Publisher is about to embed.

What I have discovered is that both attributes page and link may be used here instead of using expressions such as document.pdf#nameddest=identifier or document.pdf#page=25 (they are mutually excluding).

The implementation would be easier too.

[pgundlach]

Thank you very much for your answer. I will change the implementation and then I will give an update here.

[pgundlach]

Version 4.15.13 has:

<A embedded="..."> 

with page="123" or link="nameddest" (which seems to work now)

[pr-apes]

Many thanks for your fast update, @pgundlach.