Font size standardization

[altenbach]

Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.

The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??

Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.

As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.

Idea -->LabVIEW should also standardize here!

[Andrey_Dmitriev]

I think I’ve identified the issue. Last weekend, I experimented with the Poppins font in LabVIEW (which appeared unusually small), and it seems that LabVIEW calculates font height based on the bounding box metrics rather than the cap height.

To test this, I used FontLab 8 and modified one font by setting the ascender equal to the cap height and the descender to zero. I also adjusted the safe top and bottom values for the bounding box accordingly. Now bounding box is equal to Cap Height. And voilà — the font appeared the same in both LabVIEW and WordPad. When set to 14 pt, the height was 14 pixels in both applications:

How it should be? Classically to compute the pixel height of a font at a given point size, on Windows we can use the following formula:

The cap height comes from the font metrics, while the units per eM are typically 2048 for most TrueType fonts on Windows. The screen resolution is assumed to be 96 DPI. For example, Arial and Segoe UI have slightly different cap heights (1467 and 1434, respectively), so at 36 pt, their heights should be approximately 35 and 34 pixels.

However, in LabVIEW, Arial 36 pt and Segoe UI 36 pt render at 23 and 18 pixels in height, respectively, while in WordPad they appear as expected — 35 and 34 pixels. This discrepancy occurs because LabVIEW normalizes font rendering to the bounding box (my guess). When normalized this way, the fonts scale to 0.64 and 0.53 of their expected size compared to WordPad. This is how it looks - significantly different in height:

And this is why:

So, in LabVIEW they downscaled with factors 0,64 for Arial and 0,53 for Segoe UI.

Now we can measure Tahoma, and indeed, in Word the size in pixels is more or less equal to the font size - 8 pix for 8 pt, up to 20 pix for 20 pt, but in LabVIEW we have 5 pixels height for 8 pt font and 12 pix for 20 pt, measured in Photoshop:

because scaled down with factor 1489/2472  = 0,6:

Something like that.

[Bob_Schor]

     Thank you, Andrey, for so clearly identifying the nature of the problem (which is that LabVIEW's definition of "Font Size" appears at variance with most other PC (and Mac?) software implementations). 

     With (almost) every PC user being "forced" to use a new OS (something cleverly called "Windows 11"), and NI apparently reopening Altenbach's original 2011 plea to standardize Font Size, is there any indication of when we might expect to join the rest of the "Computer Type Fonts" world?

Bob Schor

[Andrey_Dmitriev]

I think we may never see a truly “perfect” solution for font rendering. Not only the sizes, currently, the lack of full Unicode support is a major issue — but it’s not the only one. Two other fundamental properties of high-quality typefaces are kerning and hinting.

Kerning refers to the adjustment of spacing between specific pairs of letters to improve visual appearance. For example, in the Tahoma string, the combination of T and a should be slightly adjusted so that the a tucks slightly under the T, avoiding an awkward visual gap. Similarly, in the pair T and V, the V should be moved slightly to the right to prevent the letters from appearing too close together.

Hinting, on the other hand, provides instructions to the rasterizer for different sized — the software that converts vector outlines into pixels — on how to render the font cleanly at small sizes or low resolutions. Without proper hinting, some elements of the font may appear blurry or uneven.

And on the top of this story we have High DPI monitors, and LabVIEW also have no support as well. Lot of works ahead.

[Bob_Schor]

While "Perfect is the enemy of Good", I'd settle for text rendering that follows the Windows/Microsoft Font/Type specifications.  Even if it isn't possible to have all Type sizes from 6 to 36 point, something like 6, 8, 10, 12, 14, 16, 18, 24, 30, 36 would be nice (and each one being a single "larger" or "smaller" selection).

Bob Schor