Open Bug 646314 Opened 13 years ago Updated 2 years ago

unstyled form elements print bloated, & more so as actual desktop/system DPI deviates from 96

Categories

(Core :: Printing: Output, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: mrmazda, Unassigned)

References

Details

Attachments

(1 file)

At actual 96 desktop DPI, printing differs little among rv1.8.1, rv1.9.2 & rv2.0, as does screen display generally, except WRT form elements. When printed without author styling, form elements mushroom in size compared to their surroundings. With actual desktop DPI of e.g. 120 (125% or 96) or 144 (150% of 96), the size disparity grows in proportion to the DPI deviation from 96.

To reproduce:
1-ensure desktop DPI set to 96
2-open rv1.9.x or higher with a virgin profile, or with default fonts reset to OEM values
3-print a page containing unstyled form elements
4-close browser
5-reset DTE to some higher DPI, e.g. 120 or 144
6-raise browser's default font sizes in same proportion as DPI was raised, e.g, from 16 to 20 for 120 DPI, or to 24 for 144
7-print a page containing unstyled form elements

Actual results:
1-printouts at 96 DTE DPI seem reasonable except for large form elements
2-printouts above 96 DTE DPI seem reasonable except for even larger form elements
3-paper waste

Expected results:
1-printouts at any DTE DPI have form elements printed in same proportion to text size as displayed on screen, similar to rv1.8.x
You're right. The dropdown menu, input field and buttons are not scaled along with the rest. I expect this is because they're supplied by the UI (in my case GTK+) and will always be rendered according to the system DPI (120 in my case).

I patched my Firefox to scale stuff according to layout.css.dpi and it's clearly visible that this has no effect on those elements.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: