Description: A paragraph has a negative first line indentation AND borders with a space with the content. In the first line, the second part of the paragraph is misaligned with the following lines. Please, see the attached file. Steps to Reproduce: 1. Create a first paragraph with this format Before text = 3.0 cm First line = -3.0 cm Tabulation = Right 8.6 cm + Fill character without borders 2. Fill with one word, tab, some text, linebreak and so on The second part of first line is aligned whith the rest of lines. 3. Add borders & spacing with content=0.20 cm 4. Now the second part of first line is misaligned. OpenOffice 4.1.5 gives the same result. Actual Results: After add borders the second part of first line is misaligned with the others. Expected Results: The second part of first line should be aligned with the others. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 152052 [details] File with 2 paragraphs without and with borders
I confirm the behaviour with Version: 6.4.0.0.alpha0+ (x64) Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35 Locale: en-US (de_DE); UI-Language: en-US Calc: threaded I think padding doesn't work as expected by the users. cc: Desing Team for more input
The problem here arises from the fact that the "space before text" is relative to the "space to content" and the first line indent is relative to the "space before text," while the tab positioning is set relative to the whole text area, ignoring thus both "spaces." So the first question is, should tab stops positioning also be relative to the "space to content"? I'm not really sure about that, but my first reaction is to say no. The second question is, should "space before text" be defined relative to the text area instead of taking into account the "space to content"? Not sure about that either. IMO, Writer is doing what was asked to do. Right now, when designing a paragraph you need to take into account every aspect, and that means redefining tab stops when adding a border or redefining the "space before text" to take into account the "space to content" and thus match the tab stop. Another way is to define two tab stops and set the space to content as zero: the first tab stop simulate the space to content for the first line while the second goes to the real left paragraph border.
Regina, any input from the format definition?
Thank you very much RGB, but I consider that your proposal is called a "circumvention" or "bypass" (I don’t know the exact english term for "contournement") that I’ve obviously already implemented. I think we should consider these elements as boxes (cf or see HTML). The box defined by the borders contains a "paragraph" box which isolates them and makes them independent.
already the same in OOo. I support Chrisbath in his expectation. Didn't look in technical/ODF standard details however.
I see these problems: I'm not sure whether LibreOffices way to treat the first-line indent corresponds to XSL and CSS. From the specification text, I expect that a first-line indent does not alter margin and padding and so the border would not move, if the first-line gets a negative indent. That should be tested with an HTML document. LibreOffice uses an automatic tab-stop position in the first line. But its position is nowhere defined and not written to the file. From my experiments I guess, that it is as the right edge of the paragraph margin area. "paragraph margin area" is the area from the left of the page text area towards right with the length given in the "Indent Before text" field in the UI. A better position would be at the right edge of the padding area. That is where the text of the second and following lines start. ODF does not define the origin for measuring tab-stop positions in paragraphs. There exist an additional attribute "text:relative-tab-stop-position" (ODF1.2 19.855) for indexes but not for simple paragraphs.
Following Cor's comment 6, the user expectation is to have margins added consistently to the indentation. Removing needsUX.
*** Bug 54669 has been marked as a duplicate of this bug. ***
*** Bug 105692 has been marked as a duplicate of this bug. ***
The problem is not in the tab stop itself. The tab stop with fill character which belongs to the paragraph style is correctly set. Depending on the global setting "TabsRelativeToIndent" it is 3.0cm from the left edge of the paragraph margin or 3.0cm from the right edge of the paragraph margin. In the example document it is "TabsRelataiveToIndent = true", so the tab-stop is at position 3cm (from paragraph margin) + 5.6cm (the tabstop itself), which results in the 8.6cm you see in the dialog. When you insert a vertical line you see, that the tabstop position is the same for Paragraph 1 and Paragraph 2. The problem is the automatic pseudo-tabstop, which LibreOffice introduces in case of negative first line indent. That tabstop should be at the same position as the left edge of the paragraph content area, that is the position where the text of the second and followings lines start.
*** Bug 154133 has been marked as a duplicate of this bug. ***