Closed Bug 106083 Opened 23 years ago Closed 17 years ago

Changing screen DPI changes size of print fonts

Categories

(Core :: Printing: Output, defect, P2)

Product:
Core
Component:
Printing: Output
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: dsmith, Assigned: dcone)

References

(Blocks 1 open bug)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011019
BuildID:    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011019

The size of the fonts in printed output varies with the screen dpi setting.

Reproducible: Always
Steps to Reproduce:
1. set dpi to some value
2. print whatever
3. set dpi to something different
4. print whatever again
5. compare

Actual Results:  It appears as if the screen dpi is being used by the print system.

Expected Results:  I would expect the font size of printed output to be
indepedant of the screen settings.

Using a dpi of 96 looks good for printing.  A setting of 128 (what my screen dpi
really is) makes the printed fonts very very small.  Something like a 5 point or
something.
Boris, any ideas on this one?
No.  I once tried to sort out the print flow of control and decided that it's a
morass of interfaces...

See also bug 103145, though (similar problem there).
confirming, because otherwise this'll never get looked at by someone in a 
position to actually resolve it one way or another.
Blocks: 103145
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Target Milestone: --- → mozilla1.1
Ok.  So the problem is that we seem to be trying to make things the same
physical size on the printed page and on the screen.... so a higher screen DPI
means a smaller printed size for things measured in px.

The question, of course, is why we're doing fonts in px...
Assignee: dcone → rods
Summary: chnaging screen dpi changes size of print fonts → Changing screen DPI changes size of print fonts
Target Milestone: mozilla1.1alpha → mozilla1.1beta
-->
Assignee: rods → dcone
Target Milestone: mozilla1.1beta → ---
This is definitely related to bug 103145.  At least for Postscript output, the
screen DPI setting is used to scale not only fonts, but also images.  (Does this
occur on other platforms such as Windows, or is it specific to the Postscript
output driver?)

This behavior is nonsensical.  If you replace your monitor with another monitor
that has different DPI settings, and update your settings accordingly, why
should your printouts suddenly change?  Your printer's paper hasn't changed size!

If there should be a DPI setting to be used for printing (and maybe there
should), it should be separate from the screen DPI setting, since they're
independent output devices.  Certainly, whatever the scaling behavior, it ought
to be consistent on any printing subsystem.

By default, the printout should probably scale to fit the page, since there's no
such thing as a scrollbar on a printout.  I can't count the number of pages I've
had to reprint under Netscape 4.x because a table was N pixels wide and it was
scaled so that the right edge of the table was cut off.  This often makes long
sections of unreadable text, with (for example) 10 words visible and 4 words
missing on every line of the text...  (Is there a separate bug already filed for
this specific problem?)

I suppose I could set my screen DPI setting to try to work around this problem,
but I shouldn't have to, and it would be using this bug to work around that one.
 The right solution to both problems is to have intelligent auto-scaling.

Note: Even if the web page specifies a 1000-pixel-wide table, that doesn't mean
that scaling it to fit the page necessarily means scaling the fonts smaller --
images would need to be scaled, but font size could be (and probably should be)
independent of the scaling of pixel-based sizes.  In principle, Gecko should be
able to format printer output at least as well as screen output, but it doesn't
seem to happen in practice...
Priority: -- → P2
Target Milestone: --- → Future
Blocks: 125824
What about simply hardcoding the DPI we use for the gfx card to 90 DPI (setable
via prefs, "0" means: use gfx card's real DPI), e.g. instead of |scaler =
printer_dpi / gfx_card_dpi| we could use |scaler = printer_dpi / 90.0| to work
around the problem ?
Um... so to fix a fuck-up in printing you want to break screen rendering?  No,
thank you.

Perhaps a better question to ask is why scaling is needed at all.  Shouldn't
things just work if printing reports the correct conversion between px and twips?

More to the point, why are we trying to make the printed layout exactly match
the screen layout instead of going for the best possible print layout?

ccing roc, since his proposed units changes cover some of this territory...
bzbarsky wrote:
> Um... so to fix a fuck-up in printing you want to break screen rendering?  No,
> thank you.

Erm, you (likely) misunderstood me... ;-/
I do _not_ want to adjust the main display DPI, I only want to adjust the DPI
value used as parameter to calculate the scaler for the print device context.
Only at that point, only affecting the print device context and _not_ doing any
harm to the main display.

Oh, I see what you mean.  So in printing you would just divide by some random
hardcoded/preffed number instead of dividing by the real screen dpi.  Gotcha. 
Yeah, that would indeed be a workaround....

The question remains.  Why is that dividing necessary at all?
Boris Zbarsky wrote:
> Oh, I see what you mean.  So in printing you would just divide by some random
> hardcoded/preffed number

prefs, please. Setable via prefs _and_ a magic value(="0") to restore the
original behaviour if something else goes wrong.
and: random="90" for now... we can always adjust the prefs... :)

> instead of dividing by the real screen dpi.  Gotcha. 
> Yeah, that would indeed be a workaround....
>
> The question remains.  Why is that dividing necessary at all?

Different device resolution... we do all calculations for the main display - and
then we simply scale-up everything to match the printers resolution(=hack) ... I
do not remember who started with that idea but AFAIK everyone copied that part 
into the other print modules without asking about the "why?" ... ;-/
> we do all calculations for the main display

That's what this bug is about.  We should _NOT_ be doing that.  Wallpapering it
is not the right answer.
Boris Zbarsky wrote:
> > we do all calculations for the main display
>
> That's what this bug is about.  We should _NOT_ be doing that.  Wallpapering 
> it is not the right answer.

I agree with you. I only answered your question. No need to kill the
messenger... :)
This is all covered by the units bug. Implement my units plan and this will go away.
Adding dependency on Bug 177805 (Units bug).
Depends on: pixels
Robert O'Callahan wrote:
> This is all covered by the units bug. Implement my units plan and this will go 
> away.

... or makes or more worse... =:-)

jkeiser:
How would you solve this issue with your "new world for printing" assuming we
would _not_ fix bug 177805 ("Units bug") first [this is a theoretical question,
please do not beat me] ?
"Wall papering is not the answer". I have to agree. I've been trying to figure
out for months why after Mozilla 1.3 all my forms that use a print specific css
to set a monospace 8pt font are now garbage. No matter how you get there if you
can't support css media=print I'm forced to use older Mozilla, Netscape browsers
or m$IE. Tried out Firebird. Like it. Hope they don't break it there too.
*** Bug 221717 has been marked as a duplicate of this bug. ***
I wonder if this is the cause of Bug #209492 where mail messages are printing
out too large.
*** Bug 280091 has been marked as a duplicate of this bug. ***
Blocks: 280091
Was this fixed by the patch in bug 177805?
Mass-resolving some bugs related to the old Linux/Unix printing code. The old code has been removed from the tree, and the bugs are all FIXED by the new cairo-based printing system.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.