search

DistributedProofreaders / guiguts-py

Guiguts rewrite using Python/tkinter
GNU General Public License v2.0
2 stars 7 forks source link

Support per-chapter numbering for footnotes #526

Open windymilla opened 1 week ago

windymilla commented 1 week ago

At the moment (based on #503) the user has to re-index footnotes, which stops them restarting the footnote numbering for each chapter.

GG1 copes with this by not insisting on renumbering - if this approach is taken, then the numbers should still be checked (as much as is possible). An alternative approach might be to permit re-indexing on a per-chapter basis.

G4OEU commented 1 week ago

GG1's 'coping' by not reindexing means that when FNs are moved to LZs the resulting lists of FNs are unuseable. You will get many FNs with the same label such as 'A' or 'B', etc. Thus for a given anchor '[A'] (say) in the text, you will be unable to determine which of the many FNs labeled 'A' in the LZ it refers to.

One possible approach is to make reindexing an implicit part of moving FNs to LZs or to paragraphs. Futhermore that implicit reindexing would honour mutiple label types as GG1 reindexing currently does. By that I mean if you have mixed numeric and alphabetic labels in a text then the reindexing will autoincrement by label type. Thus 1->2->3->... and A->B->C->...->Z->AA->AB->...

The LZ chosen would determine the relabelling sequences used in the reindexing:

  1. End LZ - all anchors and footnotes are renumbered sequentially from 1/A/I.
  2. Chapter LZ - anchors and footnotes are renumbered sequentially from 1/A/I. for each chapter.
  3. End of paragraphs - could use either approach 1. or 2.

Finally, GG2 would do as GG1 does and offer the option of reindexing labels to the same type. Thus if there are mixed label types in the text, they would all be changed to the specified type (numeric, alphabetic or Roman).

srjfoo commented 1 week ago

My assumption was that, for chapter LZs where the footnote numbering starts over at the beginning, was that while the visible anchors would match what's in the book, the actual IDs for the anchors would have a prefix added to make them unique within the file. Is this viable?

windymilla commented 1 week ago

GG1's 'coping' by not reindexing means that when FNs are moved to LZs the resulting lists of FNs are unuseable. You will get many FNs with the same label such as 'A' or 'B', etc. Thus for a given anchor '[A'] (say) in the text, you will be unable to determine which of the many FNs labeled 'A' in the LZ it refers to.

In the case where the book numbers the footnotes 1, 2, 3, etc in chapter 1, then begins again 1, 2, 3, etc in chapter 2, and so on, then if the book is printed correctly, OCRed correctly, and proofed/formatted correctly, I don't think there is a problem with the GG1 approach for chapter LZ. I agree it would not be appropriate if the footnotes were labelled with symbols, or were labelled 1, 2, 3, etc on each page.

That said, it sounds like @G4OEU's suggested approach would leave the above case unchanged, and would fix the other troublesome cases.

windymilla commented 1 week ago

My assumption was that, for chapter LZs where the footnote numbering starts over at the beginning, was that while the visible anchors would match what's in the book, the actual IDs for the anchors would have a prefix added to make them unique within the file. Is this viable?

Are you talking about the HTML? If so, then the IDs would have to be unique, and I'm guessing that is the purpose of the "long" footnote ids, which have two numbers in them. If you are talking about the text version, then I don't think there is any feature to do what you are suggesting, and not really any need for one, since what you are aiming to do is match the book.

srjfoo commented 1 week ago

My assumption was that, for chapter LZs where the footnote numbering starts over at the beginning, was that while the visible anchors would match what's in the book, the actual IDs for the anchors would have a prefix added to make them unique within the file. Is this viable?

Are you talking about the HTML? If so, then the IDs would have to be unique, and I'm guessing that is the purpose of the "long" footnote ids, which have two numbers in them. If you are talking about the text version, then I don't think there is any feature to do what you are suggesting, and not really any need for one, since what you are aiming to do is match the book.

Definitely talking about the HTML -- apologies for not being more specific.