PDA

View Full Version : Recompiling from Mac to Win changes apparent font size



mchome
7th July 2012, 16:44
I've created a program with QT creator 2.4.1 based on Qt 4.7.4 in a Mac.
I used Lucida Grande Font that is the pre-defined one in Mac.
When I recompile the program Win7, however, its appearance is much worse a lot since all text is much larger. I see that fonts are indeed converted into MS Shell; even though they maintain the same numerical value of point size, the final result is quite different.

Does anyone know why, for instance, a 11 pts Lucida Grande txt in Mac, once in Windows is converted into a 11 pts MS Shell Dlg 2 text appears to be so larger?
Does anyone know a systematic way to force the appearance of widget text under Mac and Win to be as near as possible to each other?

Thanks a lot.

ChrisW67
9th July 2012, 00:05
It could be a number of different factors:

Mismatches between the assumed pixel density and actual pixel density of the display that different from OS to OS, and even between Windows versions.
The Windows Display Scaling "feature" which is on by default on smaller displays.
Perceived, but not necessarily real, differences brought about by different font shapes.


You can set the font size in pixels rather than points (but that has its own problems).
You can ensure Display Scaling is off when doing the comparison.
You can use a common font rather than relying on the OS default.
You can ensure you are using the Qt UI layout facilities so that font size changes do not automatically break your UI.

chriskon149
9th July 2012, 04:35
I have the same problem when using the default fonts. To fix it, I just use the layouts that Qt offers so that the UI doesn't break (just as ChrisW67 suggests). It works great!

Chris

mchome
10th July 2012, 19:23
There is more than just font conversion in this issue.
I enclose two pictures. Both are created using the same C++ code.
Widgets' text is Arial (e.g. "Plot" botton text is Arial 13)

The text label on the axes in the plot area are Times 10 and written by painter commands:
painter->setFont(QFont("Times",10));
and then
painter->drawText(x,y,text);

79797980

the user areas of the two windows is the same. Moreover the pixel size of the area devoted to the sinusoidal plots is the same. But the size of the number on the axes are not the same!

ChrisW67
11th July 2012, 00:05
Have you ensured that Windows 7 Display Scaling is turned off?

mchome
11th July 2012, 20:37
If by display scaling you mean text scaling, it is off (i.e. 100%-96dpi).
If you mean some different setting, please, tell me more on how to verify.

However, any proportional display scaling cannot be active, since the whole window (excluding the border, larger for win7) has the same size in the two OS's.

wysota
11th July 2012, 22:50
Based on the images attached it seems to me you are not using widget layouts. If you do that, you won't have to worry about the font size changes. Otherwise you'll application will fall apart on a first system installation that has a different default font size than you do.

mchome
12th July 2012, 22:39
Indeed I didn't use layouts since this is a program I use to test a plotting program core that I will later insert in an application with a much lower number of widgets, that I will create using layouts.
This discussion has made even cleaner that layouts are pretty mandatory for widgets in Qt.

However layouts do not manage text written directly using painters. And I found differences in the displayed size of the text on the axes, that was written using a painter. This is rather strange indeed.

As for my application, the conclusion is:
1) in the final program widgets will have to be put on the window by means of layouts
2) the following code enhances text on the axes:
fontsize= [...];
#if defined(Q_OS_MAC)
fontSize+=1;
#endif
painter->setFont(QFont("Times",fontSize));
painter->drawText(x,y,text);

However it is unclear why this OS-specific font enlargement is needed.

wysota
12th July 2012, 23:06
Indeed I didn't use layouts since this is a program I use to test a plotting program core that I will later insert in an application with a much lower number of widgets, that I will create using layouts.
This discussion has made even cleaner that layouts are pretty mandatory for widgets in Qt.
Indeed they are.


However layouts do not manage text written directly using painters.
That's a responsibility of your widget. sizeHint() has to be implemented accordingly.


However it is unclear why this OS-specific font enlargement is needed.
I really wouldn't do that if I were you. Enlarge your system font and see if a static +1 in font size still looks good. Then reduce the font significantly and check if +1 is ok again. I doubt they will be. +1 looks good on your system.

mchome
13th July 2012, 19:46
Making a +1 is very rough, and is a consequence of the fact that I was not able to understand the rationale behind the smaller appearance of characters (having the same name and the same point size) in Mac systems.
Another option could be to multiply by 1.1 the size.

The idea behind +1 is that I want the correction to be very small, and to influence by a significant amount only the smaller fonts.
Indeed the text fontSize on my axes is chosen as a function of the plot size (that's why I wrote [...] when I earlier discussed the fontSize definition)
For larger plot sizes I could have up to 16 points fonts, for which +1 impacts nearly negligibly.

I would have been much happier if no correction were needed. Once I understand why in Mac the same fonts (same name, same points) imply smaller actual characters, maybe I will not need any correction anymore.

ChrisW67
14th July 2012, 00:34
A 12 point font is supposed to be 12/72 inches "tall" but in digital typography that is a somewhat vague concept: the height of the virtual grid onto which the character is drawn. The characters of different fonts might occupy different amounts of that grid so a 12pt Courier and 12 pt Times may appear to be different sizes on the same system despite the virtual grid having the same height.

To arrive at a 12/72" high virtual grid on screen or paper the rendering software needs to know the actual pixel density of the device (dots per inch, DPI). Once that is known the number of device pixels needed to obtain the desired height is calculable. If the device reports accurate DPI figures, and the renderer takes heed, then the result should be close to an accurate physical height for the virtual grid (Some variation comes from rounding to whole pixels).

Windows, until recently, assumed all screens were 96 dots-per-inch regardless of whether the device reported its actual dimensions. Consequently a 12pt font is drawn on a virtual grid 16 pixels high regardless of how high that appears on screen. With the display scaling "feature" in play that assumption can be changed (120 or 144 DPI are the other fixed options) resulting in larger physical display of fonts of the same point size.

As I understand it, X11 has always taken actual display DPI into consideration but until recent years has not had a very reliable report on the actual device DPI and would often be configured with bitmap fonts for 75 or 100 DPI before scalable fonts were readily available. Mac, historically on very controlled hardware or only using recent devices, has always had the pleasure of an actual device DPI and produces fonts of close to the expected physical size.

Consequently 12pt Arial on Windows, X11, and Mac displayed on the same monitor may be different physical sizes on screen.