Readable Web » Browsers

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...]

Amazon Moves To HTML5/CSS3 For New Kindle, Leaves Mobi Format Behind

Richard Fink — Fri, 21 Oct 2011 15:50:10 +0000

Some folks I know are waiting for E-Pub to magically arrive and provide a comfy transition from print to screen. But anybody who’s looked into that closely knows it’s a fairy tale.

Ain’t gonna happen, and here’s the latest nail in the E-pub coffin:

Kindle Format 8

The List of Features Includes @Font-Face

Here’s a list of supported features on the way:
List of supported HTML tags and CSS elements

(Note to Amazon: It’s HTML Elements (but I’ll accept “tags”) but definitely not “CSS elements” CSS Properties, it is.)

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?

A Nice Use Of Web Fonts In Mainstream Media

Richard Fink — Fri, 09 Sep 2011 00:16:10 +0000

There’s a nice use of web fonts at the New York Times. (Just remember to clear your cookies to keep on reading past their twenty page a month limit.)

Titled The Reckoning , it’s a link and teaser page for a group of stories about 9/11.

Very tasteful and dutifully solemn.

Definitely not cheesy.

We don’t want cheese.

Worth a look. Really. Except for the upper case “G” with a pimple on its chin. Is this some kind of slick reference to Lincoln? Or Lincoln’s well-documented love of pizza? We’ll probably never know for sure.

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.

New @Font-Face Syntax: Simpler, Easier

Richard Fink — Mon, 07 Feb 2011 17:51:59 +0000

I love it when a plan comes together.

Some months ago, in an an email exchange with Jeffrey Zeldman about the feasibility of a book about web fonts, I wrote that the turning point – the point at which enough would be known to establish best practices – would be around the time IE9 and Firefox 4 were released to market.

A Simple And Conformant Cross Browser Syntax

Now, with IE9 and FF4 nearing release, as if on cue, Ethan Dunham of Font Squirrel has revisited the problem of a cross-browser CSS @Font-Face syntax and found – a year and half after it first became an issue – a new and simpler solution. This was last Thursday.

Only on the web could change happen so fast. Knowledgeable eyeballs were on it immediately. And within hours of publication, it was tested and tweaked a few times. By the end of the day it was already being implemented at Font Squirrel, Font Spring, and Kernest, too.

It Comes In Two Flavors

Since one of the things I do like about the Mo’ Bulletproofer syntax is that, while the following is conformant:

     src: url('http://:/') format('no-ie-404')

it’s obviously odd and deliberately self-describing. Therefore it’s less likely to be left out once you’re in the habit of using it. And less likely to be deleted accidentally by someone unfamiliar with it’s purpose. So, the following is my version of the new syntax, in line with that practice. It’s the result of tests done with the IE9 Preview 7 build and many other desktop browsers and platforms over the weekend.

The Trick Is In The Question Mark

There are currently two variations. They are:

@font-face {
     font-family: 'fishyfont';
     src: url('fishyfont.eot?iefix') format('embedded-opentype'),
	   url('fishyfont.woff') format('woff'),
	   url('fishyfont.ttf')  format('truetype'),
	   url('fishyfont.svg#svgFontName') format('svg');
	}

With this variation, IE 6, 7, 8 and IE9 take the EOT file. But, of course, IE9 supports WOFF, too. So what if, for some reason, you want IE9 to take the WOFF file instead?

Follow The Bouncing Ball

Well, the ball that was set bouncing with Ethan’s original post on the Font Spring Blog bounced back again from Melbourne, Australia where Ryan Seddon of CSS Ninja posted a fix that overcomes this limitation:

@font-face {
     font-family: 'fishyfont';
     src: url('fishyfont.eot?iefix') format('ie9-skip-eot'),
           url('fishyfont.woff') format('woff'),
           url('fishyfont.ttf') format('truetype'),
           url('fishyfont.svg#svgFontName') format('svg');
	}

With this variation, IE9 will not take the EOT. Instead it takes the next font in the stack that’s in a format that IE9 understands. In this case the WOFF file. If there was no WOFF file, it would take the TTF. (That is, as long as the TTF has the hidden embedding bit set to “Installable” – if Microsoft is still sticking to that. I’m not sure what IE9 does in that case, we’ll see.)

It’s Still Being Tested

There’s no such thing as too many tests or testers. If you find a problem, please report it on the Font Spring Blog. Or here.

I’ll be posting more as I test more and to explain how and why all this works and what problems it solves.

