File hyperlinks to relative path not generated on pdf

[Daniel Gibert]

Not sure if this is by default or a bug.

When I generate an hyperlink to a file, the obtained path of the link is an absolute address. If I change it to become a relative path, no link is added to the pdf on export. The same happens if I paste a custom path to the file, instead of a publisher generated one.

It seems that on pdf publish, Publisher checks the url and if it does not conform to what it expects, it directly omits the link completely on the pdf. This renders Publisher unusable to make PDF linked to files that must be distributed on a pendrive or to link to a 3rd party drive out of the system where the document has been created.

I think that Publisher should create pdf with whatever path you use, with no regard of being valid or not, because you could need to use a precise path at some points.

And no, the option to "include document on export" is of not value here because it destroys the linked document hierarchy and places everything on the same level, which is a big no no.

Steps to reproduce the issue:

• Select text or objets and create hyperlink
• Link to the file (it creates  Users/Xxx/Folder/Folder/Filename.pdf path)
• Modify path to make it relative to where the pdf is gonna be ( Folder/Filename.pdf )
• Export to pdf with links th the correct route for relative links to work.
• The result pdf has no links added at all

If word and indesign does it, why not publisher? is not big science. Just add the link I want.

 

[walt.farrell]

Are you also telling Publisher to include the files when generating the PDF? That's one of the options under More... in the Export dialog, if I remember correctly. It should also simplify the process, as you shouldn't need to play games with modifying the URL.

[Daniel Gibert]

52 minutes ago, walt.farrell said:

Are you also telling Publisher to include the files when generating the PDF? That's one of the options under More... in the Export dialog, if I remember correctly. It should also simplify the process, as you shouldn't need to play games with modifying the URL.

This option is in the hyperlink dialog and, as I mentioned in the post, is not useful as it copies all files on the same directory as the exported PDF, breaking any folder hierarchy and organization. The design I'm working on now consist on a master pdf with links to thousands of research pdfs organized in folders by year and subject, to be distributed on usb drives (preserving that hierarchy). So with no possibility to use relative paths, it is impossible to create that pdf on publisher. And the option to have all pdfs mixed in a single folder is a big no from the customer. 

The solution would have been for Publisher to simply blindly allow the path I wrote instead of forcing an absolute path. Acrobat can perfectly resolve relative paths by itself. I hate to think on it, but this project will force me to use InDesign or (even worst) Word.

[walt.farrell]

Thanks for the clarification.

I doubt that Serif will consider this a bug; it seems more like a Feature Request, since you're trying to use the function in a way that is not supported by the current design.

[Daniel Gibert]

17 minutes ago, walt.farrell said:

Thanks for the clarification.

I doubt that Serif will consider this a bug; it seems more like a Feature Request, since you're trying to use the function in a way that is not supported by the current design.

Thats what i fear. I consider it a "bug" because at the end the path is simply a string of characters in the file path field. I don't understand why it uses it only if is an absolute path. Use what I say and don't think about it.  It should allow to use whatever path you need (even paths to files not in the same machine) but I suppose it depends on how they consider it to be.

And thanks to you for trying to help. I appreciate it a lot.

[walt.farrell]

23 minutes ago, Daniel Gibert said:

I consider it a "bug" because at the end the path is simply a string of characters in the file path field. I don't understand why it uses it only if is an absolute path. Use what I say and don't think about it.  It should allow to use whatever path you need (even paths to files not in the same machine) but I suppose it depends on how they consider it to be.

Users would complain if they allowed invalid links like that, and the generated PDF could not be used by the end-user, so therefore the application needs to validate it.

And they can't just use what you specify, because a file URL like C:\Users\some-name\some-directory\file.name is not a valid URL. The \ is an invalid URL character, and would have to be URL-encoded.

One might argue that they could simply URL-encode the file path, and trust you to have specified it correctly. But that is a function that does not exist. And if you try to URL-encode the file path yourself, the application rejects it because the file does not exist at that location, either.

I still think it's more appropriately a feature request, and for now either you'll need to use a different application or your client will need to accept the files delivered with a different directory structure. Even if it were considered a bug, the likelihood of it being fixed in time for you to deliver your project is very small.

[Dan C]

I've spoken with our QA team regarding this, who confirmed that after updating PDFlib recently within Affinity Publisher, we had to exclude 'invalid' URLs when exporting to PDF as there were many documents failing to export if the URL was not RFC compliant.

This means we now have to check if the URL is 'valid' and we report in preflight if it isn't, and therefore won't export.

It would be nice to include this as a feature, but at this time we would need to change our validation to support it - my sincerest apologies.

I hope this clears things up!

[Daniel Gibert]

Thank you both @walt.farrell and @Dan C for you answers and dedication on this issues.

Fortunately, this work is not a regular one and it is gonna happens once in a loong time, so is not a great issue apart of having to work on other app than Publisher. I understand the reasoning on the valid url limitation. Now that I know that limitation and that is gonna stay in the future I can plan for next cases of use.

Thanks again and big hug to all the team.

[thomaso]

3 hours ago, walt.farrell said:

a file URL like C:\Users\some-name\some-directory\file.name is not a valid URL. The \ is an invalid URL character, and would have to be URL-encoded.

If a file path works in a browser window isn't it RFC compliant? – Not sure if I misunderstand but doesn't the list of RFC compliant include any protocol which works for e.g. USB sticks?

I assume the volume name of the USB-stick will be known when creating the .afpub, right?
To me a test with a file "amphibian car 1.jpg" on an USB stick "FAT_84e" and this path

