I have at last completed the compilation of a font database to examine the 
issues concerning the differences in rendering text on Mac Monterey, Windows 10 
and Linux Ubuntu.

Over 4600 font files have been included in the database, including the fonts 
distributed with each platform, the Google fonts, STIX, KG and Janda and some 
other sources. Each fontfile may have multiple style variant fonts embedded in 
it so over 9200 individual fonts are included. 
For each font, the ascent and descent at a range of text sizes between 8 and 25 
when used on each platform is recorded, as reported by the LC measureText() 
function. As previously discussed these metrics, which determine the baseline 
of the text, differ markedly between platforms, so that text is rendered in 
different  positions in the stack, leading to alignment and clipping problems, 
or simply an unprofessional-looking UI (this problem is not unique to LC).

The db also records the rendered text lengths for three sample texts at each 
textsize, in order to investigate cross-platform horizontal alignment and 
clipping issues.
The db also records : the fontnames for each font for each platform 
(different!), the set of all alternative family names, font names (different 
again!) and styles as given in the font metadata tables, the postscript name, 
the number of fonts in the file, the designer's em grid size, ascent, descent 
and OS/2 vertical metrics,  the version and the first line o) the copyright 

To summarise the conclusions of my analysis using this database:

1. Fonts which cannot be used cross-platform
There are 96 fonts in the MacOS stable which will not install on Windows, 
because they lack some metadata entry. These include Helvetica, Times, Courier, 
Monaco, Zapfino, Apple Symbols, Apple Chancery, LucidaGrande, Copperplate. 
Apple Color Emoji. Whether a font is legal to use cross-platform is a different 
question: the Apple copyright licence for New York for example restricts its 
use to Apple devices.

2.  Vertical alignment: No fonts are placed at the same vertical positions 
across the 3 platforms. Formulae for the baseline using the ascent and descent 
data are developed in the discussion paper below, and these could be used to 
align text manually if exact vertical placement is required, but this is a 
hack, and is not absolutely precise in some cases. What LC really needs is a 
built-in fixedBaselIne property for fields similar to the fixedLineHeight 
property. Until that happens, be warned that some vertical padding is needed 
when designing labels and text fields for standalones to account for vertical 
drift on other platforms.

3. Horizontal lengths: A number of problematic issues with LC were encountered 
in this investigation which certainly slowed me down. Firstly there is a bug in 
start using/stop using font file. "stop using font file" seems to leave the LC 
font library in a corrupted state. On Windows, if you ask for fontNames() after 
stop using but before start using another font, a standalone will crash; in the 
IDE you don't get any error, but the fontNames returned may contain fonts that 
were stopped earlier. There is a workaround for the crash but not the 
subsequent error … because in both Windows and Mac, after stop using is called, 
string widths returned by formattedWidth or measureText are randomly, about 3% 
of the time, incorrect [looks like a released handle is being accessed]. These 
errors could not be entirely eliminated from the db but have been mitigated so 
that I have confidence in my main conclusions below. On Linux the problem 
doesn’t arise because start using is not implemented on Linux; I installed the 
fonts for Linux using shell commands. 

A second problem arises from the way Windows names fonts combined with a 
serious deficiency in LC. On Windows the font name appearing in the font menu 
is in fact just the family name; the style the user wants must be suppled 
separately. However LC can only supply style variations Bold, Italic and Bold 
Italic. This means that literally thousands of fonts such as Arima Thin 
SemiBold cannot be accessed by LC stack on Windows, which just knows about 
Arima. This leaves aside the fact that fontStyles() hasn’t worked in LC for 
years. A further complication is that both Mac and Windows perversely make up 
their own names for the font instead of using any of the names the font 
designer supplies in the metadata: on the Mac the font name usually includes 
the style which is nice but occasionally it doubles the style — Arimo Italic 
Italic and 88 similar cases; and Windows should use a family name but sometimes 
gets it wrong! 

The upshot is that effectively the fonts in my db available for cross-platform 
LC stacks on Mac and Windows is limited to those with the same name on the two 
platforms, or where the Mac name is "<Windows name> Regular”. I also disregard 
about 1200 fonts in the Noto family for non-latin or regional fonts since by 
and large these appear to render at quite different lengths on Mac versus 
Windows. And disregard the two versions of Symbol font which are actually quite 
different fonts

This leaves 1875 eligible fonts. The good news is that of the these all but 
about 110 render at the same length to within 1 pixel (though not on Linux), 
and most of those “bad” ones are icon and assets fonts such as Dingbats or 
FontAwesome, system UI fonts, or very obscure fonts. The standouts are New 
York, Baskerville, Chalkboard, and Roboto. Which means that almost all commonly 
used fonts are safe to use if length accuracy is required — including Arial, 
Times New Roman, Courier New, Impact, Tahoma, Noto Sans, Noto Serif etc etc.

 If fonts which render at different lengths must be used, for example if you 
use the default fonts for labels, then extra padding of 10% is sufficient to 
avoid clipping in the vast majority of cases. More details are given in the 
links below.

4. Links

a. A paper discussing cross-platform font problems for LC stacks


b. The database


c. A stack to assist in extracting data from the database, particularly if you 
are not sqlite-savvy


Neville Smythe

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to