Update: Feb 17 2011

Alert: In some quick-and-dirty tests of this syntax in IE9 RC1, a problem came up. If the page kicks IE9 into a “less than” IE9 Compatibility Mode, this technique fails and the fallback font displays. The word from Microsoft’s IE team is that this behavior will not be altered for IE9 RTM.

[Let's get it over with: insert, mentally, your expletive of choice here and now, and then let's move on....]

What this means is that, as of right now, the most comprehensive, failure-proof method – one that avoids the bug in Android, the innate strangeness of the local() descriptor, and bridges the gap between IE6, 7, 8, and IE9 – is the Mo’ Bulletproofer @Font-Face Syntax. However! However! If you prefer a single declaration solution and your pages don’t trigger one of the IE9 Compatibility Modes, barring any more unforeseen changes between IE9 RC1 and IE9 RTM, the Fontspring syntax seems alive and well. The problem won’t come up. Note also, that you can near-totally prevent failure and ensure your pages are running in IE9 “Edge” mode by using the X-UA-Compatible Meta Tag.

Update: March 02 2011

Alert: More changes, but I think we are finally at the end. Maybe. Ethan Dunham has “hardened” the syntax by adding in the EOT-only src descriptor that was a part of Paul Irish’s Bulletproof Syntax. And it works in IE9′s compatibility modes, too. (I can’t see a downside. In fact, adding that first EOT-only src descriptor was Microsoft’s recommended approach to bridging the gap between IE 6, 7, and 8′s proprietary implementation and IE9′s standards-based implementation from the very start.)
So, the following now works universally:

@font-face {
	font-family: 'fishyfont';
	src: url('fishyfont.eot'); /* IE9 Compat Modes */
	src: url('fishyfont.eot?iefix') format('eot'), /* IE6-IE8 */
	     url('fishyfont.woff') format('woff'), /* Modern Browsers */
	     url('fishyfont.ttf')  format('truetype'), /* Safari, Android, iOS */
	     url('fishyfont.svg#svgFontName') format('svg'); /* Legacy iOS */
	}

Ralf Hermann is recommending it in an article on @font-face at Smashing Magazine.

Is it rock-solid? Looks like it. I would use it. But only IE9 RTM can seal the deal. Or not.
Stay tuned.

Best Practice For @Font-Face CSS Takes A Turn

Richard Fink — Mon, 31 Jan 2011 13:32:50 +0000

“Bulletproof ” is out, and “Mo’ Bulletproofer” is in.

In the last few days, major players on the web fonts scene – Kernest and Font Squirrel – have moved from Paul Irish’s Bulletproof @Font-Face syntax to Richard Fink’s Mo’ Bulletproofer syntax as the default.

Ethan Dunham, the developer behind Font Squirrel and Fontspring says:

Mo’ Bulletproofer is the only syntax that works across browsers including Android.
IE and Android both have buggy implementations and this format works around both of them.

Since I’m Richard Fink and this could just be my ego talking, here’s why Mo’ Bulletproofer is best practice going forward…

The Android local() Bug

Android has a bug that’s triggered by using the local() descriptor inside the @font-face declaration.

To clarify, the following non-standard code does not work on Android as it does in IE 6-8:

@font-face {
  font-family: 'somefont';
  src: url(somefont.eot);
  /* IE takes this font, Android doesn't. */
  src: local('3ix90a'), url(somefont.ttf) format('truetype');
  /* Android chokes on the local() descriptor and
    discards the entire @font-face declaration.
    No web fonts show up. */
   }

Unlike IE, Android doesn’t “look back” and take the font specified in the initial url reference.
This makes the “Bulletproof ” syntax unusable on Android.
The problem is described in a bug report filed by Google’s Paul Irish, originator of “Bulletproof ”.
It also includes this FYI:

This bug has also caused a workaround from the Google Font API team: http://code.google.com/apis/webfonts/
As a result they sniff and change the CSS they serve to Android 2.2 devices.

Android Is Too Big For This Problem To Go Ignored

There isn’t much choice here. Mo’ really is more bulletproof. Even if the Android problem didn’t exist, there are other solid reasons for using Mo’ , but Android is the kicker.
How big is the Android market? Well, in 2010 Android emerged as the single best selling mobile platform in the United States.
Andy Rubin, former Android CEO and current VP of Engineering at Google, reports that 300,000 Android devices are being activated every day.

Bulletproof Reported As Problematical On Linux, Too

Last week there was a pingback here at RW from WordPress developer Aaron James Young saying:

