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 notice. 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 https://www.dropbox.com/s/y4biemi64iysc40/Cross-platform%20text%20appearance.pdf?dl=0 <https://www.dropbox.com/s/y4biemi64iysc40/Cross-platform%20text%20appearance.pdf?dl=0> b. The database https://www.dropbox.com/s/qexjqnce6ept6y4/nsFontmetricsDatabase.sqlite?dl=0 c. A stack to assist in extracting data from the database, particularly if you are not sqlite-savvy https://www.dropbox.com/s/yjtv77u8sh95z5d/nsFontMetricsBrowser.livecode?dl=0 Neville Smythe _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
