Closed Bug 84223 Opened 23 years ago Closed 14 years ago

Printing cut off at the right end / right margin

Categories

(Core :: Printing: Output, defect)

defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: tarahim, Unassigned)

References

Details

Attachments

(4 files)

2001060408 trunk and builds far back.
When you print any page, about 1/8 of the window content is cut off at the right
margin. The margin for the content at the sides are too wide considering the
header and footer are printed much closer to the edge. 
It used to work at some point as I remember, and I have always thought this
problem had something to do with yet to be implemented Page Setup. However,
since the header and footer are printed quite correctly at either ends of the
printed area, I submit this as a separate bug.
OS: Mac System 9.x → All
Hardware: Macintosh → All
*** Bug 88196 has been marked as a duplicate of this bug. ***
hirata masakazu:
Does your problem look like this one:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40445 ?
can we get a target milestone for this....?
Target Milestone: --- → mozilla1.0
dcone... is there no way to get this fixed for 0.9.3 ?

----

CC:'ing katakai@japan.sun.com - I forgot this in the original bugreport (bug
88196)...
>hirata masakazu:
>Does your problem look like this one:
>http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40445 ?

Exactly, yes.
It has something to do with table layout.
*** Bug 86630 has been marked as a duplicate of this bug. ***
*** Bug 89014 has been marked as a duplicate of this bug. ***
sujay/dcone:
This bug is _very_ anoying. It hits nearly all "big" sites like CNN, Yahoo! etc.

Is it possible to get this one fixed for 0.9.4 or 0.9.5, please ?
Roland, are you using the latest trunk? Don wanted me to verify this
on latest turnk, however, we crash upon printing on the latest trunk
bits...Don wanted me to see if its still happening because he said
there were some reflow and margin fixed that went in on the trunk.
I am getting a crash here, too. I filed bug 92424 ("Crash in nsPresShell.cpp due
non-existing |mViewManager|") for that issue.

I'll try to test this once printing is working again.
sujay:
I have a 2001-07-26-08-trunk build with dbaron's print crasher stuff backed-out
+ patch from bug 89851.
I am still getting the problem. Are you sure that dcone's fix is "in" ?
I played a little bit around with the code. If I enlarge the values returned by
DeviceContextImpl::GetDeviceSurfaceDimensions() by 10% the issue disappears in
some cases.

Question:
Are there other functions used in layout code to determinate the size of the
rendering area than DeviceContextImpl::GetDeviceSurfaceDimensions() ?
Adding example URL. Take a look at the 2nd page...
Don, still not fixed according to Roland..

Don this is stil a problem on trunk 8/1 builds. You mentioned you
wanted me to try it out on trunk because of some fixes that went
in a couple weeks ago...but there is still the cut-off on the right
side of output.
*** Bug 93309 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
This is a table which does not get reflowed for the page size, it has a static 
size.. and it larger than the output page size.  Explorer does the exact same 
thing as well as Netscape 4.x.
Is there no way to add a smallish hack to avoid that the table gets cut ?
Unless I'm not seeing a sizing tag, the example I submitted, 

http://www.xml.com/pub/a/2001/03/21/xmltwig.html

has a dynamically sized table between two fixed sized cells that aren't wider
than a page on any normal printer.

I was able to use other browsers (NS4,IE,OW) to print properly. Unless I'm
missing something this should probably be reopened.
When I open the link you gave me.. I see a horizontal scroll bar.. this tells me 
that the page is a static.. or at least a minimum size.. is that right?  A 
printer is not allowed to have a scroll bar (obviously), so it can overflow the 
page size.  I usually look at a page with a scroll bar as a page that can get 
cut off.  Is this wrong.. or right?  If the page dynamically resizes depending 
on the page rectangle.. then it can always fit onto a printer page size.. or 
monitors.. but as soon as a horizontal scroll bar appears.. it seems that there 
is something that says it will not fit horizontaly onto the display.. or a page 
if thats the case.  
I did a few test cases for what I thought was an easy answer, but this seems
more complex than an easy answer.

For starters, the site in my example URL is presenting different HTML to NS4, or
at least NS4 is ignoring pieces it doesn't understand during rendering, which
makes the printing comparison problematic.

It seems that the scrollbar is presented when the window size in the
corresponding dimension becomes smaller than the sum of the minimum sizes of the
rendered page parts in that dimension.  The minimum sizes are determined to be
the size at which the part cannot be reflowed any longer.  In the horizontal
dimension, static width tags are an obvious contributor as are images and long
strings of text.  My base test case was a text file wrapped in <html> and <body>
tags.  When there was an ASCII section divider in there ("-----"...) it
presented the scrollbar when the window got smaller than the text divider.  With
just words, I could resize the window down to the width of the longest word
before getting the scrollbar.  This all makes sense.

What is non-intuititve to the user is that he typically doesn't care about
accurate output rendering with regards to font sizes, etc., he cares about
getting the content onto paper.  With web content he almost always says to
himself, "I want this information to take with me," not, "I understand that
there is a constant scaling factor employed by this browser and with the
information on the screen and the physical constraints of the piece of paper in
my printer I want the output truncated so I still maintain the explicit prefered
font pitch." (or static scaling factor, etc., whatever it is)
 
Since the output of a page that's 1024 pixels wide on my screen to my 1200dpi
printer isn't less than an inch wide (ignoring halftoning for the sake of
argument) there's some scaling that's going on, but it's not in any way tied to
the page that's being printed.  The best way to handle this would be to set the
scaling factor, if the minimum page width is wider than the output device's page
width with the default scaling factor, to a value such that the minimum page
width times the new scaling factor would be equal to the output device's real
page width. That way you could get your whole page (web) onto a page (paper).