I use the Mo’ Bulletproof @font-face syntax, which I’ve found to have the best cross-browser compatibility.

Young spent considerable time hands-on, testing Linux based browsers, before coming to this conclusion.
(It seems GTK-Webkit and Konqueror also have problems with local()).

Don’t Use local() At All

The bottom line is that using local() at all is a bad practice. In Google Fonts Failing for Internet Explorer Users I wrote:

See Jonathan Snook’s post here, and this Typophile thread here for an in-depth explanation of why the local() descriptor should not be used to specify a locally installed font except in very special circumstances.

I now take part of that back: in the absence of being able to specify and query for a unique font version ID – as a matter of defensive coding – I can’t imagine a plausible scenario where using local() isn’t, in some way, asking for trouble.

Here’s the original post on Mo’ Bulletproofer. To be updated soon, after the next Beta of IE9 arrives for testing.

Update – Feb 3, 2011

Paul Irish has chimed in on this issue in the comments. See his roundup on full view, with web fonts, on this test page. Paul is reporting that IE9 downloads both the EOT file and the WOFF file using Mo’ Bulletproofer. His tests were performed in Platform Preview 7. Is it a bug or a flaw in Mo’ Bulletproofer that calls for the addition of Conditional Comments? (That would fix the problem and it’s likely that the page would already contain the necessary “less than” IE9 Conditional Comment tags, anyway.) Also, in yet a new turn, Ethan Dunham of Font Squirrel has chimed in with yet another syntax that looks quite promising. And clever, damn him. Stay tuned. Rumor has it that IE9 RC1 (or will it be an RTM?) is due out in just a few days. Will go hands-on with testing then.

A Cat With Gloves Off

Richard Fink — Sat, 01 Jan 2011 21:18:20 +0000

A Cat With Gloves Off

The handsome gray haired gentleman with the enigmatic smile is me. And today I feel like explaining a few things about myself.
It’s a New Year, you’re already here, and maybe a little trip down memory lane on my end of the blog deal might spark some thoughts on your end of it, too.

The theme is this:

“The cat with gloves on, catches no mice.”
—Benjamin Franklin

Which Means What?

I write about Web Fonts a lot. The change from fonts as “operating system resources” to “web server resources” is a very big one. As the year goes on I’ll continue to write about that. And I’ll be getting deeply involved in other ways, too. Announcements soon.

Back to the Spring of 2009. It was clear that as a publishing medium, the web had hit a wall. It couldn’t continue to evolve until web authors had control over fonts. Fonts are the fundamental units of design.
In the Spring of 2009, the issue finally came to a head: browsers were going to support @font-face. And miraculously, @font-face was already a part of Internet Explorer. Web authors didn’t have to wait. IE and its hundreds of millions of users could benefit immediately. Woweeee.
So, the only question at that point was what the nature of the standards-based implementation was going to be.

Jumping In

I jumped into the fray as a blogger and concerned web citizen because 1) it was the right time in my life for it, I wanted to write and had started Readable Web 2) I had been tracking screen readability issues privately for years, and 3) because @font-face seemed a ripe environment for innovation.
I had a background in web development and understood the issues. But also, and known only to me, really, I had a personal history of small innovations in both the world of atoms (my Career #1 was in the Fashion Industry) and the world of bytes (my Career #2, right here). And I believe, as did the late Peter Drucker and many others, that Innovation is a practice – like management or medicine. It can be taught. I’m a student of it. And if you apply the underlying principles and practice the craft you get results. Businesses can prosper. Sick patients can get well. And maybe, just maybe, them fonts might actually show up in your web page as intended!

Fonts on the web called for a new body of knowledge. It seemed like an environment primed for maximum impact from even the tiniest bit of innovative action. Nobody knew much, no matter how much they pretended to. (I really do think this way, folks. It’s not some weird pseudo-intellectual cover story. Heaven help me!) Anyway, I felt confident that I could contribute something of value. Instinctively it felt like a good fit.

And so, along the way there were my writings here at Readable Web, EOTFAST, the Mo’ Bulletpoofer CSS hack – which right now looks to play a more important role as @font-face develops – and my articles for AlistApart.
[BTW - EOTFAST was and is a particularly good example of the practice of innovation. An update to the EOTFAST package is coming soon. I'll save the story for then.)

Still With Gloves On

Strangely, it was not until a few months ago that I allowed myself to seriously grapple with the business of making and manipulating fonts. Until then, I imposed upon myself a kind of "willful ignorance". A bound copy of the OpenType specification sat on my shelf but was seldom opened. Professional grade software tools like FontLab were seldom used.

There were two reasons for this:

1) I believed that nearly everything about fonts needed to be re-assessed for its applicability to the medium of screens and web technology. I didn't want to color my perceptions with Type Design 101 stuff that everybody swallows as an article of faith. Questioning "what everybody knows" is a part of the practice. What everybody knows is useless information.

2) I knew I would be writing about fonts for web authors who probably knew little about fonts. I needed to carefully "watch myself learn" because, to be most effective, I needed to revert, as much as is possible, to the point where I knew very, very little. I needed to preserve the ability to empathize. The longer it's been, the harder it is to travel back to that time of innocence. And then you fall into the trap of, "Gee, I thought everybody knew how to use the "Merge Contours" tool in FontLab!" As if they would even own FontLab at a price tag of $650.00.

