looking for ttf-based heading plugin

Can you please give us the link to the List Apart plugin? I’m not familiar with it.

Never heard of something that uploads each letter as a JPG. That’d be an extreme resource hit on client and server.

I know of two approaches. One is mostly server-side, uses ttf’s on the server, live generates a jpg or gif or whatever using php and gd graphics functions like https://us3.php.net/imagettftext. The headings are cached, and only if the cache is stale or otherwise detect that the graphic no longer matches the text does it regenerate.

Second approach is client-side, using flash, known as sIFR — my CG-FlashyTitles plugin was designed around that. You create a SWF ‘font file’ (to sIFR specs) which is on the server, and JS on the client retrieves the font and runs ‘replacement rules’ on certain CSS tagged elements on the page. I’ve seen some hacked versions (of sIFR) vary the color of individual characters.

-d

Is one of these approaches more efficient than the other?

BTW, I knew I had downloaded a plugin that did this and I found it here.

Yes, coldforged’s headlines plugin is the former type I outlined above.

There’s actually a third (though I haven’t seen it for WP), which is a JS image-replacement method, but uses a graphic off the server.

The advantage of the server-side stuff is you just drop some ttf’s into a folder on the server and it’s pretty much ready to go. Also can easily add coloring, drop-shadows, and other post-processing effects. The downside, however, is that it isn’t super SEO-friendly to do titles as graphics (even though as links the link title would give some SEO info).

The advantage of client-side is that the search engines/bots all just see the source textual representation — the transformation to ‘graphics’ happens in browsers with JS support. It’s also less workload on the server, as the font(s) are downloaded once, then used for every title/heading needed, versus a custom image for every possible title. Lastly, newer versions allow text selection, as if it was really just normal text. The disadvantage of sIFR specifically is the generation of font files (though you can download pre-made files), and that sIFR 2 had limited visual features. The upcoming sIFR3/FlashyTitles3 uses newer tech, fits better into page flow, and can do anything Flash 8 tech can do (i.e., shadows, knockouts, emboss, glow, etc., etc., etc.).

So, really depends. ?? But anyone doing heavy SEO work will avoid server-side-only solutions when possible.

-d

Thanks for the explanation. I did install the coldforged plugin to see what it did on my local computer. It does work quite well, although I don’t think I’ll put it on my live site at this time.

https://www.alistapart.com/articles/dynatext

Yes, the first example in the ALA article is what coldforged does. The second example is why I defined as the ‘third case’, a client-side JS replacement via images.

I should note there are further advantages to the sIFR replacement, including things like text wrapping (which sIFR2 didn’t do great, but sIFR3 does an awesome job at fitting the text to the allowable space). The image-based replacement (JS or server-side) techniques don’t have that level of intelligence/flexibility.

i.e., you write a long headline, and it runs on over your sidebar as a PNG, but as flash the box height can be expanded so that it wraps to a second line (or third, or…).

-d

I just did a test with a long post title and it word-wrapped perfectly with coldforged’s plugin.

Yes, so long as you pre-specify the max_width (or length, depending on terminology) of the title block. That’s fine for fixed-width, not for fluid-width designs. It also means you have to tweak the settings if you tweak your design/width at all…

I’m not by any means saying that coldforged’s plugin is bad — it isn’t! Does a great job for non-coders to get stylized headings. I think I pointed out the pros and cons of each approach… ??

A JS-based variant of image headlines would probably work very well, given it could instantly take into account the box width to fit to. But that still means per-title image generation and downloading, versus per-font downloading for a sIFR-based approach.