Wrong TOC hyperlinks when exporting to PDF

[JimWelch]

I have a fairly large table of contents (2 column, 1 page) with maybe ~100 entries (20 chapters, the rest level 2) in a PDF that has 164 pages.

About 95% of the hyperlinks in the TOC in the generated PDF go to the correct page. However, there's a handful that go to the next page (TOC page + 1) instead of page 86 or 87 or whatever it says in the TOC. This works for almost everything and requires me to click on each specific link to make sure it's valid or not.

This is another deal breaker (besides the ability to generate PDF bookmarks from TOC or header styles or whatever) for digital publishers - when the TOC hyperlinks doesn't work! And there's no bookmarks! So users reading large documents will get a subpar PDF experience!

Also, what's also annoying is that I need to insert a column break to prevent orphan chapter/section (the last entry on col 1 is a chapter title with it's subsections at top of col 2, so I insert a col break to make it look correct), then I get the pop-up saying "TOC has changed" on every.single.export. Even though nothing has change. I just added a col break inside of the TOC.

 

Edit: Added image from Acrobat Pro that shows the hyperlink properties. This hyperlink property is for the chapter "Sembia" and page "88" link below it, but it says Page 4 (TOC is on Page 3).

[lacerto]

(...)

[walt.farrell]

5 hours ago, Lagarto said:

Can you avoid notifications on need to update the TOC if you add the column break as a paragraph attribute (rather than adding the paragraph break manually) -- if you can, you can create a separate heading style that gets its own TOC style, which can have column break as part of its paragraph style definition so that you do not need to manually recreate the break each time you need to update the TOC.

That's an interesting idea, Lagarto. Thanks for mentioning it.

But there's another way that can work, and might be simpler when it does. There's a Flow option in the Paragraph Text Style labeled "Keep with the next <number> lines". If there's always at least one Heading 2 for every Heading 1, then changing that option to read "Keep with the next 1 lines" will ensure that you don't have a Heading 1 at the bottom of a column and its first Heading 2 at the top of the next.

(That approach does go a little strange, leaving too much space at the bottom of a column, if you happen to have a Heading 1 followed by another Heading 1, with no intervening Heading 2, at the bottom of a column. It will forcce both Heading 1 entries to the next column.)

[lacerto]

(...)

[JimWelch]

7 hours ago, Lagarto said:

In the lack of internal support for bookmarks, I have been using PDF-XChange to create bookmarks from the selected TOC text (the application has some intelligence also for creating hierarchy and formatting), or import them from an external text file, which can be useful to avoid perpetual manual creation of bookmarks when the generating application cannot achieve the desired result (even if it supports autocreation at some level).

Have you spotted the cause (any common factor) of offsets in page numbers? That is a nuisance, and I do not know any tools that could show the link content of a pdf file in one view so that it is easy to see in one view whether internal page jumps match the TOC page numbers.

Can you avoid notifications on need to update the TOC if you add the column break as a paragraph attribute (rather than adding the break manually) -- if you can, you can create a separate heading style that gets its own TOC style, which can have column break as part of its paragraph style definition so that you do not need to manually recreate the break each time you need to update the TOC.

I've been using PDFtk to script the same process. I keep my headings, indent levels, and page numbers in a text file and then use batch scripts to automate the insertion of those bookmarks into my final PDF.

I just noticed this yesterday. It's one of those "assumptions" that I thought would "just work." I know I've clicked on several to make sure the TOC worked, but I never went through and clicked on every single TOC item to make sure every single one worked. After recreating the same PDF 3 or 4 times to check the TOC (it takes > 5 minute to create), it's always the same 5 (IIRC) sections and page numbers that are invalid. However, there's nothing unique about those 5 sections. There's no page breaks before/near/around (even in the same text frame) as those headers (unlike the bug with the hyperlink anchors in PDF).

Thanks. I'll see if I can make the col break as a paragraph work in the TOC. The only problem is when I add (or remove) a new section, then that col break will need to be changed every time.

[walt.farrell]

21 minutes ago, JimWelch said:

Thanks. I'll see if I can make the col break as a paragraph work in the TOC. The only problem is when I add (or remove) a new section, then that col break will need to be changed every time.

If you always have at least one section then my Flow idea may be better for you.  Or perhaps a combination of the two approaches.

If you can share your .afpub and .pdf file here (or privately to Serif) perhaps someone can see some reason those same page links come out wrong.

[JimWelch]

3 minutes ago, walt.farrell said:

If you always have at least one section then my Flow idea may be better for you.  Or perhaps a combination of the two approaches.

If you can share your .afpub and .pdf file here (or privately to Serif) perhaps someone can see some reason those same page links come out wrong.

Yep. I'm not sure that every h1 has one h2 after it. I agree this is the best way, but I'm not sure it will work. I'll try that out later today to at least remove that pop-up.

