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.

*** 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....?

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. ***

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.

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.

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/

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

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.

The fix feature is being planned over at bug 106332.

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)

moving to 9.9 for and taking bug

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

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

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.

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.

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.

*** 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

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

dups? bug 206848, bug 109565, bug 322203

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.

(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

See comment 81 "Additional Notes."

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.