Created attachment 190406 [details] Description of desired layout and behaviour Proposal after negative answer on https://ask.libreoffice.org/t/setting-the-table-of-contents-style/97369 It is sometimes necessary to make an "element" in a paragraph to stand out in margins. The common solution is to attach a text frame to the paragraph and insert the relevant "element" inside it. Unfortunately this is not possible for TOCs or Table of Figures, … because the paragraph is internally generated. The only degree of freedom is to play with tab stop position. This is usually sufficient because entries are relatively short and the "element" (page number) can be offset with a tab. However, with large entries (as can be produced with figure caption), this does not work because the entry will use the full width between indents and the page number can at most be flushed to the right indent. Changing the indent does nothing because both text and page number are constrained by the indent. In a paragraph style, tab stops can be defined at any distance. Overflow against right indent (in LTR languages) is not checked at configuration time. Therefore a tab stop can already be defined beyond the right indent. When a tab is met in text, Writer looks for the next stop beyond the current position. If all explicitly defined stops have already been passed, implicit evenly spaced stops are considered provided we are between the indents. If an explicitly define stop can be a candidate, it is used only if it lies between the indents, otherwise it is ignored and text wraps to next line first tab stop. To achieve the desired traditional layout in TOCs and "Tables of …", it is necessary to allow to tab beyond the right indent. I know this is not in ODF. IMHO, there are two ways to achieve the desired layout: - add a checkbox near the indent definitions to "Allow tabbing beyond After Text" to enable EXPLICIT (only) tab recognition (evenly-spaced tabs must still be limited to indents for compatibility with existing documents) - or define an optional extra indent beyond After Text for the purpose of inserting "stand-out" data; entering into this area is done only through tabbing to an explicit tab stop (if it exists) The second alternative offers a way to limit the extent of extra data and to wrap to next line when th "overflow indent" is reached.
Ajlittoz, please try as follows 1. Open your document, and open TOC dialog 2. Entries tab -> in structure place tabstop behind numbering -> OK 3. Edit PS "Contents 1": Before test 0,30" and first line -0,30" 4. Change paragraph alignment to justified (makes problem more obvious) -> OK Result: Looks much better. What remains is that you can't place page number right of heading text. This is at least annoying for every heading of 2 lines or more. Couldn' find a dublicate. So for me valid enhancement request cc: Design-Team
Created attachment 190726 [details] Screenshot MSO Reading the document in MSO produces some different layout but any modification to the tab moved it back to the right position of the dialog. The lower ToC is done with MSO, using 2cm indent left/right plus 2cm hanging for the first line. The tab stop is 0.78 (left) and 16.98 (right) - and I can change these values. So I think MSO ignores the PS indentation for tab stops and uses the page margin in case of right. One question is if this makes sense, the other if we can/should change it given this affects many existing documents.
Mike, Miklos: what do you think?
(In reply to Dieter from comment #1) > Ajlittoz, please try as follows > > 1. Open your document, and open TOC dialog > 2. Entries tab -> in structure place tabstop behind numbering -> OK > 3. Edit PS "Contents 1": Before test 0,30" and first line -0,30" > 4. Change paragraph alignment to justified (makes problem more obvious) -> OK > This improves the left side ("Before text" indent) but not the right side. The question is about the right side: to have the "After text" indent behave as usual but to have an exception to be able to tab beyond the right indent. The second TOC example by Heiko Tietze is what I want to achieve. But, as I said, I prefer a general feature which can be applied to any paragraph, not hust TOC. So, this requires: - the ability to define stops beyond right indent (this is already allowed and any stop beyond right indent will be ignored in normal text flow) - a mechanism to tell the layout engine that some tab requires to escape the standard mechanism Just like Enter can be qualified by Shift (line break) or Control (page break) to signal something different from paragraph break is desired. Perhaps Alt for Tab because Shift and Control are already used. This is for the UI aspect. Such a qualified Tab would mean "jump unconditionally to next stop", ignoring indent limit. To avoid problems, it is probably wise to limit implicit evenly spaced tabs to the paragraph indented area. Then if no stop exists beyond current cursor position, we revert to standard behaviour and text jumps to first stop on next line. I have no idea how to "advertise" the special property of Tab in ODF.
We have a compatibility option called TabOverMargin for that. So it is already implemented, exactly doing what MS Word does. But a UI is missing for it (bug 76005).
(In reply to Mike Kaganski from comment #5) > We have a compatibility option called TabOverMargin for that. So it is > already implemented, exactly doing what MS Word does. But a UI is missing > for it (bug 76005). To avoid breaking existing documents, we need to have a more sophisticated mechanism. Just TabOverMargin seems to me a bit simplistic because it accepts systematically tabs beyond margin (right indent really?). This is why I propose to "tag" Tab with a modifier. Without the special modifier, Tab behaves as presently, jumping to the first available stop within indents. With the special tab, user explicitly requests that a stop beyond right indent is accepted if it exists and is relevant for the present position. I think it is preferable to a systematic global go/no go (as set by compatibility parameters) and user remains in command.
(In reply to ajlittoz from comment #6) > This is why I propose to "tag" Tab with a modifier. Mike, can we mix LibreOffice-style tabs with MSO-tabs in one document?
(In reply to Heiko Tietze from comment #7) No, currently this is impossible. Still I don't see why the compatibility option is not enough. It is not applied automagically; a user would decide to apply it in an edited document. This decision would allow one to check if the formatting of the document wasn't broken. The document is still in the process of creation, so I see no breakage of existing documents. Technically the per-tab "tag" is possible, only needs ODF extension.
(In reply to Mike Kaganski from comment #8) > Technically the per-tab "tag" is possible, only needs ODF extension. So let's keep the ticket open for this enhancement - and make access to the compatibility option easier meanwhile.