Open
Bug 839802
Opened 11 years ago
Updated 2 years ago
Print selection doesn't honor percent heights (because it doesn't have anything to resolve them against)
Categories
(Core :: Printing: Output, defect)
Tracking
()
NEW
People
(Reporter: julian.viereck, Unassigned)
Details
Attachments
(3 files)
This is a followup bug to do a "proper" fix for the problem reported in bug #830278. A possible reason for the high memory usage is presented in bug #830278 comment #c13.
Reporter | ||
Comment 1•11 years ago
|
||
I talked to dholbert on IRC about this: http://irclog.gr/#show/irc.mozilla.org/developers/464458 He pointed out "we probably need to first figure out why print-selection isn't working _at all_ for PDF.js". Based on that I've started to create a simple reduction of the problem. The version attached here doesn't use the printCallback so far but is already causing an issue. The height of the printed divs are different depending on the "print-selection-only" mode enabled or disabled. Is this a bug or a feature?
Reporter | ||
Comment 2•11 years ago
|
||
This output was generated by selecting the "Some text on the first page." string, print the document, select "Print Selection Only" and choose "PDF -> Save as PDF..." from the print dialog on OSX. The border of the div takes up the entire page when printing without "Print Selection Only" enabled, but as shown here, if the option is turned on, the height is way less.
Comment 3•11 years ago
|
||
The behavior-difference there happens because in print-selection, we don't have a containing-block-height to resolve our "height: 100%" values against (because we're just printing to an as-tall-as-it-needs-to-be container) So the "100%" ends up being treated as "auto" -- that's how percent-heights behave when they don't have anything to resolve against. (If you replace those 100% values with "auto", you'll see what I mean, in a normal print job.)
Comment 4•11 years ago
|
||
(In reply to Julian Viereck from comment #1) > He pointed out "we probably need to first figure out why print-selection > isn't working _at all_ for PDF.js". FWIW, it might be worth dedicating a bug *just to this part* (whether that's this bug, re-purposed to be about rendering, or another bug). It feels a little weird to be diagnosing rendering issues in a bug on "avoid high memory usage". :)
Reporter | ||
Comment 5•11 years ago
|
||
Renaming bug and opening new bug that is really about high memory usage.
No longer depends on: 830278
Summary: Avoid high memory usage when printing with canvas.printCallbacks → Print output is different depending on text-selection on/off
Reporter | ||
Comment 6•11 years ago
|
||
From a private email chat with :dholbert : > So -- I think the rendering difference is just a result of the way we do print-selection -- we initially print to an infinitely-tall page, which means percent-heights don't have anything to resolve against. That's just the way things work, with our current (imperfect) print-selection design. > > I'm not sure we can "fix" that behavior without completely rewriting the print-selection code. :-/ That's not to say we shouldn't do that at some point, but it'd likely be a large undertaking, and probably isn't likely to be prioritized soon.
Comment 8•11 years ago
|
||
(Clarifying the bug summary to cover what the testcases here demonstrate)
Summary: Print output is different depending on text-selection on/off → Print selection doesn't honor percent heights (because it doesn't have anything to resolve them against)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•