From: Martin Sevior (firstname.lastname@example.org)
Date: Sun Sep 07 2003 - 23:53:00 EDT
I've finally realized that there is a fundamental
misunderstanding at the root of the windows graphics bugs.
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
If you look in the GR_Win32Graphics class you see code like this.
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:
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
This archive was generated by hypermail 2.1.4 : Sun Sep 07 2003 - 23:03:46 EDT