GNOME Bugzilla – Bug 167544
Rotated text fails to refresh correctly
Last modified: 2018-05-22 13:09:59 UTC
Version details: gnumeric-1.4.2-1mdk Distribution/Version: Mandrake Cooker [1] make a new sheet [2] in two or more adjacent horizontal cells, enter a short word of text [3] select the cells, choose Format Cells / Alignment, and set to be, say, 45 degrees [5] make the text longer in each cell by adding more words You should be able to read the text of all the cells at once (this is the main use of diagonal text!) but in fact each text is clipped to its cell boundary, rendering the feature less useful than one might like. Excel and oocalc let the text cross column bounderies.
Created attachment 37516 [details] sample sheet created using the procedure described The sheet displays correctly in oocalc.
There are several issues here: 1. Row 8 isn't importing with the right height. 2. Apparently any rotation should turn off clipping. I had hoped not to have to do that.
What generated that file ?
Liam: any news of this?
Oops, sorry, I missed the question. The sample file was generated in gnumeric. The one that alerted me to the problem came from Excel. I can supply the Excel file if it will help. It also demonstrates an incompatibility in the area of conditional formatting, for which I have not yet had time to construct a test case. I have gnumeric-1.4.2-1mdk on Mandrake cooker. Liam
liam : I'm confused. If you create the sample in gnumeric Does it look different when re-loaded into gnumeric ? or does it only look different when re-loaded into XL & OO ? There are two things at work here 1) clipped text does not span as expected 2) the sample file you supplied stores a row height, but XL & OO seem to ignore it (1) will be fairly easy to solve (2) seems odd. When you first generated the file in gnumeric, what was the row height ?
I created the sample in gnumeric to reproduce the problem. I didn't do anything explicit to create a row hight. The file looks broken here if I re-open it in gnumeric. The original spreadsheet I receieved was made and saved in excel, and looked fine in that and in OO, but in gnumeric the diagonal text didn't span columns properly. I didn't send you that sheet because it was large, but I can do so privately if it will help. I'll also add a couple of screenshots to show what's going on. Liam
Created attachment 38536 [details] screen shots showing the differences Here are four screen-shots, montaged together to save space and generate less mail :-) It's saved with high jpeg compression so the text is blurry, but that doesn't matter for the purposes of this bug report. (1) the original excel spreadsheet, in open office oocalc -- looking OK (2) the same excel file in gnumeric, showing the diagonal text not working right (3) the sample file attached to this bug report, in oocalc (looks OK) (4) the sample file attached to this bug report, in gnumeric (diagonal text is clipped to columns and hence is useless/unreadable) I didn't set the row height in the attachmet -- I think gnumeric set it when I rotated the text. Liam
Thanks. Issues... A. We clip rotated text. Well know, well understood. B. Comparing 1 and 2 suggests that we don't align vertically correctly. Please check that you are using Pango 1.8.1. If you are, then please let us know exactly what format is in cell B5. C. Comparing 3 and 4 shows that the height of row 8 is wrong when imported into Gnumeric. We do not understand this. D. Comparing 1 and 2, we seem to be missing colours. Is that just conditional formats? (We haven't implemented that yet.)
Thanks for the reply. A. was the point of the bug report originally. B. Yes, I am using Pango 1.8.1. How do I tell the format exactly? Alignment in gnumeric says Left / Bottom, Wrap text, 45 degrees. Number is General. C. I didn't set the height of the row. The spreadsheet file I used was attached to this bug report. D. Yes, the colours are conditional formatting. Although the spreadhseet is hard to read without the colours, the clipping of the diagonal text was (and remains) the main problem. Liam
*** Bug 171631 has been marked as a duplicate of this bug. ***
Reopening -- I see no open questions.
B is fixed. (Rotation suppresses wrapping.)
That was wrong. Thus not fixed.
Our problem with wrapping ("B") can be seen over in bug 173095. Interestingly, OO seems to have the same problem.
Drawing is mostly fixed now. It isn't perfect, but it will generally produce a sensible result. We need a new span type to do it right.
Is there anything left in this bug??
Yes. A7 = dfjsdhjfsdfj h sdf jsdfjk sd Format A7 to 45 degrees. Resize row 7 to regular height. Press [up] six times. Notice how part of the text is now missing. There are probably similar minor display artifacts lurking around.
So its not really about clipping anymore but failure to refresh.
Nope. When row 7 is resized, we should clip at the top of the row. (But not at the right edge, even if the next cell has contents.) This is hideously complicated and probably is different for negative angles, etc.
I take it that we are trying to emulate Excel and so don't know what to do? Otherwise we should define the behaviour we expect to see. For angle 0 we only let the text overwrite empty cells. Per se I see no reason why the same isn't true for angles not equal to 0.
> I take it that we are trying to emulate Excel and so don't know what to do? That's pretty much it. The concept of rotated text in a spreadsheet is of pretty limited utility so there is no good reason to break Excel compatibility over it. One (mildly) common usage is for column headers that are wider than the cells can show. With a reasonable angle like +30 deg, they overlap each others cells -- but not text -- and thus remain readable. In contrast, an angle of 0 will guarantee textual overlap, so we really have to clip for that. No-one cares much about angles like 1 degree.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/36.