Rendered font size in native GraphicsContext backend (GDI+) in Windows

In the 2.9 GraphicsContext demo it is possible to switch between using the native backend, (GDI+ on Windows) and Cairo - by editing ‘if False’ to ‘if True’ on line 63. The two screenshots attached show that the same text rendered using GDI+ is about 25% larger than using Cairo. There is no difference when using the CoreGraphics backend on OS X.

I first came across this when developing my PDFViewer (also in the demo) and added a font scaling factor (Points per inch / Screen pixels per inch) to compensate. However, this doesn’t quite work because, when applied to the required font, the point size rounds down to the nearest whole number. For example, a point size of 10 * 0.75 becomes 7. This, as Michael Hipp has recently reported, leads to text alignment problems with things like columns of numbers where the original document contains text starting co-ordinates that have been calculated from a right or decimal alignment using the actual text size.

So, can this be classed as a bug and, if so, is it likely there could be a fix for it?

GraphicsContextDemo-Cairo.png

GraphicsContextDemo-GDI.png

···


Regards,

David Hughes
Forestfield Software

In the 2.9 GraphicsContext demo it is possible to switch between using
the native backend, (GDI+ on Windows) and Cairo - by editing 'if False'
to 'if True' on line 63. The two screenshots attached show that the same
text rendered using GDI+ is about 25% larger than using Cairo. There is
no difference when using the CoreGraphics backend on OS X.

I first came across this when developing my PDFViewer (also in the demo)
and added a font scaling factor (Points per inch / Screen pixels per
inch) to compensate. However, this doesn't quite work because, when
applied to the required font, the point size rounds down to the nearest
whole number. For example, a point size of 10 * 0.75 becomes 7. This, as
Michael Hipp has recently reported, leads to text alignment problems
with things like columns of numbers where the original document contains
text starting co-ordinates that have been calculated from a right or
decimal alignment using the actual text size.

So, can this be classed as a bug and,

I would think so, but the answer you might get is that it is just due to differences between how Cairo and GDI+ convert points to pixels, or something like that.

The inability to have floating-point point sizes is a separate issue, and one that I think people would like to solve, at least for use with wxGraphicsContext. I don't yet know of any plans to do so however.

if so, is it likely there could be
a fix for it?

Perhaps. It's worth submitting a ticket to find out anyway.

···

On 2/27/12 2:00 AM, David Hughes wrote:

--
Robin Dunn
Software Craftsman