After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 355789 - Pango misaligns word-wrapped text due to trailing whitespace
Pango misaligns word-wrapped text due to trailing whitespace
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: general
1.12.x
Other All
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
: 434212 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-09-13 14:33 UTC by rhamph
Modified: 2007-05-02 06:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Test program (4.32 KB, text/x-python)
2006-09-13 14:34 UTC, rhamph
  Details
[pango-view] Add option for testing text alignment (2.55 KB, patch)
2007-05-01 20:14 UTC, Mathias Hasselmann (IRC: tbf)
committed Details | Review

Description rhamph 2006-09-13 14:33:37 UTC
Please describe the problem:
I wrote a test program that goes through each combination of logical/ink,
line/cluster/run/char, and left/center/right alignment.  When pango splits a line due to word-wrapping, it leaves the whitespace on the preceding line, which is then included as part of that line when it attempts to center-align or right-align the text.  The result is that the text is not visually aligned.

It is visually correct when left-align is used, but I believe the extents are wrong there too.

Although the text is wrong on all modes of my test program, the following modes show it clearly via the extent boxes:
1: left line logical.
3: left cluster logical.  Partially obscured by bug #355782
5: left run logical.
6: left run ink.  These extra runs may actually have some uses, so long as they didn't interfere with alignment.
9: center line logical.
11: center cluster logical.  Partially obscured by bug #355782
13: center run logical.
14: center run ink.  Again, the extra runs may have uses.
17: right line logical.
19: right cluster logical.
21: right run logical.
22: right run ink.  The extra runs here are are drawn over the red boundary box.

I will attach the test program (which uses pygtk).  Note that it demonstrates
two other bugs (mixaligned extents, char crashes).  I will file reports for
them separately.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 rhamph 2006-09-13 14:34:11 UTC
Created attachment 72702 [details]
Test program
Comment 2 rhamph 2006-09-13 15:54:19 UTC
Forgot to mention, when you run the test program, hit space to see the next combination.
Comment 3 Behdad Esfahbod 2006-09-13 20:32:02 UTC
bug 355782 has some discussion about this.
Comment 4 Behdad Esfahbod 2006-10-04 15:27:49 UTC
For center-aligned text, trailing empty glyphs should be ignored in alignment calculations, but be there otherwise (cursor movement etc).  For right-aligned text, we should break line /before/ space characters.  IOW, move the spaces to the beginning of the next line.  This needs help from break.c, and the diverging from the Unicode line-breaking algorithm, and is harder to implement correctly.

Or maybe we should not change break.c and fix-up in PangoLayout?  The alignment is a property of PangoLayout afterall.
Comment 5 rhamph 2006-10-05 08:12:34 UTC
Consider the text "Lorem ipsum.  Dolor sit amet."

Right-aligned to 15 columns, with whitespace removed
123456789012345
   Lorem ipsum.  
Dolor sit amet.

whitespace not removed, intermediate state
123456789012345
   Lorem ipsum.  
  Dolor sit amet.  # Too wide!

Whitespace not removed, what actually happens
123456789012345
   Lorem ipsum.  
      Dolor sit
          amet.  # Ugly, visually would have fit

Openoffice (correctly IMO) choses the first option.  Whitespace is irrelevent to fitting text on a line unless it immediately follows a linefeed.

There is a further problem how how extensively the whitespace is hidden.  In Openoffice, you can hit right-arrow to go through it one space at a time, but your cursor won't move, and "View/Nonprinting Characters" option won't show it.

I think it would be better if they retained full width, and were all shown when the suitable option is enabled, but were positioned past the right or left margins.  I don't know if this will break existing software though.
Comment 6 Behdad Esfahbod 2007-05-01 02:04:08 UTC
*** Bug 434212 has been marked as a duplicate of this bug. ***
Comment 7 Mathias Hasselmann (IRC: tbf) 2007-05-01 20:14:41 UTC
Created attachment 87357 [details] [review]
[pango-view] Add option for testing text alignment

Alignment renamed to align.
Comment 8 Behdad Esfahbod 2007-05-01 23:04:36 UTC
Committed --align after some tweaks.

2007-04-28  Mathias Hasselmann  <mathias.hasselmann@gmx.de>

        * pango-view/viewer-render.c (make_layout), (parse_alignment),
        (parse_options): Add option for testing text alignment.

Comment 9 Behdad Esfahbod 2007-05-02 04:20:05 UTC
I've been thinking about this and I think the right thing to do is to make one whitespace char before a non-mandatory line-break zero-width.  Still trying to figure out the least-changes approach to implementing that.
Comment 10 Behdad Esfahbod 2007-05-02 06:48:12 UTC
Ok, didn't go that bad, though the approach is a bit hacky, and it implements the third option of comment #5, not first.  That is, the final whitespace is not ignored when breaking lines.  So, eg if "test test" fits the line but not "test test ", it will break the line in between and removes the whitespace only after breaking.  Not very good, but much easier to implement.

2007-05-02  Behdad Esfahbod  <behdad@gnome.org>

        Bug 355789 – Pango misaligns word-wrapped text due to trailing
        whitespace

        * pango/pango-layout.c (zero_line_final_space),
        (pango_layout_line_postprocess): Make logical-final whitespace
        on wrapped lines zero-width.

Comment 11 Behdad Esfahbod 2007-05-02 06:48:34 UTC
Can close now :).