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 594193 - incomplete markup for horizontal fill alignment
incomplete markup for horizontal fill alignment
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: GUI
git master
Other Linux
: Normal minor
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2009-09-05 02:49 UTC by Andreas J. Guelzow
Modified: 2010-07-01 17:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andreas J. Guelzow 2009-09-05 02:49:03 UTC
new gnumeric
enter into A1: a alt-enter b
In the cell we can correctly see that a and b are on separate lines inside cell A1.
Now format the cell for horizontal alignment: fill
The cell now shows a single line with a unknown-glyph marker between a and b.

This is the bug reported to debian at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523081
Comment 1 Jean Bréfort 2009-09-05 05:34:47 UTC
This also affect printing.
Comment 2 Jean Bréfort 2009-09-05 05:52:12 UTC
The issue comes from cell_calc_layout. The code in case HALIGN_FILL is quite weird, and does not take lines into account.
Repeating the string looks weird for me, although it seems that other sreadsheets (at least oocalc) do the same thing.
Comment 3 Andreas J. Guelzow 2009-09-07 05:30:03 UTC
I don't think we can expect to have multilines for this strange "fill" alignment, but on the other hand the newline marker should probably just become a space rather than be shown as an unknown-glyph marker.
Comment 4 Andreas J. Guelzow 2010-06-30 17:28:10 UTC
There are more issues here. The repeated copies are missing the markup, eg:
enter xyx in a cell and set y bold. Then change the horizontal alignment to 'fill'. While we now see several copies of xyx only the first x is bold.
Comment 5 Andreas J. Guelzow 2010-06-30 17:49:32 UTC
The issue with visible 'newlines' seems to be intentional:

	case HALIGN_FILL:
		/*
		 * A bit weird, but seems to match XL.  The effect is to
		 * render newlines as visible characters.
		 */

but I still think that showing unknown character glyphs is bad.
Comment 6 Andreas J. Guelzow 2010-06-30 18:42:48 UTC
There is some unusual interaction between "wrap text" and HALIGN_FILL:

(bug 1) If both are set, we use a single row (showing the newline character as unknown glyph) but do not fill. This is clearly a bug.

-- If HALIGN_FILL is not set, everything seems fine

(bug 2) If HALIGN_FILL is set and wrap text is not then we we use a single row (showing the newline character as unknown glyph) and fill. This is a bug in that we should not show the newline character.

(bug 3) is the missing markup described in comment #4.
Comment 7 Andreas J. Guelzow 2010-06-30 20:52:43 UTC
(bug 2) as identified in comment #6 is fixed.
Comment 8 Andreas J. Guelzow 2010-06-30 21:45:33 UTC
(bug 1) as identified in comment #6 is fixed.
Comment 9 Andreas J. Guelzow 2010-07-01 04:55:09 UTC
(bug 3) as identified in comment #6 is fixed.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 10 Morten Welinder 2010-07-01 13:23:56 UTC
I still see the unknown glyph in the edit-line.
Comment 11 Andreas J. Guelzow 2010-07-01 17:31:31 UTC
The bug was about "The cell now shows a single line with a unknown-glyph marker between a and b." The edit-line always shows the newline character as an unknown glyph, independent from any wrap or alignment options.
Comment 12 Andreas J. Guelzow 2010-07-01 17:45:21 UTC
I think the unknown glyph in the edit line is part of bug #130581