Update TOC can inherit last applied character formatting if TOC Entry defined with just font family

[MikeTO]

If you apply bold or italic to some text and then update the TOC, the TOC entries will be bolded or italicized if the TOC text style is defined with just the font family and no traits.

1. Open the attached test document.
2. Change the body text to bold and/or italic.
3. Update the TOC.

This is the same bug as creating a new note. If you apply bold and then create a note and the note style doesn't fully define the traits, the note will inherit the last traits you applied.

These are annoying bugs because you could apply bold or italic and then an hour later update the TOC or create a new note and be confused why it's bold or italic. You have to undo the TOC update or note creation, apply and un-apply bold or italic to something, and then update the TOC or create the note again.

TOC test.afpub

[MikeTO]

BTW other users have had this difficulty before but it hasn't been reported as a bug.

 

[DWright]

This issue has been logged with our developers

[MikeTO]

This TOC update issue is driving me a bit nuts but I finally came up with a somewhat convenient workaround. To recap, if I apply a character style to text and then hours or days later, even after restarting Publisher, update the TOC, that character style is applied to the TOC. I find this crazy.

The same is true if I create a new note or draw a new frame that it inherits the character style last character style I used days ago. When I first got Affinity I didn't understand why the Revert Defaults command warranted such a prime position in the toolbar but it's because we need to have this feature on speed dial.

Reverting defaults is not something I can do to my existing text because none of it has default formatting, it all uses text styles. So my new workaround is to draw a blank text frame in the margin of each master. When I need to update the TOC, insert a note, or draw a text frame, I click in that frame and click Revert Defaults before doing whatever it is I want to do. Tip: make the frame narrow and the height of the page so you can get to it no matter where you are

This workaround shows that the session default approach gets in the way of working.

[MikeTO]

This thread should probably be tagged with af-1233

[Mark Daniel]

This will only happen if your base TOC Entry style doesn't assert a value for the relevant text property. By default it inherits from 'Base' which defines everything so you shouldn't get this unless you've changed the inheritance or deliberately knocked things out. Make sure your TOC Entry style defines everything or in based on a style that does.

[MikeTO]

48 minutes ago, Mark Daniel said:

This will only happen if your base TOC Entry style doesn't assert a value for the relevant text property. By default it inherits from 'Base' which defines everything so you shouldn't get this unless you've changed the inheritance or deliberately knocked things out. Make sure your TOC Entry style defines everything or in based on a style that does.

And if you can't define it in TOC Entry you need to define it in each TOC Heading style.

In one of my documents, I have TOC Entry defined as family=Myriad Pro, style=Regular, Italic=NC (because the control is disabled). If I used Italic elsewhere, then updating the TOC could cause TOC Heading 3 based on Entry to change to Italic.

But I can define Italic=off in TOC Heading 3 which solves the problem. It took me a year to realize this, a lot of painful TOC updating in the meantime. 🙂 

[Gianni Becattini]

That seems to be a good suggestion in my case. When it became "odd", I defined completely the style in the parameters that appears to be wrong, as you suggest, and the problem seems to fixed.

Thanks