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 539734 - Rotated text is not correctly anchored when printing
Rotated text is not correctly anchored when printing
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Printing
git master
Other All
: Normal normal
: ---
Assigned To: Andreas J. Guelzow
Jody Goldberg
: 610328 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-06-23 11:36 UTC by Jean Bréfort
Modified: 2010-02-18 04:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (1.07 KB, patch)
2008-06-25 17:02 UTC, Jean Bréfort
none Details | Review

Description Jean Bréfort 2008-06-23 11:36:14 UTC
Try this: choose a vertical orientation for a cell, then print (tested with preview and pdf). The text is always anchored at the top left corner of the cell, whatever the angle. The result is that it is printed outide of the cell area.
Comment 1 Andreas J. Guelzow 2008-06-24 16:40:10 UTC
Where should it be anchored? 

The calculation used to determine the location of the rotated string in the cell does not make any sense to me.

For example have a look at the change in location between 0 degrees and -1 degrees.
Comment 2 Jean Bréfort 2008-06-25 17:02:56 UTC
Created attachment 113418 [details] [review]
proposed patch

This patch almost fixes the issue, but seems there is still a size issue. The printed text was slightly larger than on screen.

Btw, I don't understand what is the purpose of the PangoContext* passed to print_cell_gtk.
Comment 3 Andreas J. Guelzow 2008-06-25 18:20:45 UTC
I believe we need the PangoContext* to adjust the rendered value of the cell.

This patch does seem to make the rotation match what is seen on screen. So I guess it should be committed.

I still don't understand while the rotation by 5 degrees makes a multi-line cell look so different than a 0 degree rotation.


Comment 4 Jean Bréfort 2008-06-25 18:33:30 UTC
Seen that too, I'm suspecting that gnm_rendered_value_remeasure is full of bugs

bout the PangoContext* we don't use it. I tried to use it, creating a new PangoLayout* and copying text and attributes to it, but did not see any difference in the output.
Comment 5 Morten Welinder 2008-06-27 15:53:49 UTC
Excel has a discontinuity at 0.

1. Put "x" into D10
2. Put a border around it
3. Rotate +1 degree

--> Cell becomes very, very wide
Comment 6 Andreas J. Guelzow 2008-08-26 04:36:07 UTC
I think this patch should be committed to head.

Not ethat the size differnece is probably simply the old and well known to be annoying fact that fonts rendered a different resolutions may have slightly different size.
Comment 7 Jean Bréfort 2008-08-26 09:36:23 UTC
Replying to #5: looks as one more excel bug. Do wo need to reproduce such a stupid behavior?

to #6: the 1.8 branch is affected too.
Comment 8 Andreas J. Guelzow 2008-08-26 15:28:17 UTC
#5 was in response to my last sentence in #3. Your patch has the same discontinuity.

Regarding your comment re #6. This could be said about nearly all bugs fixed in 1.9.x. I really don't know which fixes should be backported to 1..8.x.

Comment 9 Morten Welinder 2008-08-26 20:00:56 UTC
Re #5, I do not think it is a bug.  When a cell's text is rotated, it makes
some of sense to shear the visible border to get the right angle for the
previously-vertical sides with respect to horizontal.

Don't bother backporting.  This is non-trivial and not very visible
to most users.
Comment 10 Jean Bréfort 2008-08-27 06:00:48 UTC
backporting to 1.8 is trivial, or I am missing something.
Comment 11 Andreas J. Guelzow 2008-09-02 07:51:46 UTC
Comment on attachment 113418 [details] [review]
proposed patch

This patch does not apply to HEAD anymore. THe equivalent should still be committed though!
Comment 12 Andreas J. Guelzow 2008-09-02 15:24:54 UTC
I have committed a slightly modified patch (due to my prior modifications ini the print code) to HEAD.

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 13 Andreas J. Guelzow 2010-02-18 04:56:10 UTC
*** Bug 610328 has been marked as a duplicate of this bug. ***