We make software for humans. Custom Mac, Windows, iOS and Android solutions in HyperCard, MetaCard, and RunRev LiveCode
Much of the following information was gathered from the LiveCode mailing list, and is offered as a reference for cross-platform font issues.
The font issue
None of the major operating systems that LiveCode supports handle fonts in exactly the same way. Even though there are a few fonts that some systems have in common, the font metrics vary even between fonts of the same name. They will look and print differently on different platforms. Arial on Windows is not the same as Arial on Macintosh.
Windows by default displays fonts at 96 dots per inch resolution, and Macintosh displays them at 72 dots per inch. However, these default resolutions can (and usually do) change if the user has set their monitor to display at a different resolution. You cannot predict what the font metics will be on any given machine at any given time.
There is no easy way to resolve these conflicts that will enable your stacks to display identically on all platforms. The best solution is the simplest: allow the default system font to display in field text, or if you prefer more consistency, use a font common to all platforms. In all cases, leave some extra space in the field to allow for different word widths and line wrapping.
To set a field to always use the system default, set its textfont property to a font name that does not exist, such as 0:
set the textfont of fld 1 to 0
Fonts common to all platforms
There arent many. Only Courier is supported across Linux, MacOS, Mac OS X, and Windows. Because it is a monospaced font, Courier isnt very useful much of the time.
Below is a partial comparison table of some fonts shared across various operating systems. Users may install their own fonts at any time; this table lists only those fonts that are shipped with the operating system. If a font is not listed here, it is not relevant to cross-platform use. This table is not all-inclusive.
|Mac OS||Mac OS X||Windows||Linux|
|Times New Roman||X||X||X|
|Times New Roman||(often*)||X||X|
* Not native to the OS but often auto-installed by web browsers or other software
According to the mailing list, the most-recommended font for Mac/Windows deployment is Arial. Tahoma is also popular. For stacks that must display on Linux/Unix platforms as well, you will probably have to change the field text dynamically to a different font, or maintain separate versions of your stack.
Font metric comparisons
If you are determined to try for the closest appearance in cross-platform stacks, you can set the textfont and textsize of fields or stacks dynamically with scripts depending on the platform the stack is running on. Note that Windows fonts are not scalable, where Mac OS and Mac OS X fonts are. If you set a font size on Windows that does not exist natively, it will look bad. Macintosh fonts look good at any size, so it may be preferable to set your field text to a size supported by the Windows font, or else dynamically change the field fonts by script when the card opens. (LiveCode profiles can do this.)
Dar Scott posted the following helpful comparison table to the mailing list, This chart shows the formattedHeight and formattedWidth of the word "Washington" in different fonts and sizes on two platforms.
|10||11 (except for height)|
|12||14 (except for width)|
Shipping fonts with your standalones
Some companies ship fonts with their applications so that they will more closely match across platforms. Bitstream makes a font called Vera that is specifically designed to display the same font metrics on both Windows and Macintosh. However, installing fonts into a users system is not always practical, and some users may not like it.
A last resort images
An image of a block of text is always an option for static text such as labels. However, some people have resorted to using images of text characters, which are assigned to fields dynamically by script using the imagesource property. This requires careful preparation and meticulous scripting and unless an absolute match is strictly required, probably isnt worth the trouble. Text editing such fields becomes almost impossible and scripts will no longer be able to use most of LiveCodes built-in text chunking.
Our recommendation is: in most cases, pretty close is good enough.