Bug Hunting Session
Bug 125804 - PARAGRAPH BORDERS: Incorrect alignment in paragraph with first line indented
Summary: PARAGRAPH BORDERS: Incorrect alignment in paragraph with first line indented
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Paragraph-Tab-Stops Paragraph-Borders
  Show dependency treegraph
 
Reported: 2019-06-08 18:30 UTC by Chrisbath
Modified: 2019-06-27 07:46 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
File with 2 paragraphs without and with borders (11.12 KB, application/vnd.oasis.opendocument.text)
2019-06-08 18:34 UTC, Chrisbath
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chrisbath 2019-06-08 18:30:50 UTC
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:
Comment 1 Chrisbath 2019-06-08 18:34:11 UTC
Created attachment 152052 [details]
File with 2 paragraphs without and with borders
Comment 2 Dieter Praas 2019-06-09 07:35:41 UTC
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
Comment 3 RGB 2019-06-09 13:44:58 UTC
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.
Comment 4 Heiko Tietze 2019-06-12 12:40:37 UTC
Regina, any input from the format definition?
Comment 5 Chrisbath 2019-06-14 08:01:42 UTC
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.
Comment 6 Cor Nouws 2019-06-26 09:03:07 UTC
already the same in OOo.
I support Chrisbath in his expectation.
Didn't look in technical/ODF standard details however.
Comment 7 Regina Henschel 2019-06-26 13:03:57 UTC
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.
Comment 8 Heiko Tietze 2019-06-27 07:46:09 UTC
Following Cor's comment 6, the user expectation is to have margins added consistently to the indentation. Removing needsUX.