There's a third reason, I should mention, too.
Best introduced by a quote from Charles Kettering:

"A problem well-stated, is a problem half-solved."
—Charles Kettering

Sometimes it's best to watch and wait until the problems that need solving become clear - to wait until you can set, at least in your own mind as a general feeling, the boundary conditions that the solution has to fulfill.
For example, it wasn't totally, absolutely crystal clear until recently that TrueType would be - now and into the foreseeable future - the predominant format for Web Fonts. And an observation like that effects the focus of your investigations in a big way. Thomas Edison didn't turn his attention to developing a practical incandescent light bulb until he was finished putting together all the elements of a comprehensive electric light delivery system. The conditions that the light bulb had to meet were brutally clear by then. Edison stayed away from working on the bulb for ten years. A great act of faith, it would seem, because without a bulb that would 'burn' for a sufficient number of hours, all his work was for nothing. But I don't think he looked at it as risky in any way. I've found that once you have all the other parts of a system put together - nature, fate, the universe, God, whatever you want to call it - never denies you that last missing piece of the puzzle. It might be a bitch finding it, but it's there. Just keep looking.
[Note: There's been some corroboration for this view recently in digital tech - where it's been found that you can actually count on "breakthroughs" as well as the other incremental predictors like Moore's Law.]

Gloves Off At Last

These days I mostly spend all day every day editing fonts, honing my font making skills, learning new ones, and looking at fonts in my test bed of Windows GDI, Windows DirectWrite, Ubuntu (FreeType), Mac desktop, iPad, and iPhone (standard and Retina) and whatever else I can lay my hands on.
Patterns emerge. Solutions present themselves.

Ahhh, finally. A Cat With Gloves Off. Now where’s them mousies at?

Happy New Year!

Web Font Follies

Richard Fink — Thu, 09 Dec 2010 20:10:22 +0000

I freely admit that typographic subtleties like Old-Style Numerals and Swashes don’t send a tickle up my leg. I’m not alone in that. Most web devs wouldn’t give a rat’s ass about those things even if they knew what they were. I asked one web developer if a font with just the Latin-1 characters was okay and he said, “I don’t think so, the site is for a Presbyterian organization.”
And kerning? Don’t get me started… text on the web got by without kerning for fifteen years and all it’s done is grow, grow, grow. Kerning could be bad mojo. Why take chances?

The Web Font Revolution Is Just Beginning

Stephen Coles, formerly of FontShop recently wrote a blog post titled The Webfont Revolution Is Over, Let the Evolution Begin that left me with the feeling that somebody I know needs a good kick in the rebuttal department. Now don’t get me wrong: I liked a lot of what Stephen had to say. And I’ve written similar stuff myself.
But I take issue with a few things. So here goes:

“Like Simon Daniels said so prophetically over a year ago, the war (over formats
and security and delivery) is over.

The War Over Formats And Delivery Is Not Over

Microsoft doesn’t support Data URI’s except in its own IE Fourish, boorish way. And Microsoft is, so far, enforcing the DRM embedding bits within TTF files in an attempt to cling to its cake and eat it, too.

“See? We support raw fonts just like the other browsers!”
(Except in the way we don’t.)

Opera, Safari (on Mac and now iPhone and iPad), Firefox, and Chrome all support TTF without enforcing any DRM restrictions. But in IE9 it lurks as a hidden gotcha. It will waste incalculable hours of development time as web authors go around scratching their heads wondering, “Why isn’t the font showing up in IE?” (This happens to me all the time, still. Go download a fresh copy of the open source Liberation fonts from Red Hat and see how the embedding bits are set.)
IE9 will reject those fonts.
And when the web author finds out why, it’s only a kick in Microsoft’s pants, nobody else.

When will the king stop meddling with trifles? Just when, oh when, are we finally going to put to rest the phrase, “Fucking Internet Explorer”?

“Things will get better. Display pixel density will improve. Windows users will upgrade, replacing GDI with DirectWrite. But this evolution will be slow, and we can’t do much to speed it up.

The Pace Of Change Will Speed Up, Not Slow Down

Nothing is going to move slowly where e-publishing with HTML5 is concerned. The promise of DirectWrite remains “of the future”. DirectWrite doesn’t get anybody off the hook for doing nothing about the visual quality of fonts and their usefulness to developers now, today. Why not just admit that the type industry – and I include me in that – was caught sleeping and stop making excuses?

Now, if by “evolution” it’s meant that the development and deployment of web fonts from here on in will proceed in a slow, steady, controlled, and measured pace, that will not happen. I know it’s hard to see from where and from whom the answers will come, but they will come. If there is a demand, someone will fill it. And it will be frantic. E-Publishing is about to explode and Flash as a text replacement technique is dead.

“Demand comprehensive previews that show fonts in multiple sizes in all the most common rendering environments

Don’t get me started, I said.

Bah, Humbug!

Web Typography, Simply Smashing

Richard Fink — Sun, 21 Nov 2010 01:12:13 +0000

Lists of resources in bibliographies, footnotes, endnotes and the like have long been commonplace in print. And in the academic world, citations are a must. But in the bad old days before the web, unless you had an insane amount of time on your hands and a large first-rate library nearby, as a reader, such lists were, as a practical matter, just that: lists. It could take you a day or a week or longer to track down the full text of just one citation depending upon how obscure the source.
Really, kids, that’s how it was. No Google Books. Imagine.

One of the amazing things about Hypertext is that nothing need remain obscure. The full text of any citation is now just a click away. (Or in these days of mobility, just a tap away. While love remains, as always, just a kiss away, kiss away. But I digress.) Instantaneity (that a word? it should be), meaning the ability to immediately retrieve the source of a citation, has given rise to a new genre born of it: the Hyperlink “roundup”.

Hyperlink Roundups

More than just a list with brief summaries attached – [think People Magazine's "Top Fifty" lists and the like] – on the web, when done right, roundups deliver not just a world of information, but a full-blown solar system. Citations become, for the first time, a practical proposition. For anyone who’s used a browser for more than ten minutes, the process feels so natural that you don’t even pause for a “Wow!”. But a wow it deserves.
Now, if you’re into web design, you probably already know that nobody puts together roundups better than Smashing Magazine. It’s their specialty.

Web Typography: 100 Educational Resources, Tools and Techniques

Check out Web Typography: 100 Educational Resources, Tools and Techniques. I found that just reading the titles and summaries helped put a finger to the pulse of where web typography stands today. But the real beauty is that there’s nothing preventing you from spending weeks, months really, following the links and absorbing all the information that orbits around a piece like this.

[BTW - I was both surprised and pleased that I garnered 2 out of the 100 citations: one was my article Web Fonts At The Crossing published on AListApart and another was Font Hinting Explained By A Font Design Master here at RW. Cool. I’ll take any shred of validation I can get, wherever I can get it.

Next. . .

Zoltan (User Agent Man) Hawryluk Roundups Ruby Text

Hey, “roundup” works as a verb, too! My confrere in things rasterizable, Zoltan “Du Lac” Hawryluk, wrote a piece on Ruby Text: Cross Browser HTML5 Ruby Annotations Using CSS. Ruby text is annotative text that hovers above the main text and looks like this:

With the Ruby annotation, now I finally know how to pronounce Zoltan’s surname. Slick.
First supported in IE5 – yup, IE5, ya can bitch all you want about IE but when it came to text handling features it was ahead of its time – Ruby text now has broad support. Bookmark it: along with many other typographic features, Ruby’s time is a comin’.
And if you’re into browser tech, User Agent Man is certainly worth a spot on your feed list.
Zoltan’s got the right stuff. Insightful.

Next. . .

Typedia Marches On

As I’ve written before, roundups on the Typedia Blog by Eric Vorhes and others continue to do a bang up job keeping geeks like me abreast of developments in web typography. Less time searching around, more time listening to Miles. I dig it.
Feed me, Seymour.

And a Happy Turkey to all.