Readable Web » Software

Extensis Brings Google Web Fonts Straight Into Photoshop

Richard Fink — Mon, 07 Nov 2011 23:42:10 +0000

Extensis, the company behind the WebINK web font service, today announced a plug-in that brings Google Web Fonts straight into Photoshop.

Free And Open-Source Fonts Served Alongside The Proprietary, In A Surprising Twist

Since launching the WebINK web font service, Extensis has concentrated on building a library of fonts drawn from the proprietary type community, building on long-standing relationships developed through Extensis’ other font and design products: Suitcase Fusion (a desktop font manager) and Universal Type Server (a server-based font library and font license manager for workgroups).
But they haven’t left it at just being another service operating in the shadow of (now Adobe) Typekit – as services like Fontdeck, WebType, and others have done. From day one, I’ve personally seen them strive to find new ways to meet the needs of web designers with innovative software tools that, in combination with their hosting service, make the use of a font service – as opposed to shopping the web for suitable fonts and then self-hosting – a much easier and useful proposition. They’ve continuously shown up at the major web conferences to promote, of course, but also to watch and learn and listen. What’s sets them apart is that they turn around and act on that knowledge in creative ways.

Riding Piggy Back On Google’s Web Font Initiative

[A developing story... more analysis, riding in on piggy-back, is on the way...]

Adobe Announces Acquisition Of Typekit

Richard Fink — Mon, 03 Oct 2011 19:43:00 +0000

It’s fair to say that those close to the development of Web Fonts expected Typekit to be acquired by somebody. Well, today somebody did.

Adobe Buys Phonegap And Typekit for Better Web Tools

The Typekit Blog Announcement

And Adobe’s press release: Adobe Acquires Web Typography Innovator Typekit

A good thing? A bad thing? An inconsequential thing? Who knows?

ttfautohint – Support Web Typography

Richard Fink — Wed, 10 Aug 2011 14:10:43 +0000

There is a very promising open source tool by developer Werner Lemberg called ttfautohint which promises to make it a lot easier for font designers and also web designers working with free, open-source, and public domain fonts to get them looking good on Windows. Even the early versions have some experts in font software sitting it up and taking notice.

Help Improve Web Typography with ttfautohint is a quick and entertaining video explaining the problems ttfautohint is trying to solve.

Send Money

I’m kicking in a few bucks, and you should, too.

A Webfont Specimen Page Free For Download

Richard Fink — Sun, 10 Jul 2011 15:53:36 +0000

Tim Brown of Typekit put together a webfont specimen page awhile back. Originally introduced in Tim’s article for AListApart: Real Web Type in Real Web Context, and it does give a real nice view of a font in a variety of contexts.

I’ve incorporated a modified version of it into my suite of web font test pages. And, for those who might find it useful, you can take a quick look at it here, and download it here.

The Modifications

There’s two main differences between my version and Tim’s:

For test pages, I like to keep everything – the HTML, CSS, JavaScript, and even images – contained in a single file. As my webfont test pages have evolved, I’ve just found it simpler this way. At least to me. So everything is in one .htm file. The two images from the original – used for background – are included as Data URIs in the CSS. The only downside is that those images won’t show up in IE6 or 7: a situation that doesn’t bother me because nearly all the functionality remains intact and my IE testing is usually done on IE8. (IE6, 7, and 8 all require EOT, and Windows GDI is the rendering engine for all, and I’ve yet to see a font problem appear in IE6 or IE7 that didn’t show up in IE8.)
The @font-face syntax has been updated to use the “Fontspring”, single declaration syntax.
See: Further Hardening of the Bulletproof Syntax and Best Practices for Serving Webfonts to IE9 on the Fontspring blog for more information.

Pause Before You Say “IE Sucks”

An interesting glitch appeared while I was working on this. When displaying the font Ultra from Google Webfonts, there was a strange difference between IE8 and Chrome. In IE8, the glyph “j” was clipped off on the left like this:

But Chrome rendered the entire glyph and allowed the part that IE clips off to extend outside the bounding box to the left:

In both cases, it’s not what you want.
Which browser is doing the technically correct thing? And more importantly, what’s causing it? Since the clipped “j” in IE was more of an eyesore, the kneejerk response for most developers would be, I think, “Goddam IE! Again!”. But after opening the Ultra font in a font viewer, the real source of the problem revealed itself.
In the font itself, the position of the left sidebearing of the “j” was the source of the problem:
You can see that the font itself “clips” the “j”. (And this may or may not show up depending upon the layout.)

