Working with hyperlinks/anchors in Publisher

[Nathan Shirley]

I have a Publisher project that includes about 200 hyperlinks pointing to anchors. Most of the anchored objects are embedded PDFs. Is there a way to easily change an anchor from one object to another without breaking the hyperlink pointing to it (so the hyperlink points to the new anchor instead of the old, and the old anchor is removed)? Or in other words, is there a simple way to change the "target" of a hyperlink?

I need to do this to get around Publisher's bug where exporting a project to PDF fails when the project includes hyperlinks that point to PDFs. I've been putting it off hoping Affinity will eventually fix the bug (or add the ability to have more than one index), but I need to go ahead and resolve this.

[walt.farrell]

Double-click on the hyperlink in the Hyperlinks panel, and you'll get the dialog where you can change the hyperlink type or what it points to. Sounds like you may want a hyperlink to the page the embedded PDF is on, not directly to the PDF. Or possibly to a text header or caption above/below the PDF.

You'll probably need to add the new anchor before you can edit the hyperlink to it.

[Nathan Shirley]

Many thanks, tedious but seems like it should work.

[walt.farrell]

You're welcome.

[Nathan Shirley]

That was rough, but I eventually got through them all. Exporting to PDF still failed, so I went through them again and caught a single hyperlinked PDF I had missed and fixed it. Unfortunately I must have compounded bugs here, as exporting still fails. I can export chunks of it that seem to work on their own, but exporting the entire thing fails. So basically I'm back to square one, where I've been for...about 10 months now?

I'm a little worried that since I started this project back when Publisher was new, I might have picked up some problems by continuing a big project through all the different versions. Who knows? Or maybe it's just that buggy?

[walt.farrell]

Have you tried a binary search to find a page that is causing the problem?

Or enabling PDFLib Logging, and examining the log file?

 

[Nathan Shirley]

I did a couple PDFloggings months ago, but I was unable to make much sense of them, and you found something that seemed to be a red herring. I could try it again I suppose.

How would I go about running a binary search?

By the way, I can export the PDF with no issues if I turn off hyperlinks.

[Dan C]

@Nathan Shirley, if you can please run the PDFlib.log batch file and then try exporting to PDF with hyperlinks enabled, it should generate a log even if the app fails to create the file.

If you can then provide a copy of this log file here, I'll be happy to investigate further

[walt.farrell]

48 minutes ago, Nathan Shirley said:

How would I go about running a binary search?

Roughly:

1. Split the file in half.
2. Test lower half of file. If problem occurs, continue working with that half.
3. Otherwise, test upper half. If problem occurs, continue working with that half.
4. If problem doesn't occur with either half, this approach didn't work. Stop.
5. Otherwise, if you have more than 1 page in the file half that you are working with, resume at step 1 with the half you are currently using. You're done when you have only 1 page left, and it's failing. Then you know that page is causing the problem. Examine carefully and try to see what's wrong.

[Nathan Shirley]

Thanks. I've attached the pdflib.log file.

2 hours ago, Dan C said:

@Nathan Shirley, if you can please run the PDFlib.log batch file and then try exporting to PDF with hyperlinks enabled, it should generate a log even if the app fails to create the file.

If you can then provide a copy of this log file here, I'll be happy to investigate further

pdflib.log

[Nathan Shirley]

I see. Yes I've tried this process, but it isn't narrowing down the problem to a certain page. For example, If I export pages 427-442, the export works. If I export 426-442 it fails. But exporting just 426 works. Even exporting 1-437 works.

2 hours ago, walt.farrell said:

Roughly:

1. Split the file in half.
2. Test lower half of file. If problem occurs, continue working with that half.
3. Otherwise, test upper half. If problem occurs, continue working with that half.
4. If problem doesn't occur with either half, this approach didn't work. Stop.
5. Otherwise, if you have more than 1 page in the file half that you are working with, resume at step 1 with the half you are currently using. You're done when you have only 1 page left, and it's failing. Then you know that page is causing the problem. Examine carefully and try to see what's wrong.

[Nathan Shirley]

So the limits on either end are:

Exporting 1-437 works. But 1-438 fails.

Exporting 427-442 works. But 426-442 fails.

