FontUnits.Point<->Pixel (on OS X, Windows)

Targets
1

I assumed that on a display with ScaleFacor 1.0 (or in an App with no HiDPI support) FontUnits.Point and FontUnits.Pixel should be the same. Is this assumption correct?

It sure seems so on OS X.
A Label with FontUnit Default/Pixel/Point and TextSize=14 looks the same on a non-Retina-display.
A Label with FontUnit Default/Point and TextSize=14 looks the same on a non-Retina-display. With FontUnit.Pixel, FontSize=28 again the same “height/size”.

However, on Windows I always get different results, even with NoHiDPI-support enabled.
If I set the Controls to .TextUnit=Point, .TextSize=14 it always is bigger than .TextUnit=Pixel, .TextSize=14.

I guess the best approach to support HiDPI for both OS X and Windows is to set all the Control’s .TextSize with .TextUnit=Points.
Pixels is the worst solution, as with a ScaleFactor of 2.5 such as on a Notebook we have here all the Pixel-Values always need to be Scaled with that factor. Not to mention when the ScaleFactor changes (on multiple displays). With TextUnit=Point this should remain the “same” and be handled by the framework. Or am I wrong here?

So the question remains… How to figure ot the .TextSize-value for Windows?
Currently: .TextUnit=FontUnits.Default, .TextSize=14
New (1): .TextUnit=FontUnits.Pixel, .TextSize=14 (the same, but “wrong” for HiDPI-support)
New (2): .TextUnit=FontUnits.Point, .TextSize=14 (too big on Windows; the same on OS X)

I guess the workaround is to use a “scaling factor” for Windows. But hot to figure out that value?
factorWinPointVSPixel is certainly < 1 (because the same .TextSize is “too big” when using FontUnits.Point)
New (3): .TextUnit=FontUnits.Point, .TextSize=14 (the same on OS X)
#if TargetWin32 then … .TextSize=14 * factorWinPointVSPixel

So… does anyone know what is the “base” for “Point” on Windows? It certainly isn’t: Pixel * ScaleFactor What is the missing factor?

I also created a Feedback: <https://xojo.com/issue/43726> There are some ScreenShots attached which show this issue.
Maybe it would be best to have the same behavior on Windows: .Pixel is the same as .Point (on a display with ScaleFactor=1.0) ?

2

HiDPI is still in Beta on Windows. There are a number of things that are not working correctly yet.

3

@Greg O’Lone I’m aware of that.
The question/issue is also in a “no HiDPI world” (REAL Studio 2011r3; Windows 7; Monitor with ScaleFactor=1.0).
Even there I’m curious about why .Point=14 and .Pixel=14 is NOT the same on Windows, but is on OS X. And how to figure out the correct .TextSize on Windows (when using FontUnits.Point) to get the same (such as FontUnits.Default).

By how much (or what factor) is the FontUnit.Pixel smaller compared to FontUnit.Point (for the same .TextSize). or the other way around: how much is .Point bigger on windows (while it’s 1:1 on OS X). No HiDPI at all involved for this question/issue.

4

[quote=264348:@Jürg Otter]@Greg O’Lone I’m aware of that.
The question/issue is also in a “no HiDPI world” (REAL Studio 2011r3; Windows 7; Monitor with ScaleFactor=1.0).
Even there I’m curious about why .Point=14 and .Pixel=14 is NOT the same on Windows, but is on OS X. And how to figure out the correct .TextSize on Windows (when using FontUnits.Point) to get the same (such as FontUnits.Default).

By how much (or what factor) is the FontUnit.Pixel smaller compared to FontUnit.Point (for the same .TextSize). or the other way around: how much is .Point bigger on windows (while it’s 1:1 on OS X). No HiDPI at all involved for this question/issue.[/quote]

when you figure that out let me know… this is the exact technical reason I suspended work on my PDFClass… the measured font metrics were not consistent between OSX and Windows … I think someone told me (and I might be mistaken) that OSX used Point and Pixel interchangbly for fonts (ie. 1pt=1px), but that Windows did not… but if you search the forum you will find a discussion about this from about a year ago… where I documented the metrics OSX gave for a specific situation, and how WIndows gave totally different results. Some has to do with the installed font defintions, some with the way the fonts are rendered etc…

5