Over the past eight months I have cracked open many hundreds of fonts, one after the other. And I can tell you firsthand that even on carefully made fonts, stuff like this happens a lot. Ultra was designed by Brian J. Bonislawsky of Astigmatic who’s very experienced. But even so, stuff happens. So, before you go blaming the browser, if you’re using a webfont, remember that a new variable has been added to the mix – and the source of what seems like “buggy” behavior is just as likely to be there as anywhere else. Just what web developers needed, a new complication!

Some Cool Tools That Came Into Play

The CSS for Tim Brown’s page was originally in three separate CSS files. I brought them together within a single style tag using a nifty free tool – CSS Mixer – which allows you to select a bunch of CSS files, concatenate them into a single file, and minify the code using the Yahoo User Interface Library. After that, it’s cut and paste. Very handy. There is also a tool by the same developer, Sam Beauvois, for concatenating and minifying JavaScript named JS Mixer. (They’re .NET executables for Windows only. No Mac or Nix versions unfortunately.)

That’s it. Pay it forward.

Waving Goodbye To Adobe InDesign

Richard Fink — Wed, 05 Jan 2011 14:27:28 +0000

Something feels different about this year. Borders bookstore is widely expected to file for bankruptcy and it’s hard not to read an end-of-an-era symbolism into that. Clay Shirky reports that the newspaper industry has, perhaps, finally come to grips with the idea that the web is not just another business avenue but a discontinuity that makes much of what they have always done, irrelevant.

In publishing software, John Hudson, type designer, linguist, and invited expert to the W3C Fonts Working Group reports on Typophile:

The CSS3 font spec support for layout features is significantly more advanced than that provided in most word processing apps and in some respects even more advanced than that in InDesign. The nightly test builds of FireFox 4.0 already provide support for more OTL features than InDesign, both through higher level feature functions defined in CSS and through direct access to font-specific features (meaning that even custom layout features can be accessed).

Write Once, Print Anywhere

One of the things that kept browsers away from functioning as traditional “Desktop Publishing” apps was the need to install your font of choice in the operating system.
Web Fonts broke through this barrier. And the field is clear.

It’s just a question of time. And it will not make a difference if InDesign remains in other ways more sophisticated. If only for one simple reason: the browser is jacked into the network natively and InDesign isn’t.
And it’s about the network, not how pretty the printed output is. People will make adjustments in their expectations in return for the efficiencies. (Lately, the print quality of the books I’ve bought sucks anyway. How about you?)

Seems the “Browser As DTP App” idea is finally on the radar.
David Berlow writes:

Based on that big thing — that @font-face… — 2011 appears to be shaping up as the year browsers begin seriously taking over all the work of typesetting, for both print and the web.

I won’t happen overnight, but: Exit the Compositor, Enter the CSS Stylist. Better start buying Eric Meyer’s books now. You can’t say you weren’t told.

Testing Shows IE9 Beta Greedy For Web Fonts

Richard Fink — Mon, 11 Oct 2010 15:44:42 +0000

The first release of IE9 Beta has some serious flaws in it’s @font-face web font support. I’ve stopped testing until the next release. A programmer on the IE team graciously took the time to respond to an email about it. He said that many of the problems have already been fixed and that the next Beta release will be a lot better.

Here are some of the problems I found:

In my test page of first resort, the Droid Family @Font-Face Test Page, the fonts did render OK.

That was promising. But the question I wanted answered was, “Which file or files in the stack is IE taking?”. Where and when does it grab the WOFF, the EOT, or the TTF?

To determine that, I turned to Fiddler, the excellent (and free) HTTP traffic analyzer by IE veteran and security expert Eric Lawrence.
The results were weird. For some reason, IE9 requests each and every font in the stack: EOT, WOFF, and TTF or OTF. All of them.

IE9 Downloads Every Font In The Stack

That giant sucking sound you hear is IE9 Beta downloading every font in sight. If I had included an EOT, it would have sucked that down, too.

No Gordon, Greed Isn’t Good

I was looking forward to testing web fonts in IE9 Beta. But I had to give up after two or three hours. (I found other problems, as well, but there’s no point in reporting them.) IE9 is clearly not ready for any kind of serious, systematic testing of @font-face support.

With the next IE9 Beta, two questions are of special and immediate interest to me:

1) How does IE9 work with the “Bulletproof” and “Mo’ Bulletproofer” CSS syntaxes? Are there any new gotchas or best practices now that there is support for WOFF, EOT and – with some DRM restrictions, supposedly – “raw” TTF or OTF fonts?

