Hopefully it will make the internet a more beautiful place, and not like a bunch of designers got drunk on the punch and barfed fonts everywhere.

My full blog post: http://blog.twg.ca/2009/09/4-fears-of-font-face/

Kind regards,
Matthew

Bottom line: With FFx’s support of @font-face, it’s now possible for cross-browser font embedding with FFx, Safari, IE6, IE7 and IE8 (and purportedly Opera v10 & Google Chrome following soon).

My observation: Of all the user agents that render embedded fonts, FireFox is the only one that shows a perceptible delay, when loading a page containing embedded fonts (i.e., page initially renders with – assume “the default” fonts – then re-renders and “flashes”, loading the embedded fonts).

This text-replacement re-rendering is most annoying and I’m wondering if there is way for FireFox to remedy this, as other user agents seem to have accomplished?

(Behavior noted in FireFox for both on my “x-Browser Fonts” article and the “Potential of Web Typography” article).

Cheers,
-stk

For example, let’s say someone wants “kool” symbols of cats, dogs, whatever. People will use this if I can say, “Here, cut and paste this one line of code.”

But if trying new fonts requires connecting “style” references in disparate sections of code, this confuses people, and you won’t see as much adoption, creative implementation by non-specialists.

WRT licensing, the problem here is different to the one DRM usually tries to solve. Normally, DRM locks out the end-user from experiencing content they have sought and acquired, but haven’t gained the rights to experience. In this case, however, it is a class of content providers (web sites) that need to be controlled, with end-users invariably becoming unwitting cohorts. Perhaps a different solution is possible in this circumstance…

Designers could digitally sign and license font files on a per-web-site basis. Most web browsers would refuse to load incorrectly licensed font-files, and report the “fingerprint” of unlicensed font-files to a monitoring agency (mostly just a database that maps each licensed fingerprint to an owner/email). Of course, reporting would be at the users discretion, so designers working on and testing fonts could opt out, and maybe even store the fingerprint as “trusted”. Web sites, however, would lack the ability to control reporting, and would thus expose themselves to copyright infringement charges. The fingerprint could also serve to prevent a designer from defrauding another designer by acquiring digital signing rights for someone else’s font.

The only real sticking point is developing a robust fingerprinting method that survives font-tweaking by infringers. Some method that allows partial fingerprint matching and forces the infringer to materially alter the appearance of the font would be ideal. Normal digital “fingerprints” such as SHA-1 wouldn’t do.

Greetings.

Thanks for posting this screenshot. It’s subtle, but there is at least one difference: Safari’s interpretation of the margins / line-height of the drop-cap-glyphs. If you press ‘b’ on the page to turn on the baseline grid, the difference between the Firefox and Safari versions becomes much clearer.

Best,
C

(Safari 4 on the left, Firefox 3.5 on the right)

If you see any difference, please post.

Greetings.

Which leads me to an important rule they ignored: when performing keyboard handling, always check for modifier keys. Drop shadow shouldn’t toggle when the user wants to favorite your website, your numbers-only field shouldn’t block the user from pressing Ctrl-A, and so on.

Also: if you plan to use custom fonts, please use font-size-adjust. Watching the text jumping around when the new fonts load is very, very annoying.

Also, I updated to 3.5 to view the @font-face article correctly, and noticed that when I hit cmd+D to bookmark it, all of the text took on a shadow. It didn’t go away until I hit cmd+D again. I’ve never seen this happen before. It actually looks pretty cool, but what’s the story here?

I think that was a neat idea.

There is a malformed URI reference in the demo at line 49:

a href=”http://github.com/blog/363-cufón-a-sifr-alternative” Cufon /a

The o with acute accent should be escaped: %F3 is the correct way to do this.

HTML 4.01, section B.2.1 Non-ASCII characters in URI attribute values
http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars

regards, Gérard