Page 438 is most likely causing bugs, because that page has almost 200 hyperlinks (that's the page I created an index by hand). The thing is, I've painstakingly gone through every single hyperlink and rerouted the ones that pointed to PDFs (avoiding the known bug) and deleted the old anchors. I even double checked all of these.

[Dan C]

Many thanks for the PDF log provided - unfortunately this log appears to be for a PDF export that completed, as there are no error messages shown in the log and it ends as expected, with the PDF document being written.

I can see above that you have been testing different exports, and this log will only store information from the most recent export - can you please try exporting the full file once again, so that the PDF export fails, then immediately attach the log file once again here for me

[Nathan Shirley]

Oh sorry about that. I thought I had sent that right after a failed export, but I guess it's possible I did another and didn't realize it had overwritten the failed log...

I'm attaching a new one which definitely just failed.

Oh...now I see what happened. The log file was almost 150 mb and the upload failed. I must have tried a different export later that worked, and seeing the new log file assumed it was the original and that I must have grabbed the wrong one as this one was much smaller. Anyway, trying to upload gives me the attached message.

I'll upload elsewhere and send a link.

pdflib.log

[Nathan Shirley]

Okay this is a little strange, I can open and read the contents of the file no problem, but uploading to Google Drive also fails. I've now zipped the file and it looks like it uploaded successfully. (edit: and even stranger it appears that the first upload actually worked after all?)

I'm partially suspecting that hyperlinks pointing to SVG files might also fail in the same way that targeted PDFs fail. The pdflib file mentions a negative value that it can't handle. It's possible that many of these SVG files, like many of the PDF files, go beyond the boundaries of the Publisher project. However they've all been cropped (using vector crop) to be within the boundaries, and anything outside was just blank space anyway. That's just my current guess as to what's triggering these bugs, for what it's worth.

Come to think of it, I think I did a test where I shrunk a PDF down (without cropping it) to easily fit within a Publisher project, but after making a hyperlink pointing to it, exporting failed anyway. It's been about 10 months so I could be remembering wrong.

pdflib.zip

[Nathan Shirley]

Well my guess seems to be correct. Hyperlinks pointing to either PDFs OR SVGs cause PDF export to fail. I replaced all my SVG links and now I can export the entire PDF successfully. Not sure why I didn't think of that earlier. I'll add the SVG issue to the bug forum.

[walt.farrell]

Have you figured out yet whether it's really all SVG files, or just the ones that extend off the page?

[Nathan Shirley]

I haven't tested it specifically, though all these SVGs were at least vector cropped to be well within page boundaries. However, I suspect that even if they were both uncropped and fully within page boundaries the problem would be the same as with PDFs. See this on PDFs:

My guess is hyperlinks don't work at all if they point to any embedded object, and probably any linked object for that matter.

[walt.farrell]

Still, it might be worth a test with by adding an SVG that is sized to be within the page, rather than cropped to be within it, and see if the export still works.

[Nathan Shirley]

Well it was almost exactly like I guessed.

Like PDFs, it doesn't matter if the SVG is sized (rather than vector cropped) to stay within the page; linking to it will still result in failure to export to PDF. Bringing in a smaller SVG, that easily fits on the page without any resizing also fails when linked to. And it doesn't matter if they are linked to or embedded. What I didn't guess right is that this seems to ONLY apply to PDFs and SVGs. I also tested a JPG and a PNG, and links to them work fine.

See attached publisher file.

hyperlink bug test.afpub

[walt.farrell]

Thanks.

17 minutes ago, Nathan Shirley said:

What I didn't guess right is that this seems to ONLY apply to PDFs and SVGs. I also tested a JPG and a PNG, and links to them work fine

It may be any linked/embedded document file, vs image file. That is, anything that's not a raster image format.

[Dan C]

Thanks for providing this updated pdf.log (though I'm not certain why you had trouble uploading this, my apologies!).

I can confirm this latest log shows the same issue that you have reported previously, which is still logged with our developers - and as you've found it appears to affect SVG files also.

I have updated the development log with this information and I will be sure to add a 'count' to this report, to try and speed up the resolution for you.

I hope this helps and my continued apologies for any inconveniences caused in the meantime!

[Nathan Shirley]

Thanks.