One issue is that it creates an unintended "penalty" when the designer messes up or needs to revise whatever has been rasterized.

"100% of the web design community needs."

Not at all. An image instead of html text is...

- more troublesome for users to resize
- harder to select
- useless for body text (screen readers and google need to see text)
- a pain to maintain
- adds bandwidth issues

That's not to say that's not been the standard method up to this point, but it's a method that's definitely on its way out.

Rasterized text is so anti-web. Anti-accessible, anti-scalable, anti-searchable…
That's what we've had to do for years, and it's about time it ended.

- more troublesome for users to resize

Not really. All modern browsers resize images along size with the text. Not perfectly (no cubic spline interpolation), but very much passably.

- harder to select

Agreed.

- useless for body text (screen readers and google need to see text)

Not really, there is an alt attribute in the img tag and there's also that placing the text in the div with a very large offset and using the image as div's background. There's probably something else. Pre-rasterized text is nothing new and there is a set of SEO techniques for it.

- a pain to maintain

The pain is already there. See below :-)

- adds bandwidth issues

Agreed, though properly optimized PNGs will probably add up to significantly less than all the javascript bloat that comes with an average page nowadays.

--

I am not saying that this is a pretty technology. I am saying that there is a set of established practices that are lacking proper type licensing support at the moment. And that it is almost trivial to satisfy this need. Designers are getting an access to more fonts, foundries are getting additional revenue without releasing vector data, the web practices stay the same.

"All modern browsers resize images along size with the text. Not perfectly"

exactly. 12pt type as an image scaled to 24pt is going to look like crap.

"there is an alt attribute in the img tag "

There's various limits with the number of characters that can be used for that in both browsers and in terms of screen readers and SEO.

"Pre-rasterized text is nothing new and there is a set of SEO techniques for it."

And they are less than perfect once you factor in accessibility and usability issues.

"though properly optimized PNGs will probably add up to significantly less than all the javascript bloat that comes with an average page nowadays."

Most of the javascript (when properly implemented) would be cached from page to page. Custom PNGs would not.

It's not a terrible idea from 'can it be done' standpoint, it's just what we were doing circa 5 years ago. sIFR is a better option than that in a lot of cases, and @font-face is even better.

Having font licensing issues trump web site user's needs isn't very pragmatic, IMHO. Granted, I'm more of a web designer than type designer. ;)

> it’s just what we were doing circa 5 years ago

That's what we are still doing circa now. There is a lot of web designers that use pre-rendered text in their designs. What I have suggested is going to simplify their life, and give foundries more control over what's happening with their fonts in the online context.

I fully understand that rendering on the end device is far better than pre-rendering, and I do not disagree that latter is full of problems as per your list. Font-face adoption for the design (as opposed its support in browsers) still has a long way to go, and the pre-rendered text is here to stay for a while. All I am saying that there is no reason not to improve at least some aspects of it.

Sumner Stone has been arguing for something similar.

I think it should be noted that this raster idea is more of a business solution than a technical or an aesthetic solution.

Either the foundry/retailer has to set up some quite complex system for integrating these images with the customers' web page(s), or the customer will have to manually integrate every frickin' graphic, instead of the one-shot integration of the font rental CSS or Javascript code.

Then there's the whole scalability issue. Sure, graphics can be resized. But they will look icky.

I suspect that the perceived plausibility of this scheme is influenced by where you're coming from: Stuart at Font Diner almost exclusively works with unusual display faces that are only going to be viable for headlines and banners, not even really subhead material for the most part. But that's just one part of the overall font market....

Cheers,

T

Thomas, thanks for the reply.

The point I am trying to make is that the use of images for headers, menus, etc. is already an established practice.

If you look through a Creattica or PatternTap collections, you may notice how wide-spread its use actuallt is. For example, have a look at this site, which is quite typical as far as the use of technique goes. Even larger sites, like Jive and Akamai use it.

No reason not to offer a special font licensing option for these cases. There is a lot of smaller designer shops working on smaller projects that can't really justify paying $200 for a font family, do not really need the actual OTFs, but would gladly use it for their designs. Offering them rasterized option not only means a better looking web, fewer reasons to look at the piracy and an additional revenue stream for the foundries, it also builds the relationship with them and makes them more likely to purchase the real deal later on. Similar to how village does it with their "taster option".

