Re: patch -- fix resolution in pango (win32 backend)
- From: Tor Lillqvist <tml iki fi>
- To: Joaquín Cuenca Abela <cuenca pacaterie u-psud fr>
- Cc: Owen Taylor <otaylor redhat com>, gtk-i18n-list gnome org
- Subject: Re: patch -- fix resolution in pango (win32 backend)
- Date: Mon, 20 May 2002 03:31:58 +0300 (FLE Daylight Time)
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
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
] [Thread Prev