Jump to content

Recommended Posts

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).

Annotation 2019-09-05 140652.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.)


-- Walt

Windows 10 Home, version 1903 (18362.356), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.3.481 and 1.8.0.486 Beta   / Affinity Designer 1.7.3.481 and 1.8.0.486 Beta  / Affinity Publisher 1.7.3.481 and 1.7.3.475 Beta

Share this post


Link to post
Share on other sites
22 minutes ago, walt.farrell said:

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.

Yes, true. But as you mentioned, hierarchy in TOC can get quite complex and it is often difficult to have it fully automatically generated. Typically something needs to be changed over and over again manually. Affinity makes generation a bit easier than e.g. InDesign as it auto-creates corresponding TOC styles for all heading styles, and also makes it easier to specify styles to be included as TOC entries, as inclusion does not need to be part of the style definition itself. That makes style-based exception handling a bit more realistic approach -- often one just keeps on doing same changes manually after updating the TOC.

It would be useful to have a feature that keeps formatting and actual text content of TOC static but just keeps on updating the page numbering. Or perhaps this is already possible but I'm just not aware of it!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.


-- Walt

Windows 10 Home, version 1903 (18362.356), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.3.481 and 1.8.0.486 Beta   / Affinity Designer 1.7.3.481 and 1.8.0.486 Beta  / Affinity Publisher 1.7.3.481 and 1.7.3.475 Beta

Share this post


Link to post
Share on other sites
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 :(

 

Share this post


Link to post
Share on other sites
29 minutes ago, JimWelch said:

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).

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 to the document object model. 

Share this post


Link to post
Share on other sites
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?

 

 

Share this post


Link to post
Share on other sites
26 minutes ago, JimWelch said:

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.

I see. Hyperlinks, index marks, etc. can be quite a nuisance and can be difficult to get cleared of a document even if the referring text has been removed. I have  experienced something like this with InDesign (especially with documents that are based on earlier documents) even if the referring text is deleted and the orphaned enumerations have been removed from the UI lists and the document is "saved as" afterwards.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

"Save As" should basically restructure the document so that it gets purified of any superfluous and historical data so that every bit of the information included is meaningful. But that's probably a bit of a theoretical and optimistic view of the operation ;-) (the worst scenario being that the application just copies the document contents using a new file name).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Wow! And a bit worrying, as this seems to go down deep in the document object model. Can this be reproduced even up to the point of leaving just the headings (etc.) that are involved in TOC generation and deleting anything else, and producing a new .apub document? If so, please attach one here, I'd be interested to have a look on this!

BTW; I am basically learning myself to use Affinity apps by reading bug descriptions and trying to reproduce and resolve the presented problems (especially when source documents are attached), which is a kind of a luxury way to get acquainted with new software and evaluating its potential of becoming a professional tool. E.g., I have no clue on the way hyperlinks are handled in Publisher, but I'm going to learn this now because they seem to be a cause of these kinds of production problems. Just saying this because by views are likely to be a bit theoretical at times. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
1 hour ago, JimWelch said:

All of the headings had the exact same style and properties.

Did you have any hyperlinks attached to the headings themselves, or were they just text? Were any anchors or index marks on the same line with the headings?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
On 9/7/2019 at 9:47 PM, JimWelch said:

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.

Quite odd. As mentioned I managed to create an isolated (non-reproducible) bug resulting in TOC page becoming rasterized on PDF export, by creating a URL hyperlink in one the "Heading 1" styled headings, and additionally the URL itself was not rendered as a hyperlink in the PDF. But I have not managed to produce an error where TOC page links do not work (I have been testing this with a document with 4 TOC levels producing a two-page TOC).

You mentioned about pdflib.log -- I tried to look for it but could not find. Where is it created, or do I need to turn on logging somewhere?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.