file:///Volumes/FAT_84e/amphibian%20car%201.jpg

appears to work in an exported PDF without adding the file on export as being copied. It doesn't use APub's default separator \ but uses / instead and has "%20" added for space characters in the file name.

[walt.farrell]

On 10/21/2021 at 1:09 PM, thomaso said:

To me a test with a file "amphibian car 1.jpg" on an USB stick "FAT_84e" and this path

file:///Volumes/FAT_84e/amphibian%20car%201.jpg

appears to work in an exported PDF without adding the file on export as being copied.

The %20 is important, I think, if there are spaces. But getting Publisher to accept the modified file name may be difficult.

But thanks for mentioning that form of "file:" link. That may give @Daniel Gibert a (another?) workaround.

Daniel: Rather than constructing a File Hyperlink, which won't work by itself, you can modify the workflow as follows:

1. Create the File Hyperlink as you wanted to. This will give something like this in the Hyperlink Properties dialog:
   
    
2. Change the Hyperlink type to URL and change the \ characters to / (if needed) URL-encode any odd characters or spaces in the file path name, then click OK:
   
3. Now do your Export.

The exported PDF will link to the file at the location you have specified, at least in my experiments on Windows.

[thomaso]

Is it important, to switch the hyperlink type from "file" to "URL"?

In my test PDF export the link works as type "file" with the adjusted path syntax.

I suppose it would work on every mac with this stick as volume. Note there is no user involved in the path (different to the above Windows sample "C:/Users/Walt/…").

[walt.farrell]

1 minute ago, thomaso said:

In my test PDF export the link works as type "file" with the adjusted path syntax.

You're on Mac, where the / is the correct character. On Windows, the correct character is \ and if I try to construct a "file:" link like that substituting / for \ it is rejected by Publisher. In the Hyperlinks panel it shows with a red X, and it causes Preflight errors, and the link is not included in the exported PDF file.

[thomaso]

So is it more a Windows than a Mac problem? (though Daniel posted this in the mac bugs forum)

On mac an APub file hyperlink by using the path option button "…" creates by default the path like below – probably not RFC compliant because of the spaces:

… whereas the same path created via the Terminal.app would be this:

/Volumes/FAT_84e/amphibian\ car\ 1.jpg

 

[Wosven]

4 minutes ago, Hens said:

on windows and used the "include file on export" through the same option like @thomaso
And it worked fine.

 

9 hours ago, Daniel Gibert said:

And no, the option to "include document on export" is of not value here because it destroys the linked document hierarchy and places everything on the same level, which is a big no no.

 

[thomaso]

4 minutes ago, Hens said:

"include file on export"

This does not help here / solve the OP's issue. (see 1st post: the image folder structure is complex and should be maintained and images should not get copied)

[Wosven]

@Hens it happens, don't worry!

[Guest]

Regarding this issue I have a huge PDF reproduction of a 5 volume 19th century work that includes 11,000 hyperlinks. These links were created when I used QuarkXPress 2019 which I abandoned for my Affinity Publisher. Tonight I finished some revisions and exported the document from Publisher 1.10.3 on my 2019 5K Retina iMac with Monterey 12.0.1.

Before exporting I went to be sure that exporting hyperlinks etc was included. When I exported the document and opened it I discovered much to my consternation that all of the links were gone. The blue highlights were still present but the connections were all gone. Thankfully I did not allow the new copy to overwrite the original or many years of work would have been lost.

Is this a bug? It looks like one to me. I tried exporting or doing a Save As in a couple of other apps on my Mac using the original, and the links were preserved by all of them (PDF Expert, PDFpen Pro, ABBY FineReader PDF, and even Preview).

Is it possible I am missing something and this is not a bug? If it is a missing feature is there a hope of a fix in the near future? 

I am enclosing both the original and the exported file. The b file is obviously the export.

Feel free to enjoy the copies as I created it for use by other scholars without restriction other than not using the portrait for any other purpose but for this document.

96 Sermons volumes 1-5.pdf 96 Sermons volumes 1-5b.pdf

[walt.farrell]

5 hours ago, JohnGregory52 said:

Is this a bug? It looks like one to me. I tried exporting or doing a Save As in a couple of other apps on my Mac using the original, and the links were preserved by all of them (PDF Expert, PDFpen Pro, ABBY FineReader PDF, and even Preview).

Publisher does not have support to import hyperlinks in a PDF document when you Open it. It only picks up the visible text. Confirmed by a Serif staff member here: 

 

[Guest]

Will this change? This issue has been around for a good while. Has Serif and its developers have this in their sites or is it simply a limitation we will have to live with?

[walt.farrell]

1 hour ago, JohnGregory52 said:

Will this change? This issue has been around for a good while. Has Serif and its developers have this in their sites or is it simply a limitation we will have to live with?

No idea. You might look for Feature Requests to see if someone has asked for it (and if not, post one), but Serif generally won't give details of future plans.

[p10n]

On 10/21/2021 at 12:26 PM, Daniel Gibert said:

Not sure if this is by default or a bug.

[...]

If word and indesign does it, why not publisher? is not big science. Just add the link I want.

 

Daniel you are so right! I was referred to your post, from my one, see

I now tried to explain why the current behavior of AP is unnecessarily obstructive (if not buggy), I hope my explanations help.

My solution will be to use AP to create the headlines and background graphics, and insert copy text and the links in LaTeX (using the wallpaper package to include the AP-generated PDF as a background). This has been working very well with PDFs that I have created earlier with Inkscape.