Re: patch -- fix resolution in pango (win32 backend)

[Tor Lillqvist <tml iki fi>]

Joaquín Cuenca Abela writes:
 > Sorry for the late reply.  I'm not having much free time lately...

Ditto here..., sigh, replying now to a message two weeks old.

 > 2a. out->lfHeight = (int)((double)size / win32fontmap->resolution + 0.5);

 > 2b. out->lfHeight = -(int)((double)size / win32fontmap->resolution + 0.5);

 > That's because negative and positive values for lfHeight have different
 > meanings.  A positive value for lfHeight means that you're specifying
 > the "height of the font + internal leading" (in short, the line
 > spacing).  A negative value means that you're specifying the "height of
 > the font" (once you take the absolute value, of course).

 > Here we're specifying the size of the font, so we should use the
 > negative value.

OK, I see, you probably are right. But shouldn't the code that uses
LOGFONT::lfHeight elsewhere then also be modified to use its absolute
value? Like earlier in the same function where the lfHeight field of a
existing LOGFONT (set up by this function earlier?) is compared to the
size passed to the function.

 > 1a. fontmap->resolution = (PANGO_SCALE * 72.27 / 25.4) * ((double) GetDeviceCaps (pango_win32_hdc, HORZSIZE) / (rect.right - rect.left));

 > 1b. fontmap->resolution = PANGO_SCALE / GetDeviceCaps(pango_win32_hdc, LOGPIXELSY) * 72.0;

 > The problem here is that in the screen you usually don't have enough
 > pixels to draw the text at the same size as in the printer, so your text
 > will have the right physical size in the screen, but it will be
 > unreadable.

Umm, what printer?

 > To solve this problem, windows invented the "logical resolution". 
 > Basically, the user says somewhere that he wants to draw its fonts using
 > a resolution of 96dpi (by default, people with high resolutions usually
 > use 120dpi), and windows should not care about the real "inches /
 > pixels" of the screen (in fact the "i" in 96 dpi is for "logical inch"
 > instead of a real inch).

 > That way, you get readable text at low resolutions, and your font
 > doesn't changes its size as you change your resolution.

Hmm. I don't really grok this "logical inch" business. (First time I
notice it now in the GetDeviceCaps documentation, and I can't do a
Google search for more docs now as my ISP's DNS seems to be borken.)
But consider that most GTK+ 2.0 programs presumably are originally
written for X11, and ported to Windows later (if ever). On X11, when
you ask for a font size in points, what you get is supposed to be a
font that really has that size, in points, on the screen. There
usually is a way tell X11 the actual physical size of your display
area. Maybe Windows can get the physical size from newish monitors
through some fancy plug-and-play protocol? Anyway, I do think that
Pango should try to get as close to the asked for size as it can.

 > There is here one more thing to do (not fixed by my patch).

 > The "resolution" value will convert the size variable in pixels, but
 > lfHeight is not expecting pixels, but a value in "logical units"
 > (nothing to do with the "logical resolution" or "logical inches").
 > 
 > The default mapping mode (MM_TEXT) uses 1 logical pixel = 1 pixel, so
 > (with my patch) you will get the right size for the font for hdcs using
 > MM_TEXT (and any mapping that keeps the 1 log. pixel = 1 real pixel),
 > but in the general case it will still be wrong.

I don't think there is a need to account for any non-MM_TEXT mapping
mode. Anybody who tries to use those with Pango and/or GDK gets what
they deserve. "logical unit == pixel" is pretty much assumed in
GDK/Win32.

--tml