428109 - 'Print Selection' prints nothing on page with very wide div

Status: NEW

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (30-in wide div)

This bug was discovered in bug 402264 comment 41, and it's present in both Firefox 2 and Trunk.

STEPS TO REPRODUCE:
 1. Open testcase
 2. Select any chunk of text (or Ctrl-A to select all)
 3. Ctrl-P to print
 4. Select "Print Selection"
    (in FF2, choose "Selection" under "Print Range")
    (in FF3 under Linux, choose the "Options" tab, and check "Print Selection Only")
  5. Go ahead and print (either to file or to a real printer)

EXPECTED OUTPUT: selected text visible
ACTUAL OUTPUT:  blank page

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: reference 1 (12-in wide div)

This testcase just has a skinnier div (though it's still wider than a page), and it works fine for print-selection.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (20-in-wide div)

This testcase also shows the bug, with a 20-inch wide div.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (100-in wide div)

It's possible the smaller divs work on Windows (I'm not sure, as my windows box is being weird right now.)  However, this version with a 100-inch-wide div definitely doesn't work on Windows.

Comment 4

[Daniel Holbert [:dholbert]]

Note that, while they break in "print selection" mode, these testcases all work fine when printed *normally* (not as selection) -- the right edge of the div just gets cut off, which is fine.

Briefly, here's the code that's responsible for this discrepancy:

If we're doing 'print selection' mode, we tweak mPrt->mPrintFrameType here:
  http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/printing/nsPrintEngine.cpp&rev=1.174#2848

And that change to mPrintFrameType affects which shrink ratio we choose, here:
   http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/printing/nsPrintEngine.cpp&rev=1.174#1815

1818    float ratio;
1819    if (mPrt->mPrintFrameType == nsIPrintSettings::kFramesAsIs || mPrt->mPrintFrameType == nsIPrintSettings::kNoFrames) {
1820      ratio = mPrt->mShrinkRatio - 0.005f; // round down
1821    } else {
1822      ratio = aPO->mShrinkRatio - 0.005f; // round down
1823    }

In normal printing, we use mPrt's shrink ratio, but in print-selection, we end up using aPO's shrink ratio.

This matters because mPrt->mShrinkRatio is capped (on the lower end) to 0.60, here...
   http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/printing/nsPrintEngine.cpp&rev=1.174#1665

... but no such capping is done for aPO's shrink ratio.

So, in summary:  if we have a very wide div, we'll get a very small shrink ratio (e.g. 0.15), in an effort to make it fit. For normal-printing, that shrink ratio is capped with a lower-bound of 0.60.  If we do print-selection, however, we don't ever cap it, so we keep a very small print ratio.

(I think this might end up causing the bug because of the loss of precision when we scale up by large amounts.)