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. ***
Dear Chrisbath, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Test performed with the latest version (25.2.3.2) The bug reported on 08/06/2019 is still present. If borders are applied to the paragraph, the indentation is incorrect from the second line of the paragraph. If the left border is removed and the others are kept, the bug disappears.
Désolé, je n'ai pas pu attacher le fichier de test que j'ai préparé !