Le Samedi 26 Août 2006 20:33, Lubos Lunak a écrit :
> Dne sobota 26 srpen 2006 15:21 Germain Garand napsal(a):
> > Le Vendredi 25 Août 2006 16:47, Lubos Lunak a écrit :
> > >  Hello,
> > >
> > >  this is basically http://bugs.kde.org/show_bug.cgi?id=111754 for the
> > > 3.5.x branch. Or just google for things like 'kde gnome fonts dpi' to
> > > get more info about the issue, like
> > > http://process-of-elimination.net/wiki/Control_Font_DPI_in_X . In
> > > short, most fonts are designed only for 96DPI and 120DPI and look
> > > horribly with other DPIs. Since X by default computes real DPI and we
> > > just use it, while GNOME forces it to 96DPI, we get a lot of "KDE has
> > > ugly fonts", despite us doing things "properly". Go figure.
> > >
> > >  The patch adds a combobox allowing to force DPI this way, but it still
> > > defaults to real DPI.
> >
> > As a side note, if KDE is to officially support this broken concept of
> > having different DPIs for the display and for the font server, we need to
> > document that and start fixing our applications to make that distinction
> > as well.
>
>  Well it's not like users can't force a different DPI value themselves :-/.
> I think e.g. running gnome-settings-daemon in KDE does that.

I heard it does.. and some distributors add their own fixed Xft.dpi value in 
Xresources files.

>
>  But the option is meant rather as a hack, and it intentionally defaults to
> the real DPI (it works just fine for me with Microsoft TTF fonts). Perhaps
> it should even say that the option is not recommended, but with all those
> people saying that our fonts handling sucks just because their fonts suck
> :( ...
>

right... now if a user with an already tweaked Xft.dpi simply modifies some 
other font options, isn't the patch going to remove that tweak by default? is 
this intended?

> > with Qt, I think one needs to use heightMM() instead of logicalDpiY() to
> > be guaranteed (is that right? are there other ways?) to derive the
> > display's real DPI (and then these methods' documentation should be
> > updated to state that the situation on X is now as broken as on Windows!)
>
>  I'm afraid I have no idea about this stuff.

anyway, I just verified that on a 140 dpi laptop, with 
  -X properly configured to 140x140dpi
  -Xft.dpi forced to 90:

given a QPaintDeviceMetrics p (a QPaintDevice in Qt4),

p->height()/(p->heightMM()* 1/25.4) == 140
p->logicalDpiY() == 90

so one can at least take his pick according to the situation.

Germain