Typography for Mobile -- Best Practices Guidance

Scott Rossi scott at tactilemedia.com
Sun Mar 20 19:45:02 EDT 2016

> On Mar 20, 2016, at 3:21 PM, Sannyasin Brahmanathaswami <brahma at hindu.org> wrote:

I'm not sure there are best practices at this point, but here are a few responses, FWIW.

> 1) Assuming we want to avoid loading fonts into LC

Why?  This the only way to display non-resident fonts on a device/system.

> If we use the Droid family... is that available  on iOS?  if so, how do you specify that so that it is not substituted for Roboto on Android (the Droid font is so much better looking)

There are Droid and Roboto fonts on the net in TTF format that can be installed (see above).  My understanding is the Droid font is available on all Android systems; according to Wikipedia, Roboto was introduced in v4 (IceCream Sandwich). Also note that a new (improved?) version of Roboto was introduced in v5.

FYI, Helvetica Neue has been the default on iOS for some time, until Apple introduced San Francisco with iOS 9 and El Capitan.

I find the easiest way to universally assign fonts is to set the textFont of the stack to the desired font name, and change individual controls where needed. As long as controls don't have a font name assigned, they should inherit the stack setting.

Note that on iOS font names are case sensitive and rely on the PostScript names of fonts which may differ from the file names. You can use a font management app or font inspector to view the details of font to determine if it has a different PostScript name.  If it does, and the name differs beyond just upper/lowercase file naming, you'll need to use a font map file (simple text file) to establish font name equivalents on a device.

> If not, what can we use that will
> a) work on Mac Desktop

See above.

> b) work the same on iOS (I'm having trouble there myself with a font that is huge on the desktop and smaller on the iPHone -- as if the metrics were completely different, even though I'm working in 736 X 414 px in both platforms)

One issue I haven't yet resolved is how to handle the font size of a native field when a stack is scaled using fullScreenMode.  In my experience, the font size of a native field doesn't auto-scale, while in most cases the font size of standard LiveCode controls (fields and buttons) does.

Also note that as of 7.1.3, custom-installed fonts on iOS will only render correctly in the iPhone 4/5 simulators, and will display incorrectly (or broken/missing, in the case of icon fonts) in the other simulators (bug #16733).  LiveCode has stated this fix is a low priority, however, the fonts will render correctly on a device.

> c) be substituted on Android, but still have the same look and feel?

If you're planning to use Android fonts on OS X and  iOS, why would you need to substitute on Android?

> 2) Were we to load a font in LC, are display results "robustly predictable" across all devices. Typically where one gets bitten is the line length  and or X heights/line heights  growsor shrink relative to the original design. If the design of a particular "module" mandates some precision on the formatted height of the field/label/visible name etc.  you are then in big trouble.

I would say you need to plan how your application is going to scale across devices: are you going to go with a fullScreenMode that proportionally scales the stack to fit the device screen, or are you going dynamically adjust your UI to scale to screen dimensions. Note how you're going to be displaying text: LiveCode fields or native fields, and test on several devices.


Scott Rossi
Tactile Media

More information about the Use-livecode mailing list