2) Regarding the “raw” TTF and/or OTF fonts – if IE9 ignores them unless the embedding permissions are set to “Installable”, how will that affect performance and, quite possibly, a web author’s ability to test a font and debug a font problem?

This “embedding permission” stuff may be unfamiliar to you so let me explain:

In an interoperability clash with Firefox, Safari, Chrome, and Opera, Microsoft announced that, as of Platform Preview 3, IE9 would enforce embedding permissions. The embedding permissions (usually called “embedding bits”) is DRM data that’s internal to the font. There are four levels of permission. This means that IE9 will decline to load a TTF or OTF font unless the permission level is set to Installable. (That’s Zero for the font techies out there.)

Now, IE can’t know if the font’s internal data is set to “Installable” until it downloads it. So what’s the fallback scenario? What does this mean for page load times and the order in which you have to list the font files in the stack?

All of this, of course, is an effort on Microsoft’s part to discourage web authors from posting “raw” TTF or OTF files. Microsoft has reaped great competitive advantage from its investment in fonts and they are concerned about loss of control. And they are having trouble letting go. (Big surprise.)

I was keeping an open mind about this approach. But in preparing the test fonts and pages for IE9 my mind got made up for me. Enforcing the embedding bits creates a hidden “gotcha” – a possibility that, mysteriously, a font won’t load in IE9 – and there is no justification for this complication. It’s misguided. And as a policy, poorly thought out. It will backfire – producing exactly the opposite of its intended effect.
I would rather see IE9 not support raw TTF or OTF files at all, than this. I would have no complaint.
Should this decision persist into the next Beta release, I’ll go into more detail in a separate post.

Lastly – the phrasing of the announcement about this on the IE blog went way beyond spin and into the realm of disingenuous. The wording makes it seem like restricting the loading of fonts based on the embedding bits is in conformance with the CSS3 module.
It isn’t.

Here’s what was written on the IE blog:

“Starting with Platform Preview 3, IE9’s @font-face implementation conforms to the CSS3 Fonts module; supported font formats include EOT and WOFF as well as raw fonts with embedding permissions set to installable.”

EOT is NOT a part of the CSS3 Fonts module. Neither is font loading restrictions based on embedding permissions. I do, however, admire the wordcraft involved in grouping them all together in the same sentence so as to create the impression that they are all a part of the CSS3 Fonts Module.
Very slick. Very Bushy.

To Kindle Or Not To Kindle

Richard Fink — Wed, 28 Jul 2010 17:43:52 +0000

Decisions, decisions.

Today my wife the doctoral candidate asked my advice on whether to buy a book she needed as a P-Book or the Kindle edition. (We have the Kindle DX.)

The name of the book is The Structure Of Scientific Revolutions by Thomas Kuhn. (Strangely, I remembered both the book and the author’s name. I think I might have read it a long time ago during my history-of-technology phase.)

Anyway, here were the considerations:

Delivery: Kindle is instant versus having to wait (and pay extra) for the P-Book.

Price: $9.99 for the Kindle versus $13.80 plus shipping for the P-Book.

Payment Method: Both instant – quickpay or autopay or one-click or whatever Amazon is calling it.

Intrinsic Quality: Print is print is print. Expectations will be met. There will be a Table Of Contents, there will be an Index. You can flip through it. However, there’s no equivalent to a “flip through” on the Kindle. And Kindle books can vary in quality depending upon how the digital file is created. This usually means problems navigating through the book. How widespread these problems are with Kindle books produced by commercial houses, I don’t know. But the fear flashed through my mind – and that’s a problem for both Amazon and publishers of titles for the Kindle. I wonder what the return policy is.

Miscellaneous Pros For the P-Book: You can resell it. You can loan it to a friend who doesn’t have a Kindle. It’s just as easy to scan and OCR parts of it as it is to try and copy and paste from the Kindle. (Can that even be done? …gotta work on my Kindle-skills.)

Miscellaneous Pros For the Kindle Edition: Nothing to carry, it travels with the device. It also travels with the iPad via the Kindle app. Is there a desktop version of the Kindle app? I don’t know.

Bottom Line: This book is a must-have, not discretionary. (The local library could, in this instance, be an option since the course requiring it won’t last forever.)
But on the logic of, “Well, ten bucks more or less isn’t going to break me”, the Kindle edition won. Later today, I’ll check out the quality issues and report back.