Yep. I was waiting until QA popped in, then I can upload it to Dropbox (it's a huge file, with 350+ images, so even without images I think it exceeds file upload size for the forum). However, I still hope Affinity fixes the problem of the actual page links not working

 

[lacerto]

(...)

[JimWelch]

4 minutes ago, Lagarto said:

And no forced line breaks, either, I suppose. And even if there were, I suppose these should have an opposite effect: -1 offset instead of +1 (as surely the starting position should determine the page number, and not the ending position).

Then it could be an update (refresh) bug -- that is, could these headings have been on those pages at some point of the document's history, and the TOC has somehow just become corrupt. Have you tried if the problem can be fixed simply by de- and re-selecting the related heading styles -- or by deleting and recreating the TOC. Just to see if this is a matter of corrupted TOC, or a deeper problem related o the document object model. 

Actually, the incorrect hyperlinks always go to page 4 (page 3 is where TOC is at) - regardless of whatever number (88, 89, 115, 125, etc.) is printed next to the TOC header. None of those were ever on page 4.

I'll try deleting and recreating the TOC and deleting and recreating the headers as well. I've changed and checked the text styles on the problem headers and that didn't seem to change anything.

It prints the correct page number! So why doesn't the TOC use the same page number that it prints for the hyperlinks?

 

 

[lacerto]

(...)

[JimWelch]

I tried deleting the TOC, deleting the section header that causes problems, then recreating the TOC (without the bad hyperlink section), adding back in the section, then updating the TOC, and it's still not working correctly. 

I'm not sure how or why the TOC displays the correct page number "header....##" but the hyperlink goes to a different page? That seems strange to me. It feels like if one piece of code was broken, then the other piece should also be broken.

[lacerto]

(...)

[JimWelch]

6 minutes ago, Lagarto said:

Yes, really odd.

Is the produced PDF technically sound, though, so that you can e.g. edit the page destinations in Adobe Acrobat or other software that allows you to edit links, and correct them so that they point to correct pages?

There should be a way to "purify" the document so that it is cleared from any historical burden and only contains the most recent data and pointers to it. Have you tried if "Save as" has any effect on the matter?

Yes. I manually edited the problem links in Acrobat Pro (see screenshot in opening post for Acrobat pro hyperlink editor screenshot).

I haven't tried a "Save As". What would that change? I'll try that later tonight.

[lacerto]

(...)

[JimWelch]

Save As didn't help. I did a Save As, exported still problem. I deleted the TOC completely, did another Save As, added a new TOC, exported, still same problem.

 

The file size did get smaller (slightly) after the Save As, so that did clear something out.

 

I've even deleted the entire text frame concerning one of the items and then recreated it. And it still has a problem.

[JimWelch]

Update - There's actually more bad hyperlinks in TOC now after I did the Save As, delete TOC, recreate TOC, etc.

[JimWelch]

Okay. I'm looking at the PDFlib log file and I can see the problem. It's pretty clear and now that I'm looking here, I realize that not only are the page numbers wrong but the entire line is wrong. Sometimes the Section Name links to page 4 (wrong page) and the number is correct, other times the Section name is correct and the page number link is wrong, and sometimes both are wrong.

Here's the pdflib.log output:

[0]
PDF_setfont(p_0x000002AF80CBBFD0, 0, 15.221038)
PDF_fit_textline(p_0x000002AF80CBBFD0, "à¥\213à¥\217à¥\223", /*c*/9, 1883.539918, -637.890519, "xadvancelist={5.601342 6.073194 6.819025 }")
PDF_restore(p_0x000002AF80CBBFD0)
PDF_restore(p_0x000002AF80CBBFD0)
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 4}")
[4]
PDF_create_annotation(p_0x000002AF80CBBFD0, 68.868000, 681.140060, 294.102000, 720.856860, "link", "action {activate 4} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 5}")
[5]
PDF_create_annotation(p_0x000002AF80CBBFD0, 288.356400, 681.140060, 294.102000, 702.020060, "link", "action {activate 5} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 4}")
[6]
PDF_create_annotation(p_0x000002AF80CBBFD0, 294.102000, 681.140060, 294.102000, 702.020060, "link", "action {activate 6} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 5}")
[7]
PDF_create_annotation(p_0x000002AF80CBBFD0, 288.892039, 667.892549, 294.102000, 682.104463, "link", "action {activate 7} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 5}")
[8]
PDF_create_annotation(p_0x000002AF80CBBFD0, 288.892039, 655.904268, 294.102000, 670.116182, "link", "action {activate 8} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 4}")
[9]
PDF_create_annotation(p_0x000002AF80CBBFD0, 68.868000, 638.326697, 287.780400, 659.206697, "link", "action {activate 9} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 7}")
[10]
PDF_create_annotation(p_0x000002AF80CBBFD0, 287.780400, 638.326697, 294.102000, 659.206697, "link", "action {activate 10} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 4}")
[11]
PDF_create_annotation(p_0x000002AF80CBBFD0, 68.868000, 619.489897, 294.102000, 659.206697, "link", "action {activate 11} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 7}")
[12]
PDF_create_annotation(p_0x000002AF80CBBFD0, 287.780400, 619.489897, 294.102000, 640.369897, "link", "action {activate 12} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 4}")
[13]
PDF_create_annotation(p_0x000002AF80CBBFD0, 294.102000, 619.489897, 294.102000, 640.369897, "link", "action {activate 13} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 7}")
[14]
PDF_create_annotation(p_0x000002AF80CBBFD0, 288.913523, 606.242387, 294.102000, 620.454301, "link", "action {activate 14} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 4}")
[15]
PDF_create_annotation(p_0x000002AF80CBBFD0, 68.868000, 588.664816, 288.140400, 609.544816, "link", "action {activate 15} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 8}")
[16]
PDF_create_annotation(p_0x000002AF80CBBFD0, 288.140400, 588.664816, 294.102000, 609.544816, "link", "action {activate 16} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 4}")
[17]
PDF_create_annotation(p_0x000002AF80CBBFD0, 294.102000, 588.664816, 294.102000, 609.544816, "link", "action {activate 17} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 8}")
[18]
PDF_create_annotation(p_0x000002AF80CBBFD0, 288.902781, 575.417305, 294.102000, 589.629219, "link", "action {activate 18} borderstyle=solid linewidth=0")
PDF_create_action(p_0x000002AF80CBBFD0, "GoTo", "destination {retain page 8}")
[19]

 

