https://bugs.documentfoundation.org/show_bug.cgi?id=148597
--- Comment #10 from ajlittoz <[email protected]> --- (In reply to sdc.blanco from comment #9) > (In reply to ajlittoz from comment #8) > It seems preferable to collect all the formatting onto the Entries tab, for > example with: > > CT = Caption Text > C = Category > C# = Category Number > (plus CI = Chapter Info) For consistency with all the other table Entries tab (except Bibliography), I think it would be better to have: E = caption text (where E is mnemonics for "entry") E# = category + category number (plus CI, of course) Keeping the E ensures a "relative" compatibility with existing documents. Your proposal introduces an improvement compared to mine: you separate the "identification" of the entry into two components C and C# which can be edited separately. However, this immediately raises a problem. From my experiments, today the "components" of the caption paragraph are split at the number range field with a subtlety. If the field is immediately followed by a non-U+0020 SPACE character, this character is kept in the first component. We end up with everything from the beginning to the field or its immediately subsequent character as "Category & Number" and everything from the first non-U+0020 following the preceding run to the end. This is not good in languages such as French where AutoCorrect inserts non breaking space before a colon frequently used to separate the numbering from the caption itself. Transposing this to your (better) three components proposal, we could have: - C or EC: everything from start to number range field, removing trailing spaces - C# or E#: number range value ==> But to do with the separator? Should it be included with E# or ignored, considering we can always add literals in the Entries structure line between two descriptors? ==> Also what is the definition of a separator (+)? To avoid the problem mentioned for French, I suggest that any run of non-U+0020 characters suffixed to the field be treated as the separator, accounting for possible multi-character separators. - CT or E: everything after the field or separator, excluding leading spaces (+) Since a caption can be manually generated (which I do frequently when my items are not enclosed in a frame), you can't rely on the Insert>Caption to get the separator. And my suggested separator recognition will fail for something like space-em dash-space, in fact any separator using a space after the number. -- You are receiving this mail because: You are the assignee for the bug.
