Many Web designers have been asking how we support iPhone® and iPad® devices using our Fonts.com Web Fonts service. These devices are known for superior display quality, and as our testing and usage have shown, there’s no exception when it comes to Web fonts. The iPhone 4, for example, with its 960-by-640-pixel resolution at 326 ppi (higher than early laser printers), renders text that is simply stunning. Web fonts really shine when zooming to see content up close, thanks to their amazing sharpness and clarity.
Our approach to Mobile Safari® support can be summed up in two words: simplicity and control.
“Simplicity” is often difficult to achieve, but we’re committed to giving Web designers an elegant solution that’s also very easy to use. Second (and maybe more important), we believe it’s essential to provide designers with control over how they assign their fonts. Specifically, we think designers should have the freedom to assign CSS selectors according to their own associations for bold, italic, light, condensed, heavy, ultra and other styles.
Why is this so important? The Helvetica® typeface family, for example, contains more than 50 fonts (weights) in our Web font solution. It certainly made sense to us to leave the CSS selector assignments up to the designer. Yet, believe it or not, we reached that conclusion after much debate. We understood that by predefining CSS declarations behind the scenes, we could offer convenience to users because the work would already be done. However, we also knew we’d be making subjective decisions, so total flexibility won in the end. Control belongs in the hands of designers.
We also have a hunch that by keeping our solution simple, and by enabling designers to assign their own CSS selectors, we’ve been able to retain consistent, browser stability using Mobile Safari. I guess one could argue that as being the most important aspect of all.
So, basically, your fonts look like every other webfont on Safari because you didn’t actually do anything differently from other webfont providers?
Our approach is actually different. For example, as mentioned in the post, we allow users to assign CSS selectors to individual weight, as opposed to predetermining the weight and not giving designers a way to do this for themselves. This latter approach is being used by other providers. We believe this may be leading to browser instability in some cases — something we’re not experiencing.
Weird, I could have sworn I can do that with TypeKit by just including a font-family and defining a font-weight and get the correct cut of the font. But maybe I’m misunderstanding something—a code example would be appreciated, to see what exactly is different. Thanks!
When you have multiple weights defined in a font-family like in some other services, it will crash Safari in iPhone and iPad. Our service does not do it this way of course, so our service works great in iPhone and iPad. This is other services way of doing it, like this:
@font-face{
font-family:“font1”;
src:url(“url path to font 1″) format(“svg”);
font-style: normal;
font-weight: normal;}
@font-face{
font-family:“font1”;
src:url(“url path to a different font for font1”) format(“svg”);
font-style: normal;
font-weight: bold;}
The result of this is crashing iPhone and iPad, plus problem with IE. Not to mention when you have professional fonts that have 10 to more than 50 weights/styles. How do you define, ‘light’? is it weight 7 or 9..? ‘heavy’ is it weight 30 or 47…?
Thanks,
Oh, cool—thanks for the quick reply. I’ll keep it in mind when advising customers in the future.
If you or your customers use our service, you don’t have to worry about this, our system simply will not cause this kind of problem.
Thanks,
[…] This post was mentioned on Twitter by Fonts.com, Douglas Brull, Delicious Black Box, Okay Type, Best Mpls Web Design and others. Best Mpls Web Design said: RT @DouglasBrull: Getting Web Fonts to Look Fantastic on iPhone and iPad Devices http://blog.fonts.com/archives/865 ( via @Fontscom ) […]
Interesting, because I’ve always used selectors with other services. As far as the crashing goes, Typekit resolved that in May.
The only reason I use your service has been the workhorse fonts that I can’t get elsewhere. As far as performance and ease of use is concerned, I haven’t seen a difference.
Appreciate the effort, but you’re just patting yourself on the back for making par.
Yeah, sorry but this blog post is kind of a waste. I read it hoping to find out more about your process, but this simplicity and control part is pretty bogus. You wrote 5 paragraphs and didn’t really say anything. I learned more in comment #2 than I did in the entire blog post.
I think Steve’s post above addresses our process specifically (repeated below). Can you be more specific about the info you are looking for?
Getting Web Fonts to Look Fantastic on iPhone and iPad Devices .…..
I found your entry interesting do I’ve added a Trackback to it on my weblog
…