The default bug view has changed. See this FAQ.

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

NEW
Unassigned

Status

()

Core
Printing: Output
9 years ago
5 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

9 years ago
Created attachment 314709 [details]
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
(Reporter)

Comment 1

9 years ago
Created attachment 314710 [details]
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.
(Reporter)

Comment 2

9 years ago
Created attachment 314711 [details]
testcase 2 (20-in-wide div)

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

Comment 3

9 years ago
Created attachment 314717 [details]
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.
(Reporter)

Updated

9 years ago
OS: Linux → All
Hardware: PC → All
(Reporter)

Comment 4

9 years ago
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.)
(Reporter)

Updated

9 years ago
Summary: Print Selection prints blank page, on a page with very wide div. → 'Print Selection' prints nothing on page with very wide div

Updated

7 years ago
Duplicate of this bug: 448549
You need to log in before you can comment on or make changes to this bug.