You can have this today:
True Font Family
There's another site offering something very similar but I'm still looking for the link.

Worth checking out just to see. But not an answer to the question of typography on the web.

If you're looking for a headings-limited raster solution, Cufón is much more elegant. And in IE, it doesn't use raster - it uses Vector Markup and scales beautifully.
(In Webkit browsers and FF it uses the canvas tag and renders as a bitmap.)

Ah, found it:

Facelift

(Cool name, too.)

Same concept as True Font Family.

"The point I am trying to make is that the use of images for headers, menus, etc. is already an established practice. "

And is on its way out due to all the points already mentioned.

Web designers aren't really in any hurry to keep this particular method around.

> And is on its way out due to all the points already mentioned.

It may take several years for this method to actually cease to be relevant.

Even when the @font-face support gets all its wrinkles sorted out, the websites will still need to be designed for then legacy browsers such as FF3 and IE7.

Consider the situation with IE6. It was released in 2001, IE7 was out in 2006, and it is only now that some sites start to refuse IE6 clients. And that's not even a mainstream practice yet.

I know what you are saying. This is an ugly practice, doesn't scale, doesn't reflow, etc. No argument there, I agree.

I realize that this being Typophile, we tend to put a higher value on type, but I think, in general, most web designers are perfectly happy with graceful desegregation of @font-face selections to system font-stacks. That's still preferable over having to server custom images.

I think small sites will still be OK with the 'image as headline' option but since they're small sights, I'm not sure how much demand there'd be for online rasterization services for that. If I'm using a custom face on my site, I'd like want a license to it anyways for my print material.

I hate to shoot down the idea, I think it's something worth exploring, I just to clarify what the market demand might actually be for that before undertaking such a project.

@epsilicon

I've been looking at the source code for Facelift.
Thanks for posting this. I've become re-interested.
Just as the increase in bandwidth has made @font-face a viable proposition so too, might some of these image replacement techniques be worth a second look.
Some sites might not want to settle for the fallback font-family. On a well-optimized site the performance hit for this kind of stuff might be acceptable if not over-used.

Designers certainly want the kind of "graceful degradation" that fonts-as-images provide. But are they willing to put up with the unwanted side-effects?

>This is an ugly practice, doesn’t scale, doesn’t reflow, >etc.

It scales somewhat but gets fuzzy. However, if there were onzoom or ontextsize change events built into browser javascript engines a true re-scaling could be achieved.
(FF is finally, at least, providing a javascript property for detecting the zoom level. But no events as yet.)
I've done some research and proof-of-concept work on this aspect of scaling and browser capabilities.
Reflow can be achieved right now, using javascript and Ajax. Kind of a production, though. Don't know if it's worth the hassles. Easier to apply it only to short headlines far left aligned!

This as a service? Not optimistic about that, but who knows.

Rich

Personally, I would like it if in addition to the ambitious schemes still in development for web fonts, it were possible to use the standard bitmap font file formats that are used with Linux in conjunction with web pages. Yes, such fonts would not scale well, but at least it would allow people to draw their own fonts for use with their web pages without waiting for the development of new technology. Of course, that would have been even more true years ago, since now it seems like the web font standard is coming soon.

This thread made me think a little further about the case for using this technology which is on anything that doesn't support @font-face . . .

My thought is that you could have some javascript that detects the browser and an 'if all else fails' then the old standby's Cufon and sIFR- http://cameronmoll.com/archives/2009/03/cufon_font_embedding

I think a rasterized solution is likely plan Z . . .

Stuart

>I think a rasterized solution is likely plan Z . . .

You must not get out much, or do web solutions start at Z. ;)

Cheers!

Pre-Turkey Coma . . . :D

Plan Z = When all other options become unavailable and you don't want to lose the client . . .

:D

I hope you had a nice nap.

May I assume by "client", you mean the person who's hired someone to design their web site?

Cheers!

Indeed . . .

...then, if the term 'client' is shifted to mean the person who points their browser at a web sites, and you think about it as an web designing employee, and not a consultant, or web standards agitator: Plan Z, is great when all other options are risky and you don’t want to lose your job...:)

I mean, you can't count on quality text (or smaller), from @font-face fonts, without great care and testing, and even then, some clients... and, you can't count on quality headlines from @font-face fonts, without great care and testing, and even then, some clients...

Cheers!