Floating items are chopped at end of printed page




19 years ago
10 years ago


(Reporter: h.b.furuseth, Unassigned)



Firefox Tracking Flags

(Not tracked)





19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS 5.7 sun4u; en-US; m16) Gecko/20000621
BuildID:    2000062115

When a floating image or other box is printed and reaches
the end of the page, it is chopped and does not continue
on the next page.

Reproducible: Always
Steps to Reproduce:
1. Fetch http://www.uio.no/~hbf/mbug2.html .
2. Print it - to file if you have ghostview.
3. Look at the results: 2nd circle and 2nd box
are both too big for their page.  (If they are not,
adjust the margins so that they _are_ too big
and try again.)

Actual Results:  Page 1 contains text + 1st circle + start of 2nd circle.
Page 2 contains text + 1st DIV    + start of 2nd DIV.
(Each DIV has "DIV #n..." at the top and
"...DIV #n" near the bottom.)
Page 3 contains just the text "(eof.)"

Expected Results:  Either:
2nd circle is not printed on 1st page, but all of it
is printed on 2nd page.  If so, maybe the text it
floats "around" is pushed down to 2nd page too, or maybe
only the floating image is pushed down (if so it'll
look like it's not floating).  In any case, text from
the next <br clear=all> will have to come after the

or: 2nd circle starts on page 1 as before,
and page 2 starts with the rest of 2nd circle.  And so
on for the rest.

(the same URL also illustrates another (reported) bug.)

Comment 1

19 years ago
2000072420win32talkback. Printed to Postscript file using windows 2000 `HP 
Color LaserJet PS` driver. ran ps2pdf to view with acrobat. [confirming]
Ever confirmed: true
OS: Solaris → All
Hardware: Sun → All

Comment 2

19 years ago
This bug has been marked future because we have determined that it is not 
critical for netscape 6.0.  If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future

Comment 3

19 years ago
I think potentially silent loss of information is fairly high-profile bug.
Also, the number of print bugs are still annoying to the point where I have to
keep another browser around in order to print things.  I don't think that's the
advice you want sysadmins to give their users.

I suggest you temporarily insert a pref setting which removes printing features
that work as poorly as this.  E.g. it'd do the equivalent of this (which
doesn't work but I trust you get the idea):
  <STYLE media=print><!--
  * {float: none !important;}  /* avoid this bug */
  *[text-align=justify] {text-align: left (or auto) !important;} /* bug 40130 */
For stuff like Bug 37685 (<pre> spacing doesn't work), maybe gross hacks like
printing _everything_ in a fixed font would be easy enough to throw into this
pref setting(s)?  Just a loose thought.


19 years ago

Comment 4

18 years ago
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay

Comment 5

18 years ago
I want this bug fixed.
Also cc'ing attinasi, cause he says it might be his bug.
Reassigning to Marc.
Assignee: dcone → attinasi
Target Milestone: Future → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.2

Comment 7

17 years ago
I see this bug as a major drawback in using mozilla. I have to walk three floors
to use a computer which prints theese kind of pages correctly. In my opinion it
should be a high priority bug. For instance:


17 years ago
Keywords: mozilla1.1

Comment 8

17 years ago
*** Bug 148809 has been marked as a duplicate of this bug. ***
Assignee: attinasi → printing
QA Contact: sujay
*** Bug 287700 has been marked as a duplicate of this bug. ***

Comment 10

14 years ago
*** Bug 314508 has been marked as a duplicate of this bug. ***


11 years ago
Duplicate of this bug: 427939
So what're the odds we have someone around who knows a) why this is happening and b) how to fix it?
Assignee: printing → nobody
QA Contact: printing
This bug appears to be FIXED, at least on Gecko 1.9.0 on x86, in Camino 2.1a1pre ( 2009100200). I.e., I get the "expected results" (option 2; "2nd circle starts on page 1 as before, and page 2 starts with the rest of 2nd circle") when printing this page on Mac OS X 10.5.


Comment 14

10 years ago
Works for: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/2009090900 SUSE/3.0.14-0.1 Firefox/3.0.14
fantasai: any idea why this might have suddenly started working in the last 18 months?

Comment 16

10 years ago
No idea, but it works in the 3.0 release. We can mark this bug as WORKSFORME, I guess.
WORKSFORME in Gecko 1.9.0-based (and later) browsers. Too bad we don't know what fixed this, though :-p
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.