444458 - In Print-Preview at some zoom levels, <span> has trailing blank space, or overlaps other text.

Status: RESOLVED WORKSFORME

(Core :: Print Preview, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Steps to reproduce:
 1. Load testcase
 2. Zoom in (Ctrl+mousewheel)

ACTUAL RESULTS:
  At some zoom levels, the span either has blank space after it, or overlaps the text following it. Also, for <u>/<del>, the line that's drawn through/below the text is either too short or too long.
  Basically, it looks like we're not computing the span width correctly.

When I just view the page normally (not in print-preview) and I zoom, I don't see the buggy behavior.  So, this seems to be a print-preview specific bug.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot: zoomed 1x (notice incorrect blank space between words)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot: zoomed 2x (notice incorrect slight overlapping of words)

Comment 3

[Martijn Wargers (dead)]

Seems to work fine here on windows.

Comment 4

[Daniel Holbert [:dholbert]]

Good to know.  I'm guessing it's a cairo issue -- I think cairo-related bugs have caused other similar Linux-only printing issues in the past.

Comment 5

[Martijn Wargers (dead)]

Sorry, never mind, I see it now, I have to zoom in while on print preview.

Comment 6

[Daniel Holbert [:dholbert]]

Oops, that's my fault -- s/"Load testcase"/"Print Preview the testcase"/ in step 1 of the steps-to-reproduce.

Comment 7

[Daniel Holbert [:dholbert]]

OS / Hardware --> all, per comment 5.

Comment 8

[Daniel Holbert [:dholbert]]

Like bug 444448, this bug originated in the 2007110904 nightly, which is when bug 363265 landed and enabled zooming *within* print-preview.

Before that bug landed (i.e.in the previous nightly, 2007110804), your browsing zoomlevel would set the print-preview zoomlevel.  So, initially I thought I might be able to reproduce this bug in earlier nightlies by zooming and _then_ print-previewing, but that doesn't seem to reproduce it -- it's specifically a problem with zooming *within* print-preview.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

This testcase demonstrates what's going on. The bordered 300px-wide div can be used as a sort of ruler -- on my machine, its right border falls approximately at the division between a's and b's. 

If you view the testcase normally (not print-previewed), and zoom in and out, you'll see that the split-point between a's and b's moves around a bit at different zoom levels -- sometimes it falls after the div's right border, and sometimes it falls before it.  This presumably happens because we're using different fonts, and so the "aaaa..." string changes length slightly.  However, notice that we never leave a chunk of blank space between the a's and b's.

If you zoom *within print-preview*, you'll see that the length of the "aaa" string changes there as well, indicating that we're switching fonts -- HOWEVER -- in print-preview, the start-point of the "bbbb" string appears to be stuck.  It never shifts to accommodate shorter "aaa" strings".  This is most noticeable when I've zoomed in 4x.

So it looks like in print-preview, we do an initial reflow, at zoomlevel = 100%.  Then, as we zoom, we assume that the textruns' start-positions and lengths can be scaled up and down exactly with the zoom-level.  However, that assumption doesn't hold, because we change fonts, and that tweaks positioning and length.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screenshot: testcase 2, zoomed 1x & 4x, normal & in print-preview

Here's a screenshot of testcase 2, at two zoomlevels, in both normal-browser-mode and print-preview-mode, demonstrating the problem.

Comment 11

[Jonathan Watt [:jwatt]]

It doesn't seem to be possible to zoom any more. Can you still repro this, Daniel?

Comment 12

[Daniel Holbert [:dholbert]]

I cannot repro anymore (i.e. I can confirm that print preview won't let me zoom anymore with ctrl-scrollwheel and ctrl +/-)

I also tried adjusting the "Scale" dropdown, which is the closest thing we have to zooming now in print-preview, and that didn't reproduce the bug.

So I guess this is WFM.