Are you going to have the font embedded in an app, or used in a site with @font-face?
Both .otf and .ttf are functional everywhere except Opera mini: http://caniuse.com/#search=otf
But i take it you're asking about rendering quality. I don't have a lot of testing to back up my guess that you're probably fine in either case, unfortunately.
From what I have bee able to gather, implementation of @font-face is problematic in some mobile apps (which is what your table shows, basically), so embedding seems the safer (fewer annoyed costumers) approach—which covers the “predictable” part of the question.
And, yes: the “clearly” part of the question was in regard to rendering quality. There are a lot of excellent tools for testing font rendering in various browsers. but I haven't stumbled across one yet that compares rendering in mobile apps. From the buzz I am picking up from business types, more and more traffic that was formerly web-exclusive is anticipated to become pure mobile, so it seems to me that fonts-for-mobile is an emergent trend with a lot of possibilities…
Nick, a lot of work in this area has to do with targeted development. There is quite a significant difference between the available mobile devices and developing a font for each of them hinges on a combination of factors, including the consideration of OS, physical size, resolution and screen type/rendering environment, e.g., E Ink, LCD. As such it may not really be possible to have a one font fits all solution. The work that goes into optimising a font for an E Ink display would likely be of little or no benefit on a sharper colour LCD such as the one used on the iPhone/iPad or the HD Super AMOLED display used on the Samsung Galaxy SIII.
Thanks for the comments. The issue is not so much developing fonts for a specific environment, but rather choosing the format that is most likely to render properly with the least number of problems.
I developed most of my library with print use in mind and, even more specifically, with display use in print in mind. Consequently, a lot of my fonts track tight, which is okay for print, but is probably not ideal for webfont and mobile usage—as in Ye Olden Days, “television spacing” was considerably looser than print spacing because of scan-line blur. Despite all of the whoop-ti-doo about improved screen resolutions and such, I am not entirely convinced that fonts developed for on-screen use shouldn’t have wider sidebearings as a general rule. In consideration whereof, I was considering making separate versions of my fonts for print and on-screen use. And, it seemed more sensible to make one flavor of OTF the print version (given Postscript’s long history with print, probably CFF), and the other the on-screen version (which kinda leaves TTF as default).
You could develop everything in TrueType flavoured OT and then append the .ttf or .otf file extension depending on your target market. Unless you have a proven reason to supply CFF OT fonts to your customers, it would save you the hassle of developing and maintaining both varieties. The discussion around this issue over on TypeDrawers gives some interesting perspectives on the matter:
If it helps and you are experimenting with web font settings on a public site I would be happy to send or post screen grabs from an iPhone 4 or iPad 3, so that you can get a feel for how those are displaying. I would be very interested in the results of any tests.
11 Jan 2013 — 8:25pm
Are you going to have the font embedded in an app, or used in a site with @font-face?
Both .otf and .ttf are functional everywhere except Opera mini:
http://caniuse.com/#search=otf
But i take it you're asking about rendering quality. I don't have a lot of testing to back up my guess that you're probably fine in either case, unfortunately.
Jason C
12 Jan 2013 — 4:59am
From what I have bee able to gather, implementation of @font-face is problematic in some mobile apps (which is what your table shows, basically), so embedding seems the safer (fewer annoyed costumers) approach—which covers the “predictable” part of the question.
And, yes: the “clearly” part of the question was in regard to rendering quality. There are a lot of excellent tools for testing font rendering in various browsers. but I haven't stumbled across one yet that compares rendering in mobile apps. From the buzz I am picking up from business types, more and more traffic that was formerly web-exclusive is anticipated to become pure mobile, so it seems to me that fonts-for-mobile is an emergent trend with a lot of possibilities…
13 Jan 2013 — 9:12am
Nick, a lot of work in this area has to do with targeted development. There is quite a significant difference between the available mobile devices and developing a font for each of them hinges on a combination of factors, including the consideration of OS, physical size, resolution and screen type/rendering environment, e.g., E Ink, LCD. As such it may not really be possible to have a one font fits all solution. The work that goes into optimising a font for an E Ink display would likely be of little or no benefit on a sharper colour LCD such as the one used on the iPhone/iPad or the HD Super AMOLED display used on the Samsung Galaxy SIII.
13 Jan 2013 — 9:20am
Not sure how relevant these are, but they are interesting. Both links are to videos regarding screen display innovations made by Japan Display Inc.
Highest pixel density display in the world (651ppi):
http://www.youtube.com/watch?NR=1&v=CuBevxQG6eo&feature=endscreen
Paper-like low-power colour LCD (no backlight):
http://www.youtube.com/watch?v=mdXu9jmTI2A
14 Jan 2013 — 7:32am
Karl,
Thanks for the comments. The issue is not so much developing fonts for a specific environment, but rather choosing the format that is most likely to render properly with the least number of problems.
I developed most of my library with print use in mind and, even more specifically, with display use in print in mind. Consequently, a lot of my fonts track tight, which is okay for print, but is probably not ideal for webfont and mobile usage—as in Ye Olden Days, “television spacing” was considerably looser than print spacing because of scan-line blur. Despite all of the whoop-ti-doo about improved screen resolutions and such, I am not entirely convinced that fonts developed for on-screen use shouldn’t have wider sidebearings as a general rule. In consideration whereof, I was considering making separate versions of my fonts for print and on-screen use. And, it seemed more sensible to make one flavor of OTF the print version (given Postscript’s long history with print, probably CFF), and the other the on-screen version (which kinda leaves TTF as default).
14 Jan 2013 — 8:19am
You could develop everything in TrueType flavoured OT and then append the .ttf or .otf file extension depending on your target market. Unless you have a proven reason to supply CFF OT fonts to your customers, it would save you the hassle of developing and maintaining both varieties. The discussion around this issue over on TypeDrawers gives some interesting perspectives on the matter:
http://typedrawers.com/discussion/200/reducing-font-family-bloat/p1
If it helps and you are experimenting with web font settings on a public site I would be happy to send or post screen grabs from an iPhone 4 or iPad 3, so that you can get a feel for how those are displaying. I would be very interested in the results of any tests.