Inserting Endnotes (body) in TOC deletes text

[Oufti]

Made with Publisher v 2.1.1 on macOS Monterey (MBP 14" M1Pro):

1. Create a new document
2. Create a text frame and type some text in
3. Insert an endnote
4. Type some text in the note body
5. (In the Notes panel > Endnotes tab > Title: assign style Heading 1 for Endnotes Title — unnecessary here for)
6. In the Notes panel > Endnotes tab > Format: assign style Texte de la note for Endnotes Body
7. Insert a TOC at the beginning of the main text
8. At the bottom of the TOC panel, in the list of styles to be included in the TOC: select, and then immediately unselect, paragraphs styled with Texte de la note, so that the note body text appears/disappears in the TOC. (This step seems to be the turning point for corruption.) — Note that an irreductible/unerasable bracketed special character in blue remains when the note is not anymore in the TOC. 
9. Refresh the TOC: the first paragraph of text after the TOC disappears! 
10. Then toggle to include or not the style Texte de la note and next paragraphs will be deleted. 

+++++++++++++

I join a file with the historic saved inside. Please look at the Notes and TOC panels as indicated for each step, to see what happens. 

TOC and endnotes - content vanishes (forums)3.afpub

— Note that this (even if created afresh) file seems prone to crash sometimes Publisher when navigating the historic. There are perhaps some steps to skip… I will restart my session to test properly. (Edit: after restart, the file is usable though unstable. Possibly the result of the bug…)

+++++++++++++

I found this bug when experimenting in relation with these other bug reports: 

 

 

[MikeTO]

I've duplicated your report. Here are steps that work with a blank document and default settings.

With Show Special Characters on:

1. Draw frames for the TOC and body textx
2. Insert a note the body frame - by default the note will be formatted as Body
3. Insert the TOC
4. Add Body as a TOC style - it adds the text of the note alone with its closing Endnote bracket, and it's not a broken bracket symbol
5. Remove Body as a TOC style - the endnote bracket will remain behind and can't be deleted

 

 

[Oufti]

 

6 hours ago, MikeTO said:

I've duplicated your report. Here are steps that work with a blank document and default settings.

Thank you very much, for reformulating and illustrating this. It is very helpful and encouraging.

 

Though, the most serious consequences of this, affecting any text following the TOC, are not shown in your video.
Therefore I would add these steps to your excellent description, following "3. Insert a TOC":

3 b. Insert two or three paragraphs after the TOC

And 6. Repeat steps 4. and 5. several times. 

Doing so demonstrates that these text paragraphs will be deleted one by one, each time the TOC style used for endnotes is toggled off [or when you refresh the TOC].

— I note that the same problem happens in v. 2.1.1 and in your beta version.

[MikeTO]

You're right, that is a more serious consequence. It's because you can't type text after that bracket and it's part of the TOC so updating the TOC will deleting any text you type. A good practice is always to place the TOC and index in separate frames and to never type regular text in the same frame. That would avoid issues like this one.

I played around earlier today trying to find other ways to generate stray endnote brackets but Publisher didn't fail on those tests. I tried inserting a footnote into an endnote (it works!), an index mark into an endnote (it works!), and other weird things like that.

[Oufti]

Thank you for your explanation. 

1 hour ago, MikeTO said:

It's because you can't type text after that bracket and it's part of the TOC so updating the TOC will deleting any text you type.

In my experimentation, I didn't type anything after the bracket, but only inserted TOC in the main text frame, so there were some paragraphs after the TOC (could be a whole book…) Then, when that bracket was introduced with the endnote body text, the first next paragraph of text was joined to it and hence candidate for erasing, every time I refresh the TOC or toggle the style to include. And this, repeatedly until all text has disappeared. 

[Am I misunderstanding the auxiliary can? For me, you can means you have the possibility — be it allowed, recommended, or forbidden doesn't matter. And if I try to type text after the closing endnote bracket, I find it is possible (even if it's not advised doing it).
So, I'd say I CAN type after the TOC, or even after that bracket, but I SHOULD not. Am I right?]

 

1 hour ago, MikeTO said:

A good practice is always to place the TOC and index in separate frames and to never type regular text in the same frame. That would avoid issues like this one.

I understand but I take this as a serious flaw.

Inserting a TOC in the flow of text, between title page and preface seems quite natural… 

And refreshing the TOC should never devour the content following it!

It would be better to have some protection against such an unexpected behaviour — wether a separate text frame created when inserting a TOC, or an unbreakable barrier between TOC and rest of the text, (or at least a warning in the help pages).

 

1 hour ago, MikeTO said:

I tried inserting a footnote into an endnote (it works!), an index mark into an endnote (it works!), and other weird things like that.

😄

[MikeTO]

1 hour ago, Oufti said:

So, I'd say I CAN type after the TOC, or even after that bracket, but I SHOULD not. Am I right?]

I understand but I take this as a serious flaw.

Inserting a TOC in the flow of text, between title page and preface seems quite natural… 

And refreshing the TOC should never devour the content following it!

Yes you can type after it, mistake. I agree it's a flaw but since Publisher doesn't clearly mark the start and end of the TOC or index it's safer to place them in separate text stories. It's just too easy to make a mess of it. It's less of an issue for the TOC but since there can be only one index, some users have complained that Publisher tells them they can have only one index but they can't find it. Using a single story in independent frames would avoid this.

It's possible to have a similar issue with text that you've typed disappearing in MS Word - you think you're typing after the TOC but it's actually part of the TOC so when it's updated the text you typed will disappear. In both Publisher or Word, position the insertion point (cursor) at the end of the TOC and start typing. In both apps, updating the TOC will delete the text you've typed because you actually typed it into the TOC. But in Word you'll know you did it because there is background shading while in Publisher you won't know for sure where you're typing.

 

 

 

[Oufti]

Thank you, once again.  

 

2 hours ago, MikeTO said:

[…] since Publisher doesn't clearly mark the start and end of the TOC or index

That's the start of the problem… Where are the end and the beginning of a paragraph in Affinity? Always not clear for me… 

 

2 hours ago, MikeTO said:

In both Publisher or Word, position the insertion point (cursor) at the end of the TOC and start typing. In both apps, updating the TOC will delete the text you've typed because you actually typed it into the TOC.

Yes, but in your demo, you placed twice the cursor inside the TOC paragraph (before the pilcrow). 

In my case, I never typed into the TOC. When I placed it, there was a paragraph break between TOC and following text (as you can probably do with MS Word – long time I didn't). In this situation, refreshing the TOC should have no influence on the other paragraphs. I would believe that the TOC will not extend outside of its last paragraph mark but yes, it does. And step by step, all the text goes crunched by the TOC.

1) On the left, my main text ; on the right, after inserting the TOC (still selected, as it was created). — If I delete the TOC, all can be back as it was.

 

 

2) Modify the TOC definition to include the note text (from there, there is no turning back possible). The first closing note mark appears, apparently inside its paragraph:

 

