Point text sizes when printing

[Jeff Davidson]

Hi,

Our app has some printing logic where the goal is to print various elements of text at specific point sizes. Since point sizes are an absolute unit, the print result should look about the same regardless of screen resolution, platform, etc. However, on my Mac, when printing and selecting the "Save as PDF" option, the fonts have all gotten smaller in the printout after upgrading from wxWidgets 3.1.0 to 3.1.2 - well smaller than the size in points of the font passed to the scaled wxDC - and I'm working to understand why. It seems related to the screen density being made more accurate in https://github.com/wxWidgets/wxWidgets/commit/e2a846e1822f1104f8b083638c30206827ef7480, since if I ignore that change and just pretend the screen DPI is 72 dpi again, the printout looks close to what it was before.

I'm starting by looking at the printing sample. But depending on my active screen resolution, the text size throughout the PDF changes. Using the default resolution on a Retina display, the DPI is 114. If I use a higher resolution, the DPI becomes 227. But everything else seems to behave the same as before, so as a result, the text is all scaled down. Absolute measurements (like the stretched image on the first page and the 5cm line on the second page) seem to be consistent.

Is it expected for the sample printout to change text sizes depending on the input screen resolution? If so, is there some way of drawing text when printing such that it is drawn at a fixed point size regardless of screen resolution?

Thanks,

Jeff

[Vadim Zeitlin]

On Sun, 25 Aug 2019 08:05:38 -0700 Jeff Davidson wrote:

JD> Our app has some printing logic where the goal is to print various elements
JD> of text at specific point sizes.

I have to admit that this seems pretty reasonable...

JD> Since point sizes are an absolute unit, the print result should look
JD> about the same regardless of screen resolution, platform, etc. However,
JD> on my Mac, when printing and selecting the "Save as PDF" option, the
JD> fonts have all gotten smaller in the printout after upgrading from
JD> wxWidgets 3.1.0 to 3.1.2 - well smaller than the size in points of the
JD> font passed to the scaled wxDC - and I'm working to understand why. It
JD> seems related to the screen density being made more accurate in
JD> https://github.com/wxWidgets/wxWidgets/commit/e2a846e1822f1104f8b083638c30206827ef7480,
JD> since if I ignore that change and just pretend the screen DPI is 72 dpi
JD> again, the printout looks close to what it was before.

The fact that the size of the font in the printout has changed is most
definitely a bug, but I don't think it would be correct to fix it by
reverting the commit above, as it seems like a step in the right direction,
especially if the new DPI values (114 and 227 mentioned below) are correct.
My guess would be that there is another hard-coded 72 somewhere else, which
needs to be adjusted to match the real API, but I don't see where could it
happen. The hardcoded printer DPI in the same file seems suspicious, but at
least for PDF output, it is the right value to use, so it's probably not
the cause of the problem.

JD> I'm starting by looking at the printing sample. But depending on my active
JD> screen resolution, the text size throughout the PDF changes. Using the
JD> default resolution on a Retina display, the DPI is 114. If I use a higher
JD> resolution, the DPI becomes 227. But everything else seems to behave the
JD> same as before, so as a result, the text is all scaled down. Absolute
JD> measurements (like the stretched image on the first page and the 5cm line
JD> on the second page) seem to be consistent.
JD>
JD> Is it expected for the sample printout to change text sizes depending on
JD> the input screen resolution?

No, this is a bug. The trouble is that I don't have a Mac with high DPI
display, so it's not that simple for me to debug this (I don't think there
is any way to tweak the DPI being used under Mac, similar to GDK_SCALE
hack, is there?). I'll try to do it, of course, and check what's going on
in the printing sample. If you'd like to ensure that I won't forget about
it, please open a Trac ticket with 3.1.3 milestone for this.

Of course, if you're brave enough to try debugging this yourself, any help
would be very welcome -- I'm not more qualified for debugging this than
just about anybody else, as I don't know anything about how is printing
implemented under Mac.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Jeff Davidson]

Filed a Trac ticket: http://trac.wxwidgets.org/ticket/18475. Thanks!