Bug Hunting Session
Bug 111932 - EDITING: Inconsistent interaction between indentation and tabulation
Summary: EDITING: Inconsistent interaction between indentation and tabulation
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 100383
Blocks: Paragraph-Tab-Stops Paragraph-Indent
  Show dependency treegraph
 
Reported: 2017-08-21 06:18 UTC by Y
Modified: 2019-10-21 00:28 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
WYSIWG result (45.33 KB, application/pdf)
2017-12-30 15:02 UTC, Y
Details
Use Case (24.71 KB, application/vnd.oasis.opendocument.text)
2017-12-30 15:02 UTC, Y
Details
Numbering style bind to paragraph style (21.59 KB, application/vnd.oasis.opendocument.text)
2017-12-31 15:40 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Y 2017-08-21 06:18:42 UTC
To recreate:
* Menu Format > Paragraph
* Intents & Spacing Tab, set Indent Before text to 0.90cm and First line to -0.90cm
* Tabs Tab, add a Left tab at position 0.90cm
* Click OK

Result: there is no tab at position 0.90cm

Do the same as above, but add the Left tab at position 0.89cm

Result: the tab is where it is expected

This bugs me when using paragraph numbering and trying to change the distance between the first line and the indent of all subsequent lines.  The tab character that is automatically inserted between the number and the beginning of the paragraph on the first line does not stop at the Indent Before text value, and instead pushes the text further inside.

Suggested fix: either
(a) allow users to set a tab at the same position as the Indent Before text value; or
(b) treat the Indent Before as a tab on the first line of the paragraph.

Both are acceptable.  The bad left justification of numbered paragraphs because of this quirk is not.
Comment 1 Regina Henschel 2017-08-21 08:31:09 UTC
The indent behavior is basically different for numbered vs unnumbered paragraphs. Please be more precise about your case.
Comment 2 Regina Henschel 2017-12-09 16:07:53 UTC
Please have a look at bug 100383. It is likely similar to your problem. if you agree, close this as duplicate.

There is currently a rework, so that only tab will change the level of a list item, same as in Draw and Impress.
Comment 3 Y 2017-12-11 07:03:39 UTC
Dear Regina,  Thanks for your comments.

Re comment 1:  Why is the indent behavior different for numbered paragraphs, and how is it different?  Frankly, all I want is to set TAB STOPS -- it is irrelevant whether the paragraph is numbered, bulleted, or plain.

Correct me if I am wrong: all types of paragraphs have three indents: (a) before text, (b) after text, and (c) first line; and then they can have zero or more tab stops.  All I need is that they be treated consistently when there is a TAB character -- does not matter if that TAB character is the result of numbering, or if it is part of the body text.  Either the Before text indent should be treated like a tab stop; or the user interface should allow to set a tab stop overlapping the before text mark.

Re comment 2: What makes you think that the problem in bug 100383 is similar or even related to my problem?  My problem has nothing to do with indent level, it is purely a tabulation problem.
Comment 4 Regina Henschel 2017-12-11 09:50:38 UTC
The error does only occur, if you try to set the tab stop in the dialog for direct formatting of a paragraph.

(In reply to Y from comment #3)
> Re comment 1:  Why is the indent behavior different for numbered paragraphs,
> and how is it different?
Because indent in numbered paragraphs is defined in the numbering, at least as long as you do not assign a numbering style to the paragraph style inside the style definition.

> Re comment 2: What makes you think that the problem in bug 100383 is similar
> or even related to my problem? Because of "This bugs me when using paragraph numbering".

Workarounds:
(1) First set the tab stop. Close dialog.  Then set the indents.
(2) Use a paragraph style and set the tab stops there.

Be aware, that the tab stop is relative to the indent. So a tab stop at 0,9cm and an indent of 0,9cm will show the tab stop at 1.8cm in the ruler.

If you need in the first line to jump from a number at position 0,0cm to a word beginning at 0,9cm indent, you need not insert a tab stop. The tabulator will jump to the indent.

There is no need for hand-made numbering. Why not use chapter numbering or list numbering as provided by LibreOffice?
Comment 5 Xisco Faulí 2017-12-12 10:18:37 UTC Comment hidden (obsolete)
Comment 6 Regina Henschel 2017-12-12 10:32:53 UTC
(In reply to Y from comment #0)
> To recreate:
> * Menu Format > Paragraph
> * Intents & Spacing Tab, set Indent Before text to 0.90cm and First line to
> -0.90cm
> * Tabs Tab, add a Left tab at position 0.90cm
> * Click OK
> 
> Result: there is no tab at position 0.90cm

I see the error, when following these steps.

I rank it a minor bug, because the sequence
* Tabs Tab, add a Left tab at position 0.90cm
* Intents & Spacing Tab, set Indent Before text to 0.90cm and First line to -0.90cm
will work and doing the same steps in styles work too.
Comment 7 Y 2017-12-30 15:02:15 UTC
Created attachment 138749 [details]
WYSIWG result
Comment 8 Y 2017-12-30 15:02:52 UTC
Created attachment 138750 [details]
Use Case
Comment 9 Y 2017-12-30 15:03:34 UTC
Dear Regina:

Thank you for all your help and workarounds.

> There is no need for hand-made numbering. Why not use chapter numbering
> or list numbering as provided by LibreOffice?

This bug report is about an inconsistent user interface quirk that still exists despite your valid workaround for which I am very thankful.  The above comment is about document structure, a completely different subject.  Nevertheless, I find the above comment worth going off-topic and hence I continue with an off topic reply.

How can you be so sure that there is no need for hand-made numbering?  How can you assert that list numbering as provided by LibreOffice covers ALL use cases without knowing the specific use case?  And even after I reveal to you my use case, and you show your expertise and apply successfully chapter numbering or list numbering to it, where do you find the self-assurance to make such a blanket statement that "there is no need for hand-made numbering" without knowing all possible use cases?

Attached is my use case, both as PDF (for WYSIWYG purpose, I cannot assume that you have the same fonts installed as I have) and ODT.  It is a simple requisition letter that a lawyer representing the buyer of real estate here in Ontario sends to the lawyer representing the seller.  I have seen much more complex requisition letters with over 40 paragraphs, but for the purpose of document structure there is enough variation/complexity in the attached use case.  Tens of thousands such letters are sent each year in the Province of Ontario alone.

You can see:
* simple paragraphs (e.g. 17, 18) for which the numbering provided by LibreOffice would be sufficient if there were no other types of paragraphs
* the majority of paragraphs require an indentation after the REQUIRED word (e.g. 12,13,14).  
* there are two special variations on the second type of paragraphs: paragraph 1, that has a very specific layout; and paragraphs with a second level of numbering (lettering in this case) like paragraph 4 and 9.
* If the paragraphs with the extra indentation after the REQUIRED word were grouped separately I could use two different lists and style them accordingly.  However, that is not the case and not practical.  The above type of paragraphs mix and match, with some of the sequence being predictable but not fixed.

Would you help me improve the attached use case?  It does use numbering as provided by LibreOffice, but it is so cumbersome to add/remove/edit paragraphs that I am thinking to revert to a fully manual one.

I must spoil the end-result though: after this letter is sent, the seller's lawyer responds to each paragraph referencing the numbering from the original letter, i.e. if I want to respond to paragraph 17, I will number the response paragraph in my reply letter 17.  Some paragraphs are not answered / not referenced, so the numbering in the response letter is no longer regular.  I am not aware of a way to skip numbers in a numbered list.  Even if there was such technology, I would not use it: one press of the ENTER key too many and all references are mangled.  You may want to revisit your statement about manual numbering.

Technology is the solution to technical problems.  Some problems are not technical in nature and in that case technology should make manual work easier, not more difficult.  This is why I reported the user interface bug which is a tripwire for the user trying to draft a letter quickly and efficiently.  You may rank it as minor, but to it is not.
Comment 10 Y 2017-12-30 15:05:47 UTC Comment hidden (obsolete)
Comment 11 Regina Henschel 2017-12-31 15:20:01 UTC Comment hidden (obsolete)
Comment 12 Regina Henschel 2017-12-31 15:40:49 UTC
Created attachment 138768 [details]
Numbering style bind to paragraph style

Your numbering is indeed special, because you want paragraph styles with different indents for your list items. Such is only possible, if you bind the list style into the paragraph style in the paragraph properties tab Outline&Numbering. With this binding the indents are not set by the list style but by the paragraph style. You can use the same numbering in different paragraph styles.
You find this approach in the attached file.

If you answer to such letters and mention the number of a list item, then this does not establish a list. In this case writing the reference to a list item manually is correct.

One problem in your file is, that you do not use the position settings of the list style at all, but try to avoid it by setting tab stops. But the discussion about that belongs into a mailing list or forum and not into the bug tracker.

I have confirmed the bug in comment 6, the workflow to reproduce the bug is clear. Therefore no further discussion is needed here.
Comment 13 QA Administrators 2019-10-12 02:45:48 UTC Comment hidden (obsolete)
Comment 14 Y 2019-10-21 00:28:31 UTC
Bug still present in version 6.3.2.2