3) Refresh the TOC, a second closing note mark appears, this time before the first (empty) paragraph of text. This is the culprit:

 

4) Every time I refresh the TOC, a paragraph of text is erased, and the closing bracket goes before the next paragraph of text, ready to erase it. So, two clicks later, two paragraphs less:

 

— As a conclusion, I would distinguish what I will pragmatically do for myself (not having text following a TOC) and what I wanted to report: a potentially harmful bug.

It's easy to click inadvertently on the wrong style when defining a TOC, but from there it's too late, unclicking it will do no good. And when a day, you happen to refresh your (badly) in text embedded TOC, you will see your text disappearing without any apparent reason… 

 

[Lee D]

Thanks @Oufti & @MikeTO, I've logged with the developers to investigate further.

[Affinity Info Bot]

The issue "Endnotes title not included in TOC" (REF: AFB-8185) has been fixed by the developers in internal build "2.2.0.1971".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.

[Oufti]

3 hours ago, Serif Info Bot said:

The issue "Endnotes title not included in TOC" (REF: AFB-8185) has been fixed by the developers in internal build "2.2.0.1971".

Thank you.

I'm glad to confirm that there are no more any extraneous special characters added to the TOC when including notes body in the TOC.
Hence, everything behaves as expected: modifications made inside the TOC (i.e. before its last paragraph mark) are by force lost when the TOC is refreshed but it has no incidence anymore on text following this last TOC paragraph mark. 

@Serif Info Bot — A possible improvement to this would be to have a visual clue to distinguish between TOC and any rounding text, so that we know easily what could be changed at next TOC refresh (content generated by the TOC tool), and what will not (text outside the TOC).

This could take any form of "decoration", as it is named in Aff apps: underlining, overligning, frame, different background around the TOC,…