216195 - Displayed Page vs. Print and Print Preview: Missing Lines, Shifted Text

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Jeffrey Knauth]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030812
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030812

When I printed http://www.february-7.com/features/conan.htm, I noticed
there were some text lines missing from the printout.  One line was
missing just after the page break from page 2 to page 3, another was
missing just after the break from page 3 to page 4, etc.  However, there
was no missing line when going from page 1 to page 2.

When I examined the printout more closely, I saw the text on page 3 had
been shifted right.  The text on page 4 had been shifted even further
right, etc.  In contrast, the text on page 2 was not shifted relative to
the text on page 1.

Finally, none of the text in the div id=foot section was printed, even
though it displayed fine when the page was rendered.  That text also did
not show up in Print Preview.

Print Preview exactly duplicated all the problems seen in the hardcopy
printouts: a lost line after each page break starting with the second
break; text shifted further and further right starting with page 3; and
no text displayed for the div id=foot section.

I downloaded the HTML and CSS files for the web page in question and
started hacking.  Attached are two (much simplified) files which
demonstrate the problems.  I cut out tags and text that did not seem
relevant and replaced the text with some numbered lines so it would be
easy to see when lines were lost by Print Preview and Print.

I have isolated two of the problems to the '<br style="clear:both">'
line near the end of the PrintPreview.  If '<br style="clear:both">' or
'<br style="clear:left">' is used, Print and Print Preview lose lines
and shift text, as described above.  If '<br style="clear:right">' is
used, or just '<br>, or no '<br>' at all, then no line loss or
progressive shifting occurs.  It looks like the rendering done for Print
and Print Preview has a bug in the 'br style=clear...>' area.

I wasn't able to figure out why the div id=foot text doesn't appear in
Print or Print Preview.  It stayed AWOL no matter what I did.  My HTML
and CSS knowledge is pretty limited, however.

I had originally added a comment to
http://bugzilla.mozilla.org/show_bug.cgi?id=200861 when I first hit this
bug since that problem report talked about lost print lines.  So does
http://bugzilla.mozilla.org/show_bug.cgi?id=102581.  However, neither of
those two sounds exactly like what I found, so I am opening a new bug
and am attaching the two test case files.            

Reproducible: Always

Steps to Reproduce:
1. Open PrintPreview.html (requires PrintPreview.css)
2. Observe rendered page (should look OK)
3. Do a Print Preview (note missing and shifted text)
4. Print (note missing and shifted text)
Actual Results:  
Print Preview and Print cause lost lines and shifted text, as detailed above.

Expected Results:  
Don't lose and shift text.

Comment 1

[Jeffrey Knauth]

Attachment: HTML to demonstrate lost lines problem when printing

Comment 2

[Jeffrey Knauth]

Attachment: CSS required by PrintPreview.html

Comment 3

[Jeffrey Knauth]

Attachment: Combines the two previous HTML and CSS files into one file

This combines the old PrintPreview.html and PrintPreview.css files into one
PrintPreviewV2.html file and should be easier for you to deal with.  The
previous two-file structure was based on the structure of the original failing
web page, but that structure isn't needed to demonstrate the problems.

Comment 4

[Jeffrey Knauth]

This bug is still marked UNCONFIRMED.  I have now rerun the test case
against both 1.5 RC1 and 2003091704 on Windows XP.  All three failure
symptoms are still present as they were on 8/14/03.  I am concerned
because there are lost lines in the printout (and print preview) with no
warning of the loss.  Today I encountered the same problems on another
web page.

Could someone else run the simple (combined) test case and at least
confirm the problem.  I apologize if this isn't the correct procedure to
ensure this hasn't fallen thru the cracks.  Thanks.

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It seems like what's described in this bug report is really two or three
separate problems, and probably thus be covered in separate bug reports. 
(Otherwise it could get really confiusing to track which fix is discussed.)  To
make it easier for people to test those bugs (rather than having to spend a few
minutes reading a large block of text to see how to test the bug), I'd describe
the bugs as follows (based on skimming the above-mentioned large block of text):

Issue 1:

  Steps to reproduce:
    1. Print or Print-Preview attachment 129831 [details]
  Expected results:
    1. On each page, the numbered lines should begin at the same distance from
       the left edge of the page.
  Actual results:
    1. On the third page, the numbered lines begin further from the left edge
       of the page than on the first two pages, and on the fourth page, further
       still.

Issue 2:

  Steps to reproduce:
    1. Print or Print-Preview attachment 129831 [details]
  Expected results:
    1. The following text appears after the line numbered 309 (on the last
       page):
         footer #################################### footer
         footer #################################### footer
         footer ####### This text does not ######## footer
         footer ####### get printed and is ######## footer
         footer ####### not displayed in ######## footer
         footer ####### Print Preview. ######## footer
         footer #################################### footer
         footer #################################### footer
  Actual results:
    1. The text is not printed.

Issue 3:
  Steps to reproduce:
    1. Print or Print-Preview attachment 129831 [details]
  Expected results:
    1. The first numbered line on page three should be one more than the last
       numbered line on page two.  The same for pages three and four.
  Actual results:
    1. The number is two more than the last on the previous page, instead of
       one.

From this point forward, this bug does not cover Issue 2.  (Note that the bug's
summary never covered it.)  If you want there to be a bugzilla bug on it, please
file a separate bug.

Issue 1 and Issue 3 seem like they might be related, so I'm willing to confirm a
bug that contains two issues in one bug, even though that might lead to
confusion later.

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Issue 2 is now bug 220102

Comment 7

[James Napolitano]

Attachment: more reduced testcase

I managed to eliminate most of the unnecessary CSS.  This testcase reproduces
all 3 issues.

Comment 8

[kokuryu]

This is sad - this bug existed back in 2003, and all of a sudden popped back up here in 2007...  Did someone link versus some very old code?

Comment 9

[James Napolitano]

I tested this bug with Firefox 3.6.13 on Linux x64, Ubuntu 10.10 (using their version of Firefox), and issues 1 and 3 and now WFM.

Issue 2 still is present, but that is now tracked in bug 220102, which I will reopen shortly.

Note: removed original URL since it's no longer valid.

(In reply to comment #8)
> This is sad - this bug existed back in 2003, and all of a sudden popped back up
> here in 2007...  Did someone link versus some very old code?

No, bugs are assumed to still be present until someone states otherwise. The same problem in the code persisted since 2003 (or earlier) until after your comment in 2007, and only sometime after then did someone fix it (as part of some other bug report).