I think that solution would satisfy the needs of the people who filed this bug
(speak up if I'm wrong about that).
verified.
Status: RESOLVED → VERIFIED
Should I file a new bug ("[printing] Need workaround for fixed sized tables
which do not fit completely on paper") or can we reuse this one ?

Another issue is that there should be some sort of WARNING that the page cannot
be printed completely. Think about a 200page document - the user prints all the
stuff and finally sees that the resulting print job misses some "things"... ;-(
I have been wondering if there is already a bug for RFE to implement "Try to fit in a page" like NS4 and IE
I couldn't find any "fit to page" bugs - weird.  

Really, "printing cut off at the right end" is just a symptom of "need fit to
page", so the cause of this bug has just been described.  Seems to me it ought
to be reopened with a new summary.
The issue with scaling is a RFE, and is listed in another bug, the print 
preview bug has this issue. We definitely discussed that and probably won't make 
it in for a while.  The biggest problem is printing is treated just like another 
device(screen), so the logic to scale to another page size would have to be 
mananged.  This we thought would best be in the print preview to manage page 
size and how the output should come out.  All the issues with framesets and 
frame, inline frames make this a very complicated issue.
Excuse the naiveté, but wouldn't treating the printing device as a screen with a
much higher resoluton (dpi) make the scaling problem go away (it would be
rerenderd to fit?).  Or maybe the rendering engine doesn't understand dpi...
*** Bug 107961 has been marked as a duplicate of this bug. ***
we're getting several DUPs of this bug..does anyone have a solution
to this problem ?
So if you figure out how many width pixels you need to render a page, divide by
the page width and set the print device(screen)'s DPI setting to that, wouldn't
that work?

If the resultant DPI is less than the browser's set DPI, skip the step so you're
not magnifying unnecessarily.
REOPEN.

We're getting lots of DUPs on this.

We should come up with a solution for this.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
this issue completely blocks me from printing the following page, which can
only be successfully viewed [afaik] in Mozilla/Netscape6.x:

http://mozilla.org/projects/ui/menus/shortcut/
Keywords: helpwanted
This might actually be a Layout bug, in that you need a way of forcing content 
to be a particular width no matter what sort of fixed-width items they contain.

To whoever fixes this, please implement it in such a way that it can be done in 
the browser window as well as on paper. Jag's doing a `View' > `Fit to Window' 
menu item for images, and I'd like it to apply (as `View' > `Fit to Window 
Width') to HTML as well.
also happens for http://lasseters.com.au
Keywords: edt0.9.4, topembed
Note: IE 6, Nav 4.x cut off the page the same as Mozilla. The user will be able
to reduce the page elements for printing when "print scaling" is implemented.
Keywords: edt0.9.4, topembed
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
moving to 9.9 for and taking bug
Assignee: dcone → rods
Status: REOPENED → NEW
Target Milestone: mozilla1.0.1 → mozilla0.9.9
verified.
Print scaling is now turned on and you can scale down large pages for printing.
Since "fit to page" already has a bug I will mark this WFM
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
Netscape 6.2.1+
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20020122 
Netscape6/6.2.1+

WIN ME

IE ver 500.2614.3500
Printing on HP LaserJet 8100 Series PS

-------

I tested a significant number of sites, including:

1.   www.officeinnovations.com
2.   www.autoweb.com
3.   www.attws.com

Window content is still cut off at the right side, though the portion of 
missing content is much less than 1/8 of the window.  On some pages, the 
missing content amounts to only a few letters of the right-most words on the 
page (or - to the very right edge of graphics images).  On other pages, the 
content loss is more significant.

The same problem exists in IE and is, in fact, worse for several of the sites I 
printed out.
rods:
Are you sure that WorksForme is OK for this bug ?
Trying to print
http://www.faz.net/IN/INtemplates/faznet/default.asp?tpl=faz/drehscheibe.asp&rub={2D82590A-A70E-4F9C-BABB-B2161EE25365}
results in a printout where nearly 1/3 of the content is missing... ;-(
reopening..people are still experiencing this problem
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
This bug is fixed in the sense that it's possible to get the whole page on one
sheet - you have to fiddle with the page scaling option until you get it right.
 Previously, there was no work around, so the bug is fixed.

This is still far from optimal.  Optimal is automatically finding the right
scaling factor.  That's being bug 100967, tracked at bug 106332.  That's an RFE,
even though no user will consider printing acceptable until it's done. It's a
DWIWNWIS issue.  

The only downside to closing this bug is that there will be alot of bugs filed
with a subject like this one and someone has to know that it's really a dup
against bug 100967.
And, just to contradict myself, I just noticed bug 85768, which is another
reason why you might get "Printing cut off at the right end", only somewhat
related to scaling. 
 
Maybe this should become a tracking bug for all the reasons you might get
printing cut off at right end?  bug 106332 and bug 85768 would be the two
blockers that I know of.
Ok, what is the real bug here?

If a page uses divs or tables and sets their width to something wider than a
printed page, they will be just too wide to print on a page. You can scale the
page to make it fit.

So, if there is a normally "flowed" page that is getting cropped, than leave
this open (and comment it and give me an URL), if not please close this bug or
explain further. Thanks. marking future for now. reset it to 0.9.9 when you want
me to look at it again.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.9 → Future
rods:
Usually less than one 1 inch(=2.54cm) gets lost to this issue (fixed-size
table/div).
Question is whether we can either implement a horizontal-only autoscale
functionality (is there a bug for that) or do the layout in two steps:
a.) try with normal page width. If [a] causes elements to draw over the page
bounds then...
b.) ... take away an inch (or a percentual amount) in paper width and check if
this fixes the issue (e.g. less elements cut at the right end).

Another "quick" workaround may be to make the borders at the right end slightly
larger (1cm - 2cm) ...
One more page: http://www.bestlifeint.com/articles/soy_benefits.html
which also comes not complete on the right side. 
I see Severity for this bug: Major, but target milestone: Future.
I would suggest to proceed with this in Buffy.
Probably better if Sujay nominates it by entering 'nsbeta1' keyword.
Issue present when printing them using Mozilla/5.0 (Windows; U; Windows NT 5.1; 
en-US; rv:1.2b) Gecko/20021014 Netscape/7.0+, on Windows 98, Me, 2000 or XP:

www.ual.com
www.officemax.com
www.askjeeves.com (only cuts off the right margin when using Win 98 or Me. Does 
not happen when using W2000 or XP)
cnn and ual look fine to me.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed
also gets cut off in the right side in print outs.
This URL is a very important public database system for Bio- and Medical-community.
I can confirm Additional Comment #52.

Mac OS 9.2.2 English-North American. ‘Orbit 3+1 1.2 0.0.6.5-dev’ theme is installed.
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.3a) Gecko/20021115
Build ID 2002111503.

IMHO printing by Mozilla Navigator still compares very poorly against IE.
Works fine on Win2k.

Just a point of reference... Our code base works on all platforms, MS has
different code bases and different teams for Mac and Windows. (In fact, I have
heard that anyone of their teams dwarfs ours in size) They get to focus solely
on the intricacies of each of those platforms and not worry about portability. 

I am not making an excuses, I am just pointing out the reality of what we do and
our requirements.

With Chimera 0.6, right cut off (small portion) of printed page also happens but
only when I print my bank statement (it's sort of delicate for me to give you
the address...). I can print the same page ok with IE though.
This problem is still occurring, at least in 1.2.1 on Windows 2000.
Attachment #115768 - Attachment mime type: application/octet-stream → application/pdf
I think this bug has to do with the font that Mozilla uses when it determines
how to lay out the page to send to the printer. It does not seem to use the
displaying font's metrics, causing it to cut off the right bit of text if the
displayed font is wider than the font being used for the measurements.
THis bug is still present in 1.5rc2. In effect, whenever I need to print a page,
I first save it to HTML, then I open it in OpenOffice.org and then I print. It
is a real pain.

Does noone else print stuff from the Web? :-(
I have to agree with Comment #58. I find this bug very annoying. Printing off a
page is a common task for many people/businesses and I don't think it's very
good that the text is cut-off at the right hand side of the page.

I am using 1.5 final:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

The problem exists on the majority of pages. Go into 'File > Print preview'
right now and look for yourself. Even though 'shrink to fit' is selected there
is still some of the text missing from the right hand side of the page at the
top (where 'Reporter:tarahim@earthlink.net (hirata masakazu)' is).

Also, if a line of text just happens to be where one piece of paper goes into
another whilst printing the line is split *between* the two pages. This is also
very annoying. This was actually what I was looking for when I found this bug.
It is very similar. Essentially text is being lost/split when printing. Not good.
Another example would be:
http://www.planetblackandwhite.com/features/articles/reader/0014.shtml

The right-end of the text is trimmed off instead of wrap to the next line.
Does anyone here have a testcase that "Fit to Page" (bug 100967) doesn't fix?

If that could be on by default would that resolve this bug?

Looks like rods is gone - reassigning to default component owner.
Assignee: rods → core.printing
Status: ASSIGNED → NEW
QA Contact: sujay
*** Bug 208861 has been marked as a duplicate of this bug. ***
This is weird. I found a good testcase page at:
http://www-106.ibm.com/developerworks/rational/library/3757.html
that reproduces this bug, but only on some platforms.  Indeed, it seems that the
'print preview' view is always clipped on the right hand side, but the printed
output isn't. Here's the scoop:

                 Truncated in Print Preview       Truncated on Printed Paper
Windows 2000               Y                                Y
Windows XP                 Y                                N (prints fine).

I have a reduced testcase (I think) but need to test this on my Win2k machine
before uploading (testing won't happen until thursday). 
(I'm amazed that this bug is still present three years after reporting it)
I see the same problem with Mozilla 1.6: Headers and footers extend left and
right over the area where printed output is shown. Maybe the page just has a
horizontal printing offset (i.e. page shifted to the right by about 1cm (0.5in
roughly)) that causes the rightmost part of the printing contentd to be clipped
(the rightmost visible printing also is about 1cm further left that the headers
and footers).
In addition, in the page preview things look OK.
Having Fit to Page turned on in the printer dialog turned on does not fix the
problem with the text being cut off on the right hand side. (mozilla headers &
footers are unaffected as noted by other reports)

http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=pubmed&dopt=Abstract&list_uids=15492839
or for that matter any single result from www.pubmed.org (which is used by many
scientists) cuts off the right hand side of the text.
Also One of the scientists tells me that right edge text gets cut off on pubmed
html based emails.

Even if i do a page set up and change it from Any printer to be the printer that
i am printing to (which i verified it had the correct set up) it still occurs.
In mozilla 1.8a4 the abstract title ends in "recepto in co" with no page set up.
However after the page set up is done it ends in "recptor in colo" and the
vertical bar in the n. So page set up is changing things.

I can work around the issue by doing a print at 80% in the page set up.

Also note that geko engined Camino 2004082512 (v0.8.1) manages to do the job
right. My guess would be the way it interacts with the printer drivers on the
mac is different. You might want to talk to the Camino printer driver developers
to see what they are doing differently and potentially get it fixed.

Testing of this was done on a macintosh using both Mac os X 10.3.5 or 10.3.6

Products affected the latest build of Mozilla 1.8a5
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041109
Firefox/1.0
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 

Mozilla 1.7.3 & 1.7.2 Final Release fo 
Mozilla 1.8a3 & 1.8a4
 
PRODUCT NOT Affected
Camino 2004082512 (v0.8.1)
*** Bug 268913 has been marked as a duplicate of this bug. ***
Another example of truncated text can be found at

http://www.peterguy.com/php/install_IIS6.txt

It would seem to always happen on plain text files that have long lines. My
issue is in Mozilla 1.6, 
identification string "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040113"

To me this isnt a 'showstopper' but it is rather irritating to have to open
another browser when i want to print stuff..
Adjusting margins does not seem to help.  Words are still cut off on the right
end when margins are changed, but words wrap differently.  Links also do not
align properly (which might be a clue... I think it's not properly calculating
the width of the text).  Try a print preview on
http://www.eesanjose.org/faq.php?nographics=1 to see what I mean.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
(In reply to comment #68)
> Adjusting margins does not seem to help.  Words are still cut off on the right
> end when margins are changed, but words wrap differently.  Links also do not
> align properly (which might be a clue... I think it's not properly calculating
> the width of the text).  Try a print preview on
> http://www.eesanjose.org/faq.php?nographics=1 to see what I mean.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0

Correction:  Prints okay, but print preview is wrong.
*** Bug 285655 has been marked as a duplicate of this bug. ***
(In reply to comment #68)
> Adjusting margins does not seem to help.  Words are still cut off on the right
> end when margins are changed, but words wrap differently.  Links also do not
> align properly (which might be a clue... I think it's not properly calculating
> the width of the text).  Try a print preview on
> http://www.eesanjose.org/faq.php?nographics=1 to see what I mean.

print and ppv WFM for the majority of the examples cited (of the websites that
still exist or haven't changed), example:
http://www.bestlifeint.com/articles/soy_benefits.html

a couple examples that still don't work:
 http://www.planetblackandwhite.com/features/articles/reader/0014.shtml
 http://www-128.ibm.com/developerworks/rational/library/3757.html
both involve elements of tables and javascript, which probably implicate other
bugs with better test cases

(amazing that at 4 years of age, this doesn't have a reduced testcase attached)

re: http://www.peterguy.com/php/install_IIS6.txt - one wouldn't expect plain
text to wrap
Summary: Printing cut off at the right end → Printing cut off at the right end / right margin
I first added this to bug 325093, but then found this one. An issue similar to mine was declared a duplicate to this.

My report from there (updated):
I'm also seeing chopped off text in 1.7.11(Win32) on Windows 2000.

When trying to print e.g.
http://en.wikipedia.org/wiki/Software_patents_under_TRIPs_Agreement on a HP
LaserJet 4MV (PS), some text is cut off at the right.

*Sometimes* it helps to adjust the scale manually because word wraps are then
placed differently.

It seems the run length of <b> and <i> text is not calculated correctly, as I
also see some bold stuff (e.g. some links) exceed their run length and extend
into the normal text following them.

Update (shame on me): For the above page, this is only in the preview. The printout is correct. But I've had cases where cut-off text also appeared in the print, though I have none at hand now.

Just one, but this is a bit different:
http://de.wikipedia.org/wiki/Trivialpatent contains a link which, when printed, expands to the full URL. This URL is then cut off because it's bigger than the page width allows.

But another thing: Try to set a different scale when print previewing one of the above wikipedia links. Does not really look scaled to me, font size appears to always stay the same. Any idea what causes this?

MOW
when i print to PDF, the same thing happens: a bit of the right margin is cut off when i attempt to print this page:

http://www.cybersource.com/news_and_events/view.xml?page_id=1577
Just thought I would let you know that for at least the pubmed search results that I hav mentioned above this is still occuring, in the mac version of 2.0.6 and does not occure in Safari.

Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/2007072517 Firefox/2.0.0.6

This is also occuring in sea monkey 1.1.4


Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
For me, this problem is limited to just the last character or two of long lines, truncated right in the middle of a character.  With DejaVu fonts, every printout is affected here, with Firefox 2.0.0.11/os2. I too tried adjusting margins and scaling, and the new word wrapping would sometimes cover it up, but more often would just change what line got truncated.  Then I found that I could cover the bug up reliably by creating a usercontent.css file in the user profile chrome directory, with the code html>body {padding-right: 1 em !important}. This doesn't seem to break the web pages I visit, and it totally stopped the truncation. 

I also have the problem of lines having text attributes like <i> and <b> having overlapping text, especially noticeable with DejaVu fonts, but I think this belongs in a separate bug.  It's just like preview bug #259186 except that it does affect printing.  So far I've found no corresonding print bug. Maybe one should be entered, but I want to see if it happens on Windows first. 
Most of what I see as problems with printing from Firefox is covered in the good discussion for this issue, except for one point. A single web page doesn't have to print on a single sheet of paper. In some cases, I think it would be more useful and legible to have overflowing content print on additional pages, or at least allow that option.

When I use print preview on, for example, this large-area web page http://www.shopping.hp.com/webapp/shopping/series_can.do?storeName=computer_store&landing=notebooks&a1=From+price&v1=%24500-%24800
I can turn on scaling to make the contents fit to a portrait or landscape A/A4 piece of paper. However, in landscape format, the contents overflow the bottom of the page, and Firefox (2.0.0.13) does not attempt to put these contents on a second page.

I certainly understand the desire to fit web page contents to as few printed pages as possible, but rendering overflowing content to additional pages seems vastly preferable to omitting it entirely.

I would be happy to help with creating a "reduced testcase"; please contact me via email with instructions or references to requirements for doing this.
Assignee: printing → nobody
QA Contact: printing
(In reply to comment #77)
> Most of what I see as problems with printing from Firefox is covered in the
> good discussion for this issue, except for one point. A single web page doesn't
> have to print on a single sheet of paper. In some cases, I think it would be
> more useful and legible to have overflowing content print on additional pages,
> or at least allow that option.
> 
> When I use print preview on, for example, this large-area web page
> http://www.shopping.hp.com/webapp/shopping/series_can.do?storeName=computer_store&landing=notebooks&a1=From+price&v1=%24500-%24800
> I can turn on scaling to make the contents fit to a portrait or landscape A/A4
> piece of paper. However, in landscape format, the contents overflow the bottom
> of the page, and Firefox (2.0.0.13) does not attempt to put these contents on a
> second page.
> 
> I certainly understand the desire to fit web page contents to as few printed
> pages as possible, but rendering overflowing content to additional pages seems
> vastly preferable to omitting it entirely.
> 
> I would be happy to help with creating a "reduced testcase"; please contact me
> via email with instructions or references to requirements for doing this.

Cannot reproduce ==> http://rnik.fileave.com/84223_1.pdf

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
(In reply to comment #72)
> I first added this to bug 325093, but then found this one. An issue similar to
> mine was declared a duplicate to this.
> 
> My report from there (updated):
> I'm also seeing chopped off text in 1.7.11(Win32) on Windows 2000.
> 
> When trying to print e.g.
> http://en.wikipedia.org/wiki/Software_patents_under_TRIPs_Agreement on a HP
> LaserJet 4MV (PS), some text is cut off at the right.
> 
> *Sometimes* it helps to adjust the scale manually because word wraps are then
> placed differently.
> 
> It seems the run length of <b> and <i> text is not calculated correctly, as I
> also see some bold stuff (e.g. some links) exceed their run length and extend
> into the normal text following them.
> 
> Update (shame on me): For the above page, this is only in the preview. The
> printout is correct. But I've had cases where cut-off text also appeared in the
> print, though I have none at hand now.
> 
> Just one, but this is a bit different:
> http://de.wikipedia.org/wiki/Trivialpatent contains a link which, when printed,
> expands to the full URL. This URL is then cut off because it's bigger than the
> page width allows.
> 
> But another thing: Try to set a different scale when print previewing one of
> the above wikipedia links. Does not really look scaled to me, font size appears
> to always stay the same. Any idea what causes this?
> 
> MOW

Cannot reproduce any of the above.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401
Firefox/3.6.3
As per comment 71 and my recent findings, should we CLOSE this bug?
Unless you are using a Daily build or a non production build, The problem appears not to be truly fixed. 

It looks like a workaround has been added (in 3.6.3 or earlier) as a default to users profiles which provides in the print dialog box a selected option of  "Ignore Scaling and Shrink to Fit Page width."   If you uncheck that Item the right side continues to get cut off & not printed on any other sheets of paper. (for extra wide table type pages or users with bad eyesight this could be a problem) 


Steps to Reproduce.

1. Run Firefox (3.6.3) on a mac.

2. Go to http://en.wikipedia.org/wiki/Periodic_table_%28wide%293. Select Print. 

3. Select Firefox From the "Options" Drop down menu.

4. Uncheck "Ignore Scaling and Shrink to Fit Page Width"

5. Click Print.  (FYI. I printed to the size US letter, although I later found out that saving to PDF has the same issue without killing any trees)

Expected Results. 
To have multiple pages printed that showed the entire periodic table of elements. example will be attached in pdf form.

Actual Results. 
In portrait mode groups 12 to 18 get cut off.


Additional Notes.

 http://www.nhl.com/ice/playerstats.htm cuts of the FO% Colum in the table as well as in the footer which has freeform wrapping text most of the first hump in the word mark print in the text "trademarks and Vintage Hockey word mark and logo"  Example will be attached in pdf form.


Portrait cuts off right.
http://www.asciitable.com/ Example will be attached in pdf form.

http://www.officemax.com/ (a previously stated site) Also has this issue (cuts off the right of the Office Supplies, Office Technology and Office Furniture Sections) however it seems to have some other rendering issues as well.

http://www.officemax.com/ (a previously stated site) Also has this issue however it seems to have some other rendering issues as well.


Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Example of Steps to reproduce issue in Comment #81
see Additional notes section of comment 81. Also note headers with today's date & the website.
(In reply to comment #81)
> Unless you are using a Daily build or a non production build, The problem
> appears not to be truly fixed. 

Did you see my build identifier? I'm using Firefox 3.6.3 (en_US) standard on Windows XP Professional SP3.

> Steps to Reproduce.
> 
> 1. Run Firefox (3.6.3) on a mac.
> 
> 2. Go to http://en.wikipedia.org/wiki/Periodic_table_%28wide%293. Select Print. 
> 
> 3. Select Firefox From the "Options" Drop down menu.
> 
> 4. Uncheck "Ignore Scaling and Shrink to Fit Page Width"
> 
> 5. Click Print.  (FYI. I printed to the size US letter, although I later found
> out that saving to PDF has the same issue without killing any trees)
> 
> Expected Results. 
> To have multiple pages printed that showed the entire periodic table of
> elements. example will be attached in pdf form.
> 
> Actual Results. 
> In portrait mode groups 12 to 18 get cut off.

WFM ==> http://rnik.fileave.com/84233_PeriodicTable.pdf 

> Additional Notes.
> 
>  http://www.nhl.com/ice/playerstats.htm cuts of the FO% Colum in the table as
> well as in the footer which has freeform wrapping text most of the first hump
> in the word mark print in the text "trademarks and Vintage Hockey word mark and
> logo"  Example will be attached in pdf form.

WFM ==> http://rnik.fileave.com/84233_PlayerStats.pdf

By the way, did you see the small "Print" link on the right, above the "Legend >" button? It produce a print-friendly page.

> http://www.asciitable.com/
> Portrait cuts off right.

CONFIRMED! ==> http://rnik.fileave.com/138484_print.pdf
In Landscape mode print is OK.
(In reply to comment #85)
> > http://www.asciitable.com/
> > Portrait cuts off right.
> 
> CONFIRMED! ==> http://rnik.fileave.com/138484_print.pdf
> In Landscape mode print is OK.
RNicoletto: I think you linked to the wrong PDF there.  That PDF doesn't match asciitable.com, and instead it looks like a snippet of test-HTML -- it says "First cell 1pt | Second cell 0.9pt | Third cell 0.8pt [...]".  (It's also the same PDF you linked to in bug 169132 comment 22.)

However, no reason to update the link, as long as what you've got roughly matches the PDF that was already attached here in comment 84.

(FWIW, this is WFM at asciitable.com on Ubuntu Linux, using Firefox 3.6.3.)
Sorry, in Comment 86 I had "Shrink to fit" selected, which I now see is supposed to be deselected, from Alexander's instructions in comment 81.  That changes things a bit.

Alexander: So, given web content that's inherently wider than a page, and given that a user explicitly requests that the content NOT be shrunk, you want the content to still all get printed somehow -- how exactly? Do you want Firefox to print a "grid" of sheets, in order to fit all the non-shrunk content that falls off the edge?

If that's the request (based on my understanding of comment 81), then this is WONTFIX imho (or perhaps would-be-cool-to-have-but-very-complex-to-do-right).  It's complicated enough to render arbitrary web content to a single column of printed pages, and rendering instead to an arbitrary-width grid of pages is beyond what Gecko can do for you right now. :)
(In reply to comment #87)
> Alexander: So, given web content that's inherently wider than a page, and given
> that a user explicitly requests that the content NOT be shrunk, you want the
> content to still all get printed somehow -- how exactly? Do you want Firefox to
> print a "grid" of sheets, in order to fit all the non-shrunk content that falls
> off the edge?

Just FYI, this is how Internet Explorer print that page ==> http://www.filefactory.com/file/b11h085/n/IE8_asciitable.com.pdf

IMHO nice print.
(In reply to comment #88)
> Just FYI, this is how Internet Explorer print that page ==>
> http://www.filefactory.com/file/b11h085/n/IE8_asciitable.com.pdf

That's nothing extraordinary -- it looks like they're just shrinking-to-fit, and they basically match Firefox's default behavior. As discussed in Comment 87, I think Alexander is asking for reasonable behavior when shrink-to-fit is explicitly *disabled*.  (I don't know if IE even lets you disable it.)

(Also: when possible, it's best to attach pdfs/screenshots directly to the bug, rather than posting them on third-party sites, (a) so they don't arbitrarily become 404's at some point (and are accessible to future bug-viewers), and (b) so they don't spam the downloader with flashy ads to "please wait 30 seconds for your download, or join our premium members club now!" like e.g. Filefactory does)
RNocoletto.  comment #88
I concure with Daniel Holbert in the posted comment number 89. It would be far more helpful if you where to please add the IE 8 PDF as an attachment inside of this ticket. Also the third party site is explicitly denied by my companies fairly unrestrictive malware prevention gateway. If it was properly attached to this bug report it would save other users a lot of hassle.

Daniel Holbert. comment number 87
A grid of pages is a good way to put it. However I don't consider it a
"would-be-cool-to-have" as a lot of other other graphic, 
text and spread sheet applications do such that In my opinion I have come to
expect it as a basic capability in any applications that allows you to print.  

Please note: I am explicitly not passing any judgment on how difficult it would be to do.
I'm resolving this as WORKSFORME, since the problem as originally described (back in 2001) is fixed now that we have the default "shrink to fit" setting.

As for printing to a "grid of pages" when shrink-to-fit is disabled: that's more of an enhancement request (adding new functionality), and it merits a separate bug. (plus, this bug here is already getting unmanageably long. :))  So, I've filed Bug 559671 to track the potential "print to grid of pages" feature.
Status: NEW → RESOLVED
Closed: 23 years ago14 years ago
Resolution: --- → WORKSFORME
No longer depends on: 106332
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: