[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    Bug#35119: Font size depends on X server DPI value
From:       Linus Torvalds <torvalds () transmeta ! com>
Date:       2001-11-30 21:18:14
[Download RAW message or body]


On Fri, 30 Nov 2001, David Faure wrote:
>
> Interesting.
> Or simply
> echo 'Xft.dpi:300' | xrdb -merge

Yes.

> > Maybe kword gets upset when Xft uses a DPI value of 300, while the X
> > server DPI query returns 75. Basically kword should only care about the
> > Xft-reported size, methinks.
>
> I can't agree here.
> First, KWord isn't tied to Xft.

I think we actually agree.

What I meant is that kword really shouldn't care about the X server DPI
value, but simply care about the proper font metrics - regardless of where
those metrics come from (ie Xft or anywhere else).

So the fundamental question in any WYSIWYG is always "what are the metrics
of this object (font/graph/xxxx) in the physical world". And here the X
server DPI setting simply doesn't matter - the size of the object is
inherent in the object itself, not in anything else.

If you mix in "visual DPI" settings into this too early, you're _always_
going to get the wrong answer. The visual DPI (whether on a printer, on
the screen, or on any other medium) simply has no _meaning_ for the
document itself - if you want the document to be truely independent of
medium.

The issue of what _size_ to show on the screen is then completely separate
one. That's when the X server DPI value can come in, but I will bet you $5
that 99.9% of all your users never put their paper up to the screen to see
if it printed out the same size as it showed on the screen.

Printing out the same size as it shows on the screen is _meaningless_.
Every single person I know will have "physically bigger" text on their
screen, simply because their screen is not 300 dpi, so in order to see
small text legibly you do not WANT to try to make the physical size on the
screen have anything to do with the physical size of the paper.

The only thing you care about is really that the _relative_ sizes on the
screen between the "virtual A4" you write on, and the actual size of the
text you write is the same.

Then, for "preview" mode, you may want to try to match actual physical
sizes, but even then I bet that 99% of all people will just want to see
the whole page inside the window - not caring about the size, but caring
about the fact that exactly _because_ they want to work with a expanded
view of their document, they seldom see the whole page on the screen.

> Also, I don't see why the user should have to set the Xft DPI resource,
> instead of parametring his X server correctly, if necessary.

This is because the X server DPI setting is hard. There are no good ways
to automatically set the DPI for a screen - all current methods just suck.
The only reliable method is a command line option, otherwise you'll get
random values depending on whether your monitor supports DDC or not, or on
which version of the X server you are running, or on what graphics card
you have (not all cards do DDC, either in hardware or simply in the X
driver).

That means that in 99% of all real-world cases, the DPI value reported by
the X server is total and utter crap, _and_ you cannot set it sanely in a
configuration file.

So having a Xft.dpi value that you _can_ set, and then ignore the X server
DPI value is the next best option, as the Xft developers found out.

Also, there's a long and boring argument (that I've already had with
Keith), where my standpoint is that nobody cares about "physical DPI", and
that the only thing that really matters is not how many dots per _inch_,
but how many dots per _arc_ you have visually. Ie how big do the dots
_appear_ to your eyes, not how big are they physically.

A 63" projection TV display has _huge_ pixels, but to offset it you sit
further away from it than you would from a small 14" portable TV. So
_visually_ they actually have comparable DPI, and thinking that the
"physical size" of the picture matters is pure and utter stupidity.

Do you think your TV should shrink the picture so that it would look the
same on a 63" display as on a 14" TV? That's "WYSIWYG". But it's stupid,
and everybody _realizes_ that it is stupid.

For some reason, when you talk about monitors instead of TV's, people
don't realize that it is stupid to care about the physical size of the
monitor. I ahve a nice 21" TFT LCD display, and I have it further away
than I had my old 17" display. Visually, the DPI values of the two
monitors would be exactly the same, except I also have higher resolution
on my 21" monitor (1600x1200 as contrasted to my old 1280x1024).

It turns out that the _visual_ DPI has nothing to do with physical size of
the monitor, but with the _resolution_ of the monitor. A 63" projection TV
has the same basic resolution as a 14" TV, modulo some small visual
artifacts like line doubling and comb filtering that improve on the
perceived image.

> However, I would like to point you to this page, about the question "why honour
> the DPI setting at all, i.e. why care about the size of things on screen".
> Please check the last paragraph from:
>  http://www.freetype.org/freetype2/docs/glyphs/glyphs-5.html

That has nothing to do with the physical size of the image shown on the
screen: that least sentence only says that the absolute _physical_ size of
the objects has to be fixed. But you have to realize that physical size
only matters once printed out on a physical medium - when it's on the
screen, you're working on the virtual zoomed-in representation of the
image, not onf the "physical medium".

As mentioned, you may have a special "preview" mode, where you can try to
match up the actual physical screen size, but as also mentioned, you (a)
can never get it to work reliably because the size isn't reliably reported
anyway and (b) nobody really cares.

> My take was that, for the ones who don't care about it, it's no problem if it matches
> the real size of things or not, so by respecting the X server DPI value I assumed
> everyone would be happy, those who care about it and those who don't ;-)

Trust me, the Xft people initially thought the same. They've noticed
differently in the real world, and realize that the visual size is what
matters. Which is why Xft.dpi is there, and which is why future X servers
will probably default to a resolution-based default DPI.

Remember: people who care about the same physical size can (and do) just
zoom in/out of the view until the size of the paper on the screen matches
the size of the paper they print out.

		Linus

[prev in list] [next in list] [prev in thread] [next in thread]