Bug 154133 - Writer: Erroneous handling of initial tab in hanging indent paragraphs with border
Summary: Writer: Erroneous handling of initial tab in hanging indent paragraphs with b...
Status: RESOLVED DUPLICATE of bug 125804
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.5.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-11 14:44 UTC by ajlittoz
Modified: 2023-08-07 21:32 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Wrong initial tabulation with negative first line indent and border (30.05 KB, application/vnd.oasis.opendocument.text)
2023-03-11 14:44 UTC, ajlittoz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ajlittoz 2023-03-11 14:44:35 UTC
Created attachment 185908 [details]
Wrong initial tabulation with negative first line indent and border

When configuring a paragraph style for negative first line indent, an implicit tab stop is defined at left indent. Thus you can enter e.g. a term then tab to type its definition and line up nicely with lines 2+. This works fine with large indents.

A hanging indent may also be used for comments where word COMMENT will be followed by a linebreak and the comment itself. It gives a compact form for the comment without the need for two paragraph styles.

Should a comment need more than one paragraph, you start the second paragraph with a tab and don't enter the COMMENT "title", typing the next comment paragraph instead.

This is a form of direct formatting but works fine.

Hanging indent paragraph can be emphasised with a border. Padding space is added to avoid visual clutter between text and border. This padding space adds some distance between top border and text and also between text and bottom border, good. Right indent is shifted by the padding distance too, good but there is no feedback in the horizontal ruler.

It looks like the left indent is treated differently depending on the first character. Note again that there is no visual feedback in the horizontal ruler and that the markers are not positioned where text will physically be laid out.

If first character is a printable character, everything is fine and text is offset by the padding distance. If the first character is a tab, Writer seems to compare "padding" position to unshifted left indent (consisted with ruler display) to decide whether it should stop at left indent or jump to next tab stop (in the attachment, default stops every 1.25cm).

This becomes apparent when padding is slightly smaller than left_indent: text starts at unshifted left indent and second line which is aligned at padding+left_indent does not line up with the first one.
If padding is really smaller than left_indent, text is set as expected.
If padding is larger than left_indent, text starts at first available default stop.

The issue seems to be in the computation of the target position after the tabulation. IMHO padding has been forgotten.

Tested with 7.4.5.1 under Fedora Linux 37, Plasma desktop. But erroneous behaviour has been present for ages, at least since 4.x releases.

Possibly related: bug 125336
Comment 1 ajlittoz 2023-03-12 11:25:44 UTC
After more experiments, the key factor is padding distance in Borders tab. It is not necessary to have a border byt itself, only padding is sufficient to cause the issue.
Comment 2 Dieter 2023-03-28 08:52:07 UTC
I confirm the behaviour with

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b5c3a7502f7ff6ccf0f829c1f3a2ba50b8584c41
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (de_DE); UI: en-GB
Calc: CL threaded

But I'm not sure about expected result and so I'm not sure, if it is a bug or not. If you a tab stop at 1cm it works.

Steps:
1. Open attachment 185908 [details]
2. Select second paragraph
3. Format -> parapgraph -> Broders -> change padding to 0,5 cm

Actual result
Relativo position of first line indent changes

Expected result:
???
Comment 3 ajlittoz 2023-03-28 10:45:32 UTC
(In reply to Dieter from comment #2)
> But I'm not sure about expected result and so I'm not sure, if it is a bug
> or not. If you a tab stop at 1cm it works.
> 
> Expected result:
> ???

Layout in Writer is based on a box model similar to the one for HTML. Proceeding outwards, you have:
- a rectangle for paragraph text
- padding space around it
- a border with or without shadow
- "margins" around the border named indents at left and right and spacing above and below

In my understanding of "typography", first line indent should apply on the text rectangle. The fact it is named 1st line INDENT makes me fear it is applied on the margins level.

From experiment, it looks like indents (before and after) are first taken into consideration. They are then reported in the ruler. This defines the basic text rectangle. The left and right limits are reported in the ruler. If there is a negative first line indent, this shifts the left (in LTR mode) border limit but does not change the basic text rectangle as far as lines 2+ are concerned.

After this first step, padding space is used to position text inside the paragraph rectangle. However padding space does not modify the marks in the ruler, in particular, it does not change tab stops which are used with their "absolute coordinates", not considering the effect of padding.

When you change before-text indent, tab stops are recomputed so that they keep their relative position to left indent, clearly indicating that they were intended to be relative to paragraph left indent. This is what users generally expect.

But since padding results in shifting the position where paragraph text will be set, the same shift should also be applied so that a padded paragraph keeps the same relative layout as a non-padded paragraph.

Shifting the markers in the horizontal ruler to report an existing padding might confuse seriously users (s/he defined a 0cm left indent and the mark does not appear on the 0 graduation), then the 0-origin might be offset instead by the value of the padding space. The case of the right (again in LTR) indent mark is different as you don't specify a paragraph width and the position is computed. However some means should be devised to provide padding information to avoid a "surprise" seeing the mark not aligned on text limit.

IMHO the problem boils down to not offsetting tab stops the same way as effective paragraph text limits are offset.

But as I mention above, to avoid user confusion some means must be found to indicate the existence of padding in the ruler.
Comment 4 Dieter 2023-04-10 13:30:12 UTC
Not sure, if I understand everyting. But as far as I can follow, I see two issues:

> But since padding results in shifting the position where paragraph text will
> be set, the same shift should also be applied so that a padded paragraph
> keeps the same relative layout as a non-padded paragraph.
Actually padding seems to be only assigned to "Before Text Indent" and not to "First Line Indent". That might be a first enhancement request. 

> But as I mention above, to avoid user confusion some means must be found to
> indicate the existence of padding in the ruler.
Thant might be a second enhancement request.

But I'm not too deepl in this area of Writer, so let's ask design team.
Comment 5 Heiko Tietze 2023-04-11 09:06:52 UTC
First paragraph (1):  Before Text = 0.5cm, First Line = -0.5cm, second paragraph (2): same attributes but starts with a tab indenting the first line to the same position like the first paragraph. Adding a border is expected to shrink the available space but in fact seems to ignore the first line negative indentation (3). The expectation is that it works likewise applied to the first paragraph (4,5)

1 Lorem ipsum dolor sit amet
1       consectetur adipiscing elit
2 <tab> Vestibulum consequat mi
2       quis pretium 
3          <tab> Proin luctus orci
3          ac neque venenatis

Expected:

4    Lorem ipsum dolor sit amet
4          consectetur adipiscing elit
5    <tab> Proin luctus orci
5          ac neque venenatis

Duplicate of bug 77484 and/or bug 125804 (definitely), related to bug 153407 and bug 107497.
Comment 6 Regina Henschel 2023-08-07 20:43:35 UTC
I consider this to be not an enhancement but a bug, and it is duplicate to bug 125804.
Comment 7 Stéphane Guillou (stragu) 2023-08-07 21:32:46 UTC
OK, with Heiko and Regina agreeing, I'll mark as duplicate.
Will add the related reports there.

*** This bug has been marked as a duplicate of bug 125804 ***