Fundamental misunderstanding in Windows graphics class.

From: Martin Sevior (
Date: Sun Sep 07 2003 - 23:53:00 EDT

  • Next message: Pierre Abbat: "Re: How to make a po file from a strings file?"

    Hi Folks,
             I've finally realized that there is a fundamental
    misunderstanding at the root of the windows graphics bugs.

    It's this.

    Logical units are 1440 dpi. Font and character widths are always
    calculated with 1440 dpi fonts.

    Having calculated the withs at 1440 dpi, they are scaled to the current
    device resolution.

    If you look in the GR_Win32Graphics class you see code like this.

    UT_uint32 GR_Win32Graphics::getFontAscent()
            return tlu( GR_Win32Font::Acq::getAscent(*m_pFont) );

    So the font m_pFont which is whatever the current font size is is used
    to calculate the font width. The problem with this is that rounding
    errors get us as we zoom or when we print.

    Fonts are only presented at integral sizes 12,13,14,15,etc.

    It is easy to imagine a zoom that would say the font should be size 13.6

    But if we use either 13 or 14 to calculate the character widths, we will
    get a result that is not consistent.

    The solution Dom and Pat put together is that all character properties
    are calculated with the font size set to...


    (which is set to 120)

    These properties are what is returned to the graphics class.

    m_pFont should be always set to the size given by

    the then getguiFont returns the currently scaled font.

    So the code above should be:

    UT_uint32 GR_Win32Graphics::getFontAscent()
            return GR_Win32Font::Acq::getAscent(*m_pFont);

    Because m_pFont is always of size 120...

    Do the win guys get it? Can it be fixed? I still barely understand how
    the windows graphics class works. But that code struck me as
    fundamentally wrong.


    This archive was generated by hypermail 2.1.4 : Sun Sep 07 2003 - 23:03:46 EDT