@Dave S Can you please post the link to that discussion? I tried to search, but haven’t found what you’ve been writing about.

6

Off the top of my head, I’d bet it’s off by the ratio of 3/4 or 4/3 depending on how you look at it. By default, Windows uses a base measurement system of 96 pixels per inch whereas OS X uses 72 pixels per inch. OTOH, Points is always measured as 72 ppi. Now that should mean that text defined in points is going to be larger than pixels because each unit is 1/96th of an inch vs 1/72nd.

7

Thanks Greg.

This info allows a switch to FontUnits.Point for Controls while continuing to use the same controlTextSize-values for both OS X and Windows.

Dim controlTextSize As Single = 14 (Control).TextUnit = FontUnits.Point (Control).TextSize = controlTextSize #if TargetWindows then (Control).TextSize = controlTextSize * (72 / 96) #endif

A question regarding HiDPI: What is the expected/designed behavior if no .TextUnit has been set explicitly (so that a Control uses FontUnits.Default)?
Setting/Switching the .TextSize of an instanciated Control on Windows:

(Control).TextSize = 14

In a “non HiDPI” App, this sets the same fontsize (such as FontUnits.Pixel, 14)?
In a “HiDPI-supported” App, this sets the “scaled” fontsize (such as FontUnits.Pixel, 14 * ScaleFactor)?
(on OS X, the Framework may set the .Point-Size regardless of Retina or not; but on Windows it is obviously is not quite right).

If yes, then I guess it is a “HiDPI-beta” issue that some subclassed Controls in our software render very small, but the same subclassed Controls look “the expected size” in other situations (while no FontUnit has been set at any time; so all are using the Default).

8

there is no magic multiplier that will give the same “answer” for a given font between Windows and OSX.

3/4 or 4/3 works for “some fonts” , but not for others.

Here are Four common fonts measured in both Points and Pixels on OSX and Windows, this is without an “multiplier”
but I defy you to find a magic number that will take the values from one chart and create the numbers on the other

Test Text=[W] designated TextSize =100.0

Platform =Desktop:OSX
   FontName = Arial
      Unit=Point Width=94.38 Height=115.00 Ascent=91.00 Aspect=82.07%
      Unit=Pixel Width=94.38 Height=115.00 Ascent=91.00 Aspect=82.07%
   FontName = Times New Roman
      Unit=Point Width=94.38 Height=115.00 Ascent=89.00 Aspect=82.07%
      Unit=Pixel Width=94.38 Height=115.00 Ascent=89.00 Aspect=82.07%
   FontName = Courier
      Unit=Point Width=60.01 Height=100.00 Ascent=75.00 Aspect=60.01%
      Unit=Pixel Width=60.01 Height=100.00 Ascent=75.00 Aspect=60.01%
   FontName = Courier New
      Unit=Point Width=60.01 Height=113.00 Ascent=83.00 Aspect=53.11%
      Unit=Pixel Width=60.01 Height=113.00 Ascent=83.00 Aspect=53.11%
Test Text=[W] designated TextSize =100.0

Platform =Desktop:Win
   FontName = Arial
      Unit=Point Width=126.00 Height=149.00 Ascent=119.00 Aspect=84.56%
      Unit=Pixel Width=99.00 Height=112.00 Ascent=90.00 Aspect=88.39%
   FontName = Times New Roman
      Unit=Point Width=125.00 Height=151.00 Ascent=119.00 Aspect=82.78%
      Unit=Pixel Width=95.00 Height=114.00 Ascent=90.00 Aspect=83.33%
   FontName = Courier
      Unit=Point Width=80.00 Height=143.00 Ascent=107.00 Aspect=55.94%
      Unit=Pixel Width=60.00 Height=107.00 Ascent=80.00 Aspect=56.07%
   FontName = Courier New
      Unit=Point Width=80.00 Height=143.00 Ascent=107.00 Aspect=55.94%
      Unit=Pixel Width=60.00 Height=107.00 Ascent=80.00 Aspect=56.07%

Notice on OSX… that POINTS = PIXELS, where Windows they measure differently
On OSX Courier and Courier New are different (HEIGHT), but on Windows they are the same

I’m not saying that any of this is due to XOJO, but more that the rendering on each OS is different, and the underlying FONT FILES themselves are different