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 152265 - Line breaks differ between screen and printing
Line breaks differ between screen and printing
Status: RESOLVED DUPLICATE of bug 323315
Product: Gnumeric
Classification: Applications
Component: Printing
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on: 153549
Blocks:
 
 
Reported: 2004-09-09 18:57 UTC by Jon Kåre Hellan
Modified: 2007-11-08 22:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example spreadsheet (1.60 KB, application/x-gnumeric)
2004-09-09 18:59 UTC, Jon Kåre Hellan
Details
Result of printing, converted to png (285 bytes, image/png)
2004-09-09 19:00 UTC, Jon Kåre Hellan
Details

Description Jon Kåre Hellan 2004-09-09 18:57:45 UTC
The attached spreadsheet contains the string "qwerty" in A1, and nothing else.
The attached .png file shows what happens when printing it. We see the character
"y". On top of it, there is several characters' width of pixledirt.

What happens is that the text is wider on paper than on screen. It is wrapped
inside the cell, and all but the lowest few pixels of the first line are clipped.
It would be better to show the complete first line and clip the second if necessary.

Another issue is that when the space to the right or below is empty, it may be
better to let the text overflow into that space. Didn't printing use to work
that way?
Comment 1 Jon Kåre Hellan 2004-09-09 18:59:37 UTC
Created attachment 31451 [details]
Example spreadsheet
Comment 2 Jon Kåre Hellan 2004-09-09 19:00:49 UTC
Created attachment 31452 [details]
Result of printing, converted to png
Comment 3 Morten Welinder 2004-09-09 20:16:33 UTC
Why is the line wider during printing?  I thought all this client-side font
business should take care of that.
Comment 4 Andreas J. Guelzow 2004-09-10 01:38:04 UTC
Fonts do not scale linearly wtih change in resolution. A string at 75 dpi may
have a differnet width than one at 300, 600 or 1200 dpi. 

There is already a bug open about that.
Comment 5 Andreas J. Guelzow 2004-09-10 01:45:53 UTC
Jon-Kare wrote: "It would be better to show the complete first line and clip the
second if necessary."

Well, you specified bottom alignment for the cell, so the bottom of the text
will be aligned with the bottom of the cell. If you wanted to see the top of the
cell you could have chosen top alignment.

I think this is not really a bug but just a result of the chosen format for the
cell. (Of course the fact that we need to wrap should be a bug!)
Comment 6 Jon Kåre Hellan 2004-09-10 16:41:08 UTC
I now see that "wrap text" is actually checked for this cell. This makes it
NOTABUG. 

Now I wonder how the cell ended up with "wrap text". Oh, well.
Comment 7 Morten Welinder 2004-09-13 13:44:02 UTC
> Fonts do not scale linearly wtih change in resolution.

This is also true in TeX and a bit (because there is more to small font sizes
that simple scaling).  It's a bit of a problem here, though.

We might have to silently allow minor overshooting, say .5pt
Comment 8 Morten Welinder 2004-09-23 17:21:55 UTC
Mostly fixed in cvs with the new printing code: if the screen layout has only
one line, we now turn off wrapping for the printing layout.
Comment 9 Morten Welinder 2004-09-23 17:34:30 UTC
We will need pango support for the general solution to this.
Comment 10 Andreas J. Guelzow 2007-04-24 22:32:07 UTC
I think the remaining issue is really the change of line breaks for wrapped text between screen display and printing. So the subject should reflect this.
Comment 11 Andreas J. Guelzow 2007-11-08 22:49:14 UTC
Bugs 323315, 152265 and 1060029 essentially describe the same situation: the character sizes vary slightly between screen rendering and printing. As a consequence the line breaks and line heights vary. 

Since these are all the same problem  and 323315 provides a workaround we consolidate them to 323315.

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