Transitions, transitions.

[ UPDATE: A Few Hours After First Post ]

The book indeed has a table of contents. However, when you first “open” the book on the Kindle, for some reason it jumps to the Preface, not the TOC. Don’t see much logic in that. Plus, who reads the damned Preface anyway. I know the author is grateful to their family, to God, and to that first-grade teacher who put them on the path to authorship. There should be a “Start Reading” option that takes you straight to the meat. Or, start with the TOC, for heaven’s sake. But anyway….

Part of the reason for this post was to display, unashamedly, my own ignorance of what’s up with Kindle books. From what I can see, the best thing about the Kindle is the iPad Kindle app. Much, much more usable. And in Naples, Florida, where I live, it’s too damned hot in the sun, anyway.
In a comment on this post, Joe Golton of FilterJoe, who’s not ignorant says:

“Richard – You’ve already pulled the trigger on this one but there’s a few things that would be helpful for you to know before purchasing any more books from the Kindle store:

1) There IS a way to flip through a book, but only if the book is formatted with “waypoints.” Waypoints are the little dots you see at the bottom of the Kindle’s screen for books that have them. Look at the Kindle DX User’s Guide for an example. Just flick the controller to the right (or left) flip forward (or backward) through the book chapter by chapter.

2) You can usually download a sample to see if the book has Table of Contents and waypoints enabled. You will want to do this for any book that has chapters, to see if it is set up to take full advantage of the Kindle formatting.

3) Nonetheless – a sample will usually only show you the first 5% or so of a book. So you may not get to preview whether graphs were done correctly.

The Nook from Barnes and Noble has the advantage of allowing you to browse the entire book while you are in the Barnes and Noble store. The Nook also has another “flip through the book” option – a slider that can be used on the touchpad to jump to different parts of the book.”

So there you have it. And me, too.

E-Book Formats: The Mad Scramble

Richard Fink — Thu, 01 Jul 2010 14:37:40 +0000

I haven’t been reporting much on developments in the e-reader biz lately. Simple reason: I can’t keep up and I don’t think it pays at this point to even try. I’m enjoying the shake out, though.

The mad scramble is being driven by two factors:
1) Screen technology has gone mobile in a big way – with the Kindle, Nook, iPad, iPhone, Android, and so forth and so on.
All the stuff you could possibly have the time to read can now travel with you. And if that isn’t enough, even more stuff you’ll never ever have the time to read can be sent wirelessly to you.
2) These screens do provide a satisfying reading experience. And they are getting better all the time.

The New iPhone’s “Retina” Display

I checked out the new iPhone with it’s ultra-sharp Retina display the other day and it was amazing, really. As an iPhone user, I was very skeptical about it being worth the hassle and expense of an upgrade, but to these tired old eyes, it definitely is. I’ve simply never seen a display with text as crisp and sharp at small sizes as I saw on the new iPhone. I did a side-by-side comparison with my current phone and all I could say was, “Wow”. The next day I was using my wife’s iPad for something and I couldn’t help but try to imagine what it would be like if the iPad had the same quality screen as the new iPhone. Wow++. Only a matter of time, I suppose.

E-Reader? Got One. It’s Called A Browser.

And so, everybody’s scrambling to establish themselves as the dominant platform or format or application, or something or other for the burgeoning market for “books onscreen”.

Here’s a simple fact that, for me, stands out: All day long I read from an application called a browser. You’ve heard of them, right? Internet Explorer, Firefox, Chrome – those guys. But yet, when it comes to paper books that have been ported onscreen, I’m being asked to use some other application called an E-Reader.

Why? What’s wrong with this picture? Are the words in a paper book different than the words on a blog?

As you ponder this question, check out the free browser-based Ibis Reader. (Yes, for the iPhone/iPad it’s an app. A matter of screen real-estate, I suppose. When will mobile Safari support full-screen mode?)

I’m also keeping an eye on Blio, new e-publishing software that seems to be a little different from the rest of the pack, but we’ll see when it soon debuts.

Wanna e-publish? Jeffrey Zeldman posted a nice, brief roundup with some juicy links a couple of days ago.

Readable Web At AnEventApart, Boston

Richard Fink — Sun, 23 May 2010 16:05:23 +0000

Boston, Massachusetts Readable Web is getting out of the office this year. I’ll be attending and reporting on a wide variety of events.

Starting with:

AnEventApart, Boston