Look at how the "GoTo", "destination {retain page 4}" repeats over and over. These are the wrong hyperlinks. It's changing every other link to page 4. The first GoTo is the text, the next one is the page number. So link [0] goes to page 4 (correct), then [4] goes to page 5 (correct), then [5] goes to page 4 again (wrong), then [6] goes to page 5 (correct), then [7] goes to page 5 (correct), then [8] goes to page 4 (wrong).

Something in the code is changing almost every other H1 link to page 4. Oddly, all of the H2 links work fine. But I have some H1s without a H2 - otherwise, I could just remove page numbers on H1s. It's like a variable in their loop isn't getting incremented correctly when they are creating those PDF actions.

Also, further investigation reveals that the hyperlink is correct within the document. When I select the problem text (such as "88" in the OP post), then click Text->Interactive->Hyperlink, it says "Page 88". So the hyperlink in the afpub TOC is correct, it's only getting exported to PDF incorrectly.

 

[JimWelch]

I went through the TOC and re-hyperlinked all of the H1s by hand. Now when I export to PDF, everything is correct. However, I'm going to have to redo the TOC H1 hyperlinks every single time I add new content.

[lacerto]

(...)

[lacerto]

(...)

[lacerto]

(...)

[JimWelch]

5 hours ago, Lagarto said:

Still one question about this problem. I read your original post a bit carelessly and only now realize that the offset of the wrong page number was last TOC page +1 (rather than the referring page + 1). So when there have been errors in links (such that point to wrong page destinations) has this always been the case?

Also, as you managed to fix the error by recreating manually the hyperlinks included in the headings, which type of hyperlinks did you have in them, and did they actually work correctly, even if the TOC links pointing to the headings had errors? Did you spot anything common in hyperlinks in those headings that did not have correct TOC links?

There seems to be some bugginess in the feature, indeed. I just added a URL type of hyperlink in heading 1 styled heading and updated the existing TOC. When I created a test PDF, the whole first page of the TOC was rasterized for no obvious reason (and I tested different pdf modes, web, X-1 and print), while the second page of the TOC was in text format. Yet the page links of the TOC worked ok. In addition, the heading where the hyperlink was added did not contain a hyperlink (I ensured that hyperlinks were checked in the export settings).

I could fix this only by deleting the existing TOC and the containing frames, and recreating the TOC. This time the whole TOC was in text format and the heading also contained the hyperlink, and the TOC page links operated correctly.

The hyperlink I had created was technically flawless, so the error seemed to be completely random. I have not been able to reproduce it, either.

Yes. The bad links always went to TOC page + 1 (page 4 in my doc, page 3 is TOC).

All of the headings had the exact same style and properties. There's nothing different about the good vs bad headers (other than the bad ones linking to pg 4). I've even deleted the TOC, recreated it, so everything is the exact same, and still same problems.

I've also deleted my entire TOC, the containing frame, and then recreated the frame and TOC and still have the problem. I guess I just need to do my TOC hyperlinks by hand from now on...

[lacerto]

(...)

[JimWelch]

H1s and H2s are just text.

There's no anchors in the entire document. The only hyperlinks are on the Credits page (page 2).

The very first H1 does link to page 4, so I think there's some variable that is default to the first use of that page number.

[JimWelch]

The PDFlib.log is how we debug our PDF problems. It's the library used by Publisher when Publisher creates PDF files. You can turn it on/off by following Dan's instructions at:

 

https://forum.affinity.serif.com/index.php?/topic/92624-export-to-pdf-error/&tab=comments#comment-491521

 

If you change the file path (C:\Temp to D:\Temp or whatever), just edit the reg file using Notepad to update the path. Also, always inspect reg files to make sure it's not doing something it shouldn't do - before running them.