Vincent Povirk madewokherd@gmail.com wrote:
OK, this is starting to make sense to me. If I'm understanding this, the point of your series is that the font has a consistent size based on the unit stored in the font. If it's a physical unit like inches then the font's size in world coordinates changes based on the graphics page unit, so that it maintains the same physical size. Since GdipMeasureString reports world coordinates you see the measurement change while the pixel size should stay the same based on the device dpi.
Points, inches, meters and the like are logical units, pixel is the physical unit measure. Logical units always map to the same distance on the physical device, which uses pixels internally eventually. Using this terminology helps to avoid confusion and correlates with gdi32 APIs LPtoDP/DPtoLP.
Since get_font_hfont is applying the page transformation to font sizes, we are still scaling our fonts based on the graphics page unit, when your tests show that in at least some cases we shouldn't be. I think what you've actually done is cancel out the convert_unit() factor that get_font_hfont had applied, by changing the measurement, and I don't think that's right. The pixel size should always relate to the world size based on the transform used by GdipTransformPoints. It's the pixel size that needs to change, not the relationship between pixel size and result.
convert_unit() is a very poorly named helper, and its meening and behaviour has changed in time it seems. convert_unit() needs to be removed completely, and conversion between pixels and device/font units should be generalized.
For instance setting device unit to millimeters with GdipSetPageUnit() and then calling GdipDrawImageI() leads to completely wrong results because down in the path there is huge confusion between device units, source coordinates units and device/world transforms applied to both of them using only device X resolution and completely ignoring image resolution. What a mess.