I’ve never attended one of Zeldman & Meyer’s traveling road shows before and I can’t wait. The event kicks off tonight with a meet and greet at the Westin Copley Hotel sponsored by Extensis who is here to preview their new web font service WebInk.

Over the next few days I’ll be posting pics, twittering, muttering, commenting about just how tall Jeff Veen really looks in person, and reporting on everything and anything that happens to spark an idea in my brain.

Details on this conference and upcoming Event Apart conferences here.

Update: After-Conference Thoughts

Call it what you want: web design, digital publishing, whatever – the problems exist on two levels.

Problem 1: Cutting The Bullshit

This problem is not unique to digital publishing but to all publishing: staying on message, staying focused, writing clearly, keeping it brief – all the trite truisms are just as true today as they were when David Ogilvy wrote Ogilvy On Advertising in 1983 and Rudolph Flesch wrote The Art Of Readable Writing in 1949. Nobody is going to give you or your product more than a passing glance. At least at first. Waste people’s time and they’re gone. Click.

This is why I perked up when Luke Wroblewski argued that you should design your small-screen mobile experience first and build your desktop experience from that kernel. I agree. Working from the inside out like that imposes a discipline that would probably not exist if you started with the desktop experience. And if you can’t seem to cut it all down to it’s essence for an iPhone or Android, it’s time to ask yourself why the site exists in the first place.

Problem 2: Re-Tasking Content For Different Devices And Screen Sizes

It used to be that the difference between user agents (browsers) was the thing that drove web authors crazy. Yes, there are still issues, but it’s easy to envision a time in the near future when that won’t be anything more than an occasional and minor annoyance. The monster facing us now is different devices and screen sizes. This is a tough one – and the mental tools publishers need are just beginning to coalesce.

Recently, on Typophile.com, designer John Hudson made the observation that, to him, websites in general resembled scrapbooks. For some reason I’ve been thinking about that comment a lot and finally realized why: minus the negative connotations of the word “scrap”, they are scrapbooks. Chunks of information being fed in and out from disparate sources on the network and placed together on the same “page”. The equivalent of taking chunks of five or six pages of a book or magazine and pasting them together. Even in an era of relatively high resolution screens this will still be the case. Content must be chunked so it can reflow into its container. And connectedness is a requirement – the idea of an “e-book” on an “e-reader” disconnected from the net is already preposterous – even though we’ll be living with that situation for some time to come.

I got a new TV delivered today. It’s connected to the network, too. A TV with web apps. A giant iPad. Who’d a thunk?

And, oh, yeah. Just to cap off AnEventApart, Boston:

How Tall Is Jeffrey Veen?

Meeting Jeff Veen in person was a bit of a shock, really. For a guy who writes and speaks about all this web stuff, turns out the guy’s tall enough to be my father!

Oops, Capped Off Too Soon

[A Bit More On An EventApart, Boston] Here’s a nice roundup of the event called Themes From AnEventApart Boston with a link also, to Luke Wroblewski’s extensive notes from the conference. Also, Luke and the concept of “Mobile First” gets a treatment on the Big Web Show.

A Future Without Flash: Microsoft and Apple Nail The Coffin

Richard Fink — Mon, 03 May 2010 21:54:08 +0000

Wow. Big Changes. Bad news and more bad news for Adobe Flash and Flash developers over the past few days.

Apple Says No Flash On Apple Mobile

First, there was the announcement by Steve Jobs on the Apple blog.

Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short.

Steve hath spoken. Adobe Flash lies broken.

Microsoft Says Yes To H.264 Video, Says No To Flash

Dean Hachamovitch, General Manager of the IE team drove in another nail with an announcement on the IE Blog.

The future of the web is HTML5. Microsoft is deeply engaged in the HTML5 process with the W3C. HTML5 will be very important in advancing rich, interactive web applications and site design. The HTML5 specification describes video support without specifying a particular video format. We think H.264 is an excellent format. In its HTML5 support, IE9 will support playback of H.264 video only.

The name of this blog isn’t “Watchable Web” so I don’t know anything about what hidden or not so hidden agendas Apple or Microsoft might have for supporting H.264. But Flash’s funeral will have a big impact on the way text looks on the web, and soon.

Web Fonts Become More Important, Cufón, Too.

@Font-Face just became a whole lot more important. If Flash isn’t going to be available on Apple Mobile devices and IE9 won’t support it for video, Flash no longer has a future. For text replacement, it is no longer a viable option, period. As in: stop using as of now, today. As in: if using, phase out, soon.