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

[Joaquín Cuenca Abela <cuenca pacaterie u-psud fr>]

On Mon, 2002-05-20 at 02:31, Tor Lillqvist wrote:
> 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.

Yup, you're right.  I missed it.  I've done a grep for lfHeight, and
besides from pango_win32_make_matching_logfont, it's only used in
logfont_hash (pangowin32-fontcache.c:94).

So you should also change

pangowin32-fontmap.c:891

  int font_size = tmp_logfont->lfHeight;
by
  int font_size = -tmp_logfont->lfHeight;

pangowin32-fontcache.c:94
    lfp->lfWeight/10 +
    lfp->lfOrientation +
    lfp->lfHeight * 10;
by
    lfp->lfWeight/10 +
    lfp->lfOrientation -
    lfp->lfHeight * 10;

If you want a real patch, just ask for it.

>  > 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?

when you render text in a printer, you want a point to be 1/72.0
inches.  If you try to do the same thing in the screen, you finish with
text that it's hard to read (look at X11 :), because a screen don't have
the same resolution than a printer (even the worst printers have at
least a 300dpi resolution...)

With your calculation, you finish having in the screen text that has the
same physical size as if it have been printed (assuming that windows is
giving you the right value for HORZSIZE), but the text is only barely
readable.

>  > 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.

Not exactly.  X11 uses by default a resolution of 75dpi for fonts.  I
think that it comes from Apple, who did the same thing in Macintosh,
presumably to make a typographical point be a pixel on screen (or maybe
just because it was a typical resolution at that time).

btw that's just an approximation, if you want a typographical point be a
pixel, you need 72dpi, so if you request big sizes you don't get anymore
the 1 typographical point = 1 pixel

And anyway, in X11 you can have different resolutions for fonts, for
instance, changing the size of your screen in your configuration to
match your prefered dpi.  I think that xft can also be configured to use
a different resolution for text.

So if a X11 app is using 1 typographical point = 1 pixel, then this app
is broken (even in X11).

> 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.

oh, no.  Imagine that you have a 50" monitor that you want to use for
conferences, and that you have windows returning you the right size of
your monitor.

Now, imagine that you have this monitor with a resolution of only
1024x768 pixels.  You can run with this resolution your apps (who will
still use the same pixels as in your usual monitor) and the users will
see them ok because they're far from the screen (ie, the angular size is
the same for people seeing the big monitor, and for people seeing a
normal monitor).

But, applications that use pango will then try to draw text using the
real resolution of the screen, so in the big monitor pango will render a
text of 12points with a height of 4 pixels!!

Your presentation that looked wonderful in your little screen has just
been screwed in your conference.

> 
>  > 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.

ok, no problem here with me.

There are several articles in msdn devoted to this issue.  I think that
there's also a book chapter that explains all that stuff (something as
"The logical font").

Maybe you will also find something in the doc about LOGFONT.

If something is not clear, please just ask.  It's a convoluted issue,
and my english doesn't allows for very clear explanations, but I will do
my best.

Cheers,

-- 
Joaquín Cuenca Abela
cuenca pacaterie u-psud fr