If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Floating items are chopped at end of printed page

RESOLVED WORKSFORME

Status

()

Core
Printing: Output
P3
normal
RESOLVED WORKSFORME
18 years ago
8 years ago

People

(Reporter: Hallvard B Furuseth, Unassigned)

Tracking

Trunk
mozilla1.2alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 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
image.

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

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

Comment 2

18 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
(Reporter)

Comment 3

18 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 */
  --></STYLE>
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.

Updated

17 years ago
Status: NEW → ASSIGNED

Comment 4

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

Comment 5

16 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
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9.9

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.2

Comment 7

16 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:
http://www.stud.ifi.uio.no/~haavardw/mozillatest/cutoff.xml

Updated

16 years ago
Keywords: mozilla1.1

Comment 8

15 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

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

Updated

10 years ago
Duplicate of this bug: 427939

Comment 12

10 years ago
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

Comment 13

8 years ago
This bug appears to be FIXED, at least on Gecko 1.9.0 on x86, in Camino 2.1a1pre (1.9.0.15pre 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.

cl

Comment 14

8 years ago
Works for: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009090900 SUSE/3.0.14-0.1 Firefox/3.0.14

Comment 15

8 years ago
fantasai: any idea why this might have suddenly started working in the last 18 months?

Comment 16

8 years ago
No idea, but it works in the 3.0 release. We can mark this bug as WORKSFORME, I guess.

Comment 17

8 years ago
WORKSFORME in Gecko 1.9.0-based (and later) browsers. Too bad we don't know what fixed this, though :-p
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.