Table of Contents update messes up the layout in Publisher v1 and v2 + workarounds

[SpotColour]

A bug in Publisher v1 and v2 causes the table of contents (TOC) layout to go berserk when refreshed because it sponges up unrelated character/paragraph styles from the document. 

During a TOC refresh, the update function superimposes whatever character or paragraph style is used last in the document on top of the actual TOC styles. This should never happen since Publisher uses independent TOC styles to generate a TOC.

For example, if I apply a red character style somewhere in the document and then proceed to refresh the TOC, the entire table of contents will turn red.

The same goes for paragraph styles. If I apply a numbered list style somewhere in the document and then go to the TOC to reload it, every TOC entry will start with a number.

The TOC only sponges up style settings which are undefined in a TOC style (or its ancestor's TOC style) but defined in the last used document style. With undefined settings I mean unchecked settings or [No Change] settings, anything that can inherit a value.

So if I explicitly set the base TOC style to use black text, the unrelated red character style can no longer affect my TOC layout. This workaround works but is impractical for documents that use numerous styles. Since any of these could affect the TOC at some point, you'd need to overrule quite a few settings. Luckily, there's a more suitable workaround, albeit a bit silly.

Workaround:

1. Make sure nothing in the document is selected.
2. Go to the Text Styles panel.
3. Set the Paragraph and the Character style to [No Style].
4. Click somewhere in the TOC to make it active.
5. Refresh the TOC from the Table of Contents panel.
6. The TOC now exclusively uses TOC styles.

This behaviour must be a bug. I can't think of any reason why this would be a feature. It appears that forum user Loquos experienced the same issue last November, so I'm pretty sure it's not my setup at fault.

Steps to reproduce the problem:

1.  Create a new document.
2.  Place two regular text frames on the page.
3.  From the Table of Contents panel, insert a TOC in frame one.
4.  Add a few lines in frame two and apply the default Heading 1 style to each.
5.  Go to frame one and refresh the TOC.
6.  Edit the TOC style 'Base' and disable the tick mark next to the text colour setting (character fill).
7.  Type some text in frame two.
8.  Add a new character style and set its text colour to red (character fill).
9.  Apply the red style to the text you typed in step seven.
10.  Update the table of contents in frame one.
11.  The new character style colours the contents red, even though it is entirely unrelated to the TOC layout.

When I tried to reproduce the bug in a new document, I noticed that even though the Base style for the TOC is based on [No Style], it is far from empty. Almost every setting in the Base style has a default value. This explains a lot. I tend to defenestrate the default styles when I create a new document. My styles only have values for the settings I need. They don't have default values for unused style elements. This likely caused these daft TOC layouts, but that's beside the point. My approach should've worked just as well. After all, a TOC should never sponge up settings from a random document style. It doesn't make sense, but it is what's going on.

I'm using macOS 12.6.3 and the latest Affinity Publisher (2.0.4). I always use the Table of Contents panel to update the TOC. I did not try the Preflight panel's TOC update feature.

Hardware acceleration does not affect the issue. Neither does it help to unplug all external hardware. The problem exists in both Publisher v1 and v2.

It would be great if the Affinity team could look into this peculiar behaviour and hopefully fix it! Thank you!

 

[Callum]

Hi Spot Colour,

Thank you for your report I have logged this with our developers to be investigated further.

Thanks
C

[momsoft]

I can confirm the same behaviour and the proposed solution using v2.1.

Now that I have a working solution, it is less urgent to solve the problem, but it would be nice if the bug could be eliminated.

[AnnPS]

On 3/14/2023 at 1:48 AM, Callum said:

Hi Spot Colour,

Thank you for your report I have logged this with our developers to be investigated further.

Thanks
C

Hi Callum,

I have had this same problem with the INDEX, as well as the TOC. Thanks to SpotColours suggestions I have tried that workaround, and found a similar one works - but rather than selecting no style, I found I had to select the character style that matched the index style I was using.

Please add this to the bug report!

Edited October 31, 2023 by AnnPS

[SpotColour]

Yesterday, @AnnPS experienced a similar issue when generating an index. And I’ve recently noticed that this bug also affects footnotes.

Therefore, this bug is probably not specific to the Table of Contents. Instead, the bug seems to affect generated content in general. I haven’t had time to test all this, but this extra information will probably make it easier to pinpoint the cause of this problem.

[wrandyr]

I am experiencing a similar problem in Publisher 2.3.0 on Windows 10. When I update the TOC, italics are added to the entire TOC, the first line's font size is increased dramatically (which I can easily fix) and some kind of page or column break is inserted (which I can't get rid of). If I delete the return at the end of the line, the font size is reduced to almost invisible. Adding the return back restores the oversize, so I'm back to where I started. The workaround described by @SpotColour avoids the added italics, but not the crazy sizing. In the screenshots, the TOC paragraph style defaults to "TOC 1: OHAP Heading-Section, major (for ToC)", changing it to the desired "TOC 1: Entry" only adds the tab decorations. Does anybody have any ideas?

Groundsmen 6x9 231228.afpub

[MikeTO]

@wrandyr This is a known issue but it's easy to avoid. Edit the TOC 1: OHAP... paragraph styles and define all of the attributes that aren't currently defined and which are getting messed up. For example, if the TOC keeps being made italic when you update it, define the text as Regular (or something similar) instead of <No Change>. You will likely have to define the font family to do this. If the leading keeps getting messed up, define the leading in the text style.

Cheers

[wrandyr]

@MikeTO Thank you for the suggestion, which I applied to the style I want to use. It appears that TOC styles are automatically generated for every regular style that the TOC includes. I noticed that when the TOC is updated, the paragraph style always switches to the last TOC style listed, so I edited that one too. I still get the oversized text for the first 1 to 3 lines. If I put the cursor on an oversize line, and switch to any of the TOC styles (not just the ones I have edited), the oversize text is removed from that line, but the next line then becomes oversized. I suspect something else may be going on. My only clue is the oversize § end-of-story special character. I tracked that to an empty text box on a blank page immediately before the page with the first TOC anchor. I deleted the text box, but the oversize text still finds its way to the TOC.

[MikeTO]

This is kind of strange if every TOC style now has the font size defined. You might try selecting the TOC frame and choose Edit > Defaults > Revert. I doubt that will fix it but it's worth a try.

[AnnPS]

On 12/29/2023 at 3:50 AM, wrandyr said:

I am experiencing a similar problem in Publisher 2.3.0 on Windows 10. When I update the TOC, italics are added to the entire TOC, the first line's font size is increased dramatically (which I can easily fix) and some kind of page or column break is inserted (which I can't get rid of). If I delete the return at the end of the line, the font size is reduced to almost invisible. Adding the return back restores the oversize, so I'm back to where I started. The workaround described by @SpotColour avoids the added italics, but not the crazy sizing. In the screenshots, the TOC paragraph style defaults to "TOC 1: OHAP Heading-Section, major (for ToC)", changing it to the desired "TOC 1: Entry" only adds the tab decorations. Does anybody have any ideas?

Groundsmen 6x9 231228.afpub 811.25 kB · 5 downloads

wrandyr - the way I solved this was to create a small text box next to the TOC (same for Index), put in a line of text, highlight and format with my basic body text style, and in addition, while still highlighted, I would choose the character format of "no style" - do all this before clicking on the update TOC (or update index), and it worked everytime! Then just have to remember to delete the text box when all is complete

[Hangman]

Hi @wrandyr,

Did your document at some point in its life start out as an InDesign file?

I ask purely with regard to the text sizing issue you're seeing when refreshing your TOCs since it fits in with a known bug logged under AF-1288 and AF-1342 relating to opening IDML files in Publisher where Publisher fails to interpret the InDesign document dpi correctly and uses a default of 72 dpi.

When refreshing your TOCs the Adobe Garamond Pro Regular used changes from 12 pt to 100 pt and the 14.4 pt leading changes to 120 pt which fits perfectly with the known bug since your document is set at 600 dpi:

• 600 / 72 = 8.333334
• 12 pt text x 8.333334 = 100 pt
• 14.4 pt leading x 8.333334 = 120 pt

To overcome the issue the following steps should work:

1. Change your Publisher document from 600 dpi to 72 dpi
2. Save, Close and Re-open your document
3. Delete the existing four pages (effectively) used for your TOCs
4. Add four new pages after Page 5 for your TOCs
5. Add text frames as you previously had on the three respective pages and link accordingly
6. Re-insert the TOCs (Text > Table of Contents > Insert Table of Contents)
7. Edit the TOC 1: Entry Text Style ensuring you set the font size to 12 pt and the leading to 14.4 pt (or as required) - to override the scaled font and leading sizes
8. Apply the TOC 1: Entry Text Style to the newly added TOCs
9. Save, Close and Re-open your document
10. Change the Document dpi from 72 dpi back to 600 dpi
11. Save your Document

Now when you update the TOCs you should no longer see the increase in text size and leading each time.

Out of complete curiosity, is there a particular reason you're using 600 dpi for your document?

[wrandyr]

@MikeTOThank you, but your supposition was correct. Interestingly, It caused the first ⅔ of the text to be turned to Arial, and the middle ⅓ to be shrunk to 1.4pt (rather than enlarged). The last ⅓ stayed with 12pt Garamond.

@AnnPSAlso thank you, but that didn't work to suppress the font resizing.

@HangmanAn extra big thank you. You seem to have identified the problem and provided a solution. I particularly appreciate the detailed instructions.

This document was created entirely within Publisher, albeit using a template whose roots were an InDesign document. That template has been revised at least twelve times over more than two years, and used for around a dozen projects. This is the first time the bug has turned up for us.

I'm not really sure why we were using 600 dpi. We did have a rasterized line art logo that we may have been trying to preserve, but it is no longer being used.

Again, thank you. I never would have solved this on my own.

[Hangman]

49 minutes ago, wrandyr said:

This document was created entirely within Publisher, albeit using a template whose roots were an InDesign document. That template has been revised at least twelve times over more than two years, and used for around a dozen projects. This is the first time the bug has turned up for us.

An InDesign template would be sufficient for the bug to show itself in Publisher, though it is equally possible to 'recreate' the bug using Publisher alone even without InDesign roots...

No problem at all, I'm really glad you have a workable solution... I think if you're no longer using the rasterized line art logo you'll likely be fine at 300 dpi but equally if the document is going to print take the advice and guidance of the print company...