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
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.
After add borders the second part of first line is misaligned with the others.
The second part of first line should be aligned with the others.
User Profile Reset: No
Created attachment 152052 [details]
File with 2 paragraphs without and with borders
I confirm the behaviour with
Version: 22.214.171.124.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
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.