Another Stab at Online Outline Fonts

orest writes "Microsoft took a whack at it with WEFT. Bitstream tried TrueDoc. But someone has finally gotten somewhere with sIFR. sIFR allows web designers to render font outlines -- and thereby their preferred fonts -- in a visitor's web browser, without those fonts being installed on the visitor's computer. sIFR relies on JavaScript and Flash to accomplish its magic. A similar, bleeding-edge solution exists in Batik, an open-source SVG browser from the Apache Foundation."

Comments

Anyone see a problem with this?

[Anonymous Coward]

Javascript has its uses and its abuses. For a lot of browsing, it's best to have it turned off. But what happens if you have to have it enabled just to read the text?

I wonder if it's a good idea to sacrifice security because a web developer is addicted to a certain font.

Re:Anyone see a problem with this?

[WarpFlyght]

You don't have to have it enabled. It degrades gracefully -- if JavaScript is disabled or if the user doesn't have flash, regular text is displayed. That's the big advantage, and that's why it works well enough to have "arrived." Users who don't want JavaScript enabled don't lose any content, but users who do (a vast majority) see the page presented as the designer intended.

Re:Anyone see a problem with this?

[CyberVenom]

That's not new either. In any page where I use JavaScript I make sure that things still function sanely, albiet not as prettily without JS.

One definate advantage I see here over PNG seems to be the ability to select (for copy-paste) sections of the text (and thus less difference from "normal" text as far as the viewer is concerned)

Personally, I don't like the overuse of Flash, but then again, most people out there don't care if their sites look good in eLinks. (yes, it actually bothers me when a site looks funny in eLinks... go figure)

Re:Anyone see a problem with this?

[eddy the lip]

Personally, I don't like the overuse of Flash, but then again, most people out there don't care if their sites look good in eLinks. (yes, it actually bothers me when a site looks funny in eLinks... go figure)

Not so strange...I always test in links. It gives me an idea how things will look to search engines, and is also a decent first pass at testing text-to-speech browsers. If it's an ungodly mess in links, it's going to be unintelligible when the computer reads it out loud. Glad I'm not the only one ;)

Re:Anyone see a problem with this?

[Watts Martin]

And making sites that don't like like shit is pretty non-trivial to people who put the word designer in quotes, like it's some kind of disease. It's this kind of "creative people are too stupid to learn standards" attitude that ensures designers aren't going to be listening to you, even when you're making sense.

In point of fact, all of Macromedia's products do make it pretty easy to create 100% standards-compliant web sites. Studio MX has its faults, but an inability to handle CSS and XHTML is not one of them. Many modern web sites that degrade gracefully all the way down to Lynx were created with some combination of Dreamweaver, Fireworks and HomeSite.

Granted, I only use Fireworks from those, and do the rest in BBEdit. Yeah, I'm on a Mac. It's sure difficult for an Apple zealot like me to use all of those fancy validation features, integrated HTML Tidy and the like, but somehow my little designer mind can get wrapped around it. Hyuk hyuk hyuk.

Re:Anyone see a problem with this?

[aWalrus]

These are the same people that are coming up with the w3c standards and trying to fix the mess that Microsoft and the browser wars put us in. Making their sites accesible to non-shitheads is also one of their biggest priorities (thus the focus on graceful degradation of techniques).

At which point did this place become troll-heaven? I have seen precious few informed opinions in this thread. Less so than in any other topic.

Re:Anyone see a problem with this?

[Niggle]

If you're running with something like Firefox's Flashblock extension then it doesn't degrade at all gracefully. You just get the usual click to play icon instead of the text.

I should add that whenever I install Firefox for somebody else, I always add this extension. 90% of flash on the web is used for ads that nobody ever wants to see. Most people are just amazed at how much it can speed up page loading.

Re:Anyone see a problem with this?

[Haeleth]

If you're running with something like Firefox's Flashblock extension then it doesn't degrade at all gracefully. You just get the usual click to play icon instead of the text.

They thought of that, as you'd know if you'd bothered to visit their site:

And hey, if you are using something like FlashBlock, which means you want to use Flash but only if it suits you, you may be interested in our Greasemonkey scripts which allow you to disable sIFR.

Re:Anyone see a problem with this?

[Anonymous Brave Guy]

If you're running with something like Firefox's Flashblock extension then it doesn't degrade at all gracefully.

If I configure a proxy to prevent downloading of image files, I can block most of the ads on the web, yet some pages do not display as the designer intended. Is that their fault for using images, or mine for deliberately blocking content that might be legit?

Re:Anyone see a problem with this?

[Anonymous Coward]

And making sites that don't like like shit is pretty non-trivial to people who put the word designer in quotes

No. A designer's work is defined by the strengths and limitations of the medium that designer is working in. A "designer's" work is defined by what he want it to look like on his computer, and if it breaks elsewhere, then tough.

It's not about disparaging designers, it's about recognising that some people really don't give a shit how others see their work, as long as it looks okay to them. Designers are professional. "Designers" are not.

Re:Anyone see a problem with this?

[Anonymous Coward]

Yeah. Well, I suspect sIFR was written by "programmers".

Using flash instead of images.

[numbski]

The only benefit I see to this is that it allows dynamic content where an image would have been used before.

I guess this is good, except I'm running flash click to play in Firefox, and have JavaScript pretty paired down.

This would count as a beneficial use of flash in my book. I've used WEFT and Bitstream's solution. Never did work in Mozilla. :\

If this will work well, then I'm all for it.

Re:Using flash instead of images.

[Anonymous Coward]

it allows dynamic content where an image would have been used

Images aren't always static. Welcome to CGI 101. Flash is no different from a gif in this situation.

Unless you meant to say interactive. But you should have said that if its what you meant.

Old news

[__aafkqj3628]

sIFR has been around for ages now! Why is it only just making it onto here and being touted as "finally" being here?
(That is, if this isn't a dupe from something months ago).

Mainstream Usage

[WarpFlyght]

sIFR has come far enough to be used on major websites. Aside from seeing it in places like one of the website of the person who perfected it, it's also appearing on mainstream websites -- take ABC News. Their headlines are rendered using sIFR for browsers that support it.

Re:Mainstream Usage

[Anonymous Coward]

sIFR has come far enough to be used on major websites.

Yes, and it's fucking annoying. It breaks my scroll wheel. Text selection "works" in the sense that the text gets selected, but there's no visual feedback (i.e. the background changing colour). Right-click menus break. Middle-clicking to open in a new tab/window breaks.

The basic technology is a neat hack. But it's riddled with so many little things that go wrong, it's just not good enough to be used by mainstream websites.

Png?

[NotoriousQ]

And how is this different then just sending a png with the text. I guess it could then be dynamically sized -- but somehow I think that even Flash will have a hard time figuring out if I like my fonts triple sized.

Re:Png?

[__aafkqj3628]

Because this doesn't require you to either create a PNG file for each title you want and/or use a server-side script to try and dynamically generate the PNG.
sIFR takes whatever text already exists and feeds that to a flash file that will format that text (size it up to fit, link it up, etc.) as needed.

Re:Png?

[CyberVenom]

same idea, just done client-side, which saves bandwidth.

Re:Png?

[JaseOne]

But what is bigger the tiny png's or the Javascript + whatever else this requires?

Re:Png?

[WarpFlyght]

It's different because it degrades gracefully for text-only browsers and screen readers. As I recall, the JavaScript estimates the size of the headline based on your font settings and renders the headline accordingly, so people browsing with their font size at extra large aren't affected.

The only time it doesn't work for triple-sized fonts is if you adjust the font size while viewing the page. The JavaScript runs on page load, so you'd have to refresh to get the increased sizes to be reflected by the Flash headline.

Re:Png?

[CyberVenom]

smaller? in the long run probably the flash+JS, since the flash and possibly even most of the JS can be cached once and reused for all the different titles. just a single call to the cached JS routine and cached flash file with a font name and text would be enough. (say 100 bytes of data for each call plus maybe 100k up front for the flash app and JS routine?)
conversely for server-side PNG, each string of text would require an entire graphic to be sent. (at least a few kB of data for small monochrome images, and more for large or anti-aliased images)
hopefully the flash and javascript are small enough to make this sort of caching worthwhile.

Re:Png?

[Anonymous Coward]

It's different because it degrades gracefully for text-only browsers and screen readers.

So do normal HTML img elements. No need for non-standard hacks like this.

how is this new?

[Anonymous Coward]

After reading the fsking article, this is a technology intended mostly for doing headlines and things with flash. Fed apperently by javascript variables, the flash components render the requested text. OMFG, it's a revival of the old-skool Java headline scrollers, minus the scrolling... bleh.

Huh?

[Look KG486]

sIFR relies on JavaScript and Flash to accomplish its magic.

I patiently await the next article.

ironic

[same_old_story]

this is kind of ironic actually.

anybody that does lots of flash design will tell you, flash is a pain in the ass when it comes to type...
granted, using your font of choice is great for design, and a huge improvement over html's font families, but flash has lot's of problems with text rendering, sometimes smoothing too much or sub pixel positioning quirks. these issues can be avoided, but still photoshop, for example, renders much better looking type.

I guess when we get flash's new text rendering engineon the next flash player version, this will improve...

Re:ironic

[jonadab]

> granted, using your font of choice is great for design

On the web, it's great for *bad* design.

On paper, it's different, for a couple of reasons. For one thing, the users can't possibly substitute their own preferred fonts into a paper publication, so the only two options are for the creator to choose nice ones, or for the creator to choose ones that aren't very nice (*cough* Times), don't go well together, or cetera. But there's another difference: on paper, the text is rendered to a much higher resolution, which makes it practical to use some fonts that are a decidedly bad idea on the web -- script fonts, for instance, can be tastefully used in a print publication, but on the web, for the sake of legibility, you're pretty much limited to a basic serif font, a basic sans, or something fixedwidth, unless you're doing just one or two words (in which case, .png works okay). Anything else and you either have to set the point size so high it looks rediculous, or else the user's going to have trouble reading it.

This goes in exactly the same category as every other use of Flash: ways to gratuitously make the web uglier, while at the same time also making it harder to use.

Accessibilty?

[CableModemSniper]

Can screen readers and the ilk handle this stuff? Also doesn't it kinda give a big FU to my userContent.css font settings?

Re:Accessibilty?

[WarpFlyght]

Yes, screen readers can handle it. The text remains in the HTML, and the JavaScript just creates Flash headlines containing it on the fly for user agents supporting it. One of the most important advantages of sIFR over PNG/GIF headlines is that the original text remains with no trickery, so it's 100% accessible for people with disabilities and for text-only web browsers.

As for your custom font settings, yes, I suppose it does, but so do PNG/GIF headline images. If you disable JavaScript or Flash, you should see your preferred font.

Prior art

[dr00g911]

Meh, nothing to see here.

I hacked up this solution to auto-generate 'pretty' page titles for CMS-driven websites *many* years ago. Mine didn't require Javascript.

Course, I didn't give it a spiffy name, apply for a patent and file a press release on discovering the obvious.

Option 1:

Step 1:

Embed font in question in sized Flash title block area, create variable text field named titletext

Step 2:

Embed Flash applet in page, and add titletext=whatever into your embed and object code. Whatever being the current page's title, etc, pulled from CMS.

The cool part about this is that the flash title block is *tiny* and remains in cache.

Option 2 (server-intensive):

Have the server generate ImageMagick-based gif or jpg titles after uploading your fonts to the server.

Re:Prior art

[aWalrus]

Care to provide an example?

And sIFR has been around for quite some time too. And it's not patented. And Shaun Inman came up with, a lot of people have worked on it since. And there was no press release.

Other than that, your post is pretty accurate.

a real challenge

[CyberVenom]

Ok, so who wants to one-up this and write a full-featured text-rasterizer in pure JS?

I propose a JavaScript that can load a server-side TTF file (or OpenType or whatever) and walk the DOM, reading the CSS font name, and replacing the normal text with a rendering of the same in the specified CSS font, but rendered by the JavaScript instead of by the browser so it is gaurenteed to be done right. Of course, if the user has no JS, it will fall back to the CSS font names (which require the user have the font installed) and if the user has no CSS, it will fall back HTML 3.6 fonts.

The wheels in my head are already turning...

Oh, and before any of you leeches goes and patents it, I hereby declare prior art on the concept, so there!

Re:a real challenge

[aWalrus]

The reason no one has done that is... you can't.

Javascript cannot "render" a font that the client does not have. Javascript is executed in the client. What you suggest would only be feasible by rendering an image with the font using server-side language (which some people actually do, but I don't think it's worth the trouble).

In other issues: seriously, is there so little overlap between the web design community and Slashdot? sIFR has been around for ages, and the submitter didn't even credit Shaun Inman with coming up with the method. It's quite useful and downgrades gracefully. Not my cup of tea, but it's done wonders for designers everywhere.

SVG approach more interesting

[uradu]

I find the SVG approach more interesting because it's an open solution (well, except for the various viewer implementations at the moment). I don't necessarily see how the Batik viewer comes into this though, because their sample font demos work just fine in the Adobe viewer also.

This technology is interesting way beyond just the web. It could be used by organizations that require a consistent platform-independent representation of critical documents. Currently PDF is often the choice for that sort of thing, and probably will be for a while because it is mature in both display and printing. But having SVG become a viable option together with better viewers, or even browser-integrated SVG capabilities, can only be a good thing in the long run.

Re:SVG approach more interesting

[Anonymous Coward]

I don't necessarily see how the Batik viewer comes into this though, because their sample font demos work just fine in the Adobe viewer also.

Presumably it's a reference to the fact that Batik is written in Java. I suppose theoretically, you could do the same thing with Batik in a Java applet that sIFR does with Flash.

mask email addresses from spam target harvesters..

[Anonymous Coward]

Could this be used to mask email addresses from email address harvesters?

Re:mask email addresses from spam target harvester

[WarpFlyght]

No, because the text remains in the HTML file.

Meh

[macshit]

I just checked out the website someone cited which uses this stuff, and ... well, maybe it's better than other attempts to do the same thing (like "put all text in a image"), but it's still pretty lame.

Like most other solutions to the "control-freak web designer problem", it seems better suited for a demo than for actual users. For instance, cut-n-pasting the text: it has some clunky emulation of cut-n-paste, but it's obviously an emulation, and doesn't integrate well with the environment. It also has the "flash capture" problem, where flash will grab mouse events you don't want it too -- e.g. if you're scrolling along with the mouse-wheel, and scroll past one of these dynamic font flash thingies, wham! your scrolling stops, as the flash instance grabs all the scroll events.

Morever, I think any technology which is being touted as a tool to give the designer more control over the fine details is a double-edged sword, as there are so many completely awful web-page "designers" out there, who are none-the-less still utter control freaks. If the technology in question still allows proper user control and overriding of the web-page, and integrates well with the user's environment (e.g.: css), then fine, but this "fonts as flash" stuff seems to be typically lacking in that regard (which is not surprising because flash itself is a major offender).

Wow

[Hard_Code]

I'm consistently impressed at the amount of effort poured into seemingly trivial hacks - not in the difficulty or complexity of the hack, but in it's shallow utility.

Either people are paying web "designers" to do a whole lot of nothing, or there is some screaming need that really calls for IETF/W3C to fix this properly.

Disabled people use computers too :(

[applegoddess]

Honestly, I think this is an excellent use of JavaScript (and the whole reverting to good ol' CSS if javascript is disabled thing). It gives control of layout to the designer, but you can't forget the disabled users. They exist, just like you and me. I volunteer to help blind people, and you won't believe what a pain in the !@#$ jaws for windows, voiceover for OS X and speakup for linux are when it comes to surfing the web...all because some developer wanted to use some font he/she liked and implemented that by using flash or putting some stupid image as a replacement (and often forget to include the alt attribute, which noone seems to really use *frown*).

I can't thank people like the sIFR devs enough for trying to make peoples lives easier.

Firefox flash blocker

[JavaRob]

I guess this is good, except I'm running flash click to play in Firefox, and have JavaScript pretty pared down.

Me too -- and it sure plays hell with sIFR. It detects that I don't have Flash activated, so it displays the CSS-rendered text. Then I click the Flash box and see the sIFR-rendered text, also.

Personally, I don't think it's the fix to browser fonts. Clever hack, yes. Solution, no.

I do have the feeling we're not far off, though. Actually, here's one way you could do it -- generate a gif for each word, with the "alt" tag being the actual text. Then highlighting works, cut and paste works (cut and paste the Right/Left graphics from Yahoo driving directions if you don't believe me)... it's just slow to load the page and render, and the user is screwed if they want to resize or set their own stylesheet.

I feel like there are a lot of pieces lying around, but no full solution yet. We may just need universally-supported, load/render on-the-fly fonts... someday.

Flashblock anyone?

[bertilow]

It obviously didn't occur to the sIFR people to test this "solution" in Firefox with the Flashblock extension installed. Why am I not surprised?

Re:Flashblock anyone?

[bertilow]

Anonymous Coward wrote:

it obviously didn't occur to you to test your "theory" in Firefox with the Flashblock extension installed. Why am I not surprised?

No theory. Observation. I do use Firefox with the Flashblock extension installed all the time. I checked out some of the pages that use the sIFR "solution" (e.g. "www.sixapart.com"). The text was blocked, and no fallback was shown. When I turned off JavaScript, the text however appeared. sIFR is flawed.

Re:Flashblock anyone?

[Anonymous Coward]

I reported this bug to them, and was fobbed off with "don't use Flashblock then".

Re:Flashblock anyone?

[Anonymous Coward]

The next version of flashblock (1.3.1) will probably be sIFR compatible. Right now we have a release client that isn't quite ready to go that will allow sIFR to think that flash is not installed. We still have a couple things to work out to make sure that flash will still be blocked properly even when sIFR is fooled (so no one can fake the plugin out and display flash anyway). Expect it to appear within the next couple of weeks.

Suck my dick anyone?

[Anonymous Coward]

it obviously didn't occur to you to test your "theory" in Firefox with the Flashblock extension installed. Why am I not surprised?

Multiple PNG?

[SanityInAnarchy]

How is that different than using JavaScript to put together a bunch of PNG images (one per letter) for each title?

Anyway, the older technologies seem much better, and/or using some form of SVG + JavaScript. Flash is zombie technology -- it's dead, but people use it anyway.

Re:Multiple PNG?

[__aafkqj3628]

How is that different than using JavaScript to put together a bunch of PNG images (one per letter) for each title?

Because then you can't control kerning, leading (with more than one line), ligatures, size or anything to keep it from looking like absolute crap.

Ugh!

[Frodo Crockett]

The examples look awful if you have adblock enabled!

Oh no...

[seanellis]

I get enough e-mails at work (in Outlook, so I can't actually override this) which use Comic Sans, 14 point, purple-on-yellow, without the web designers being able to force this on me as well!

(I know I can turn it off; I'm just ranting.)

It uses flash? it uses flash?

[tod_miller]

In flash you can embedd the font anyway.... this is a bastard child solution.

Use flash, or don't. Otherwise the existing 'problem' isn't a problem, I have installed the fonts I want, use them.

Browsers could have a font api... but can you imagine the design travesties?

eurgh!

Re:It uses flash? it uses flash?

[ESqVIP]

In flash you can embedd the font anyway.... this is a bastard child solution.

But that's exactly why they use Flash to reach their goals.

Use flash, or don't. Otherwise the existing 'problem' isn't a problem, I have installed the fonts I want, use them.

I don't get your statement. Would you prefer having Flash every time a webdesigner wants fancy fonts? This solution allows text in custom fonts proportionally sized to the viewer's display (opposed to standard fixed pixel-defined size), while still maintaining accessibility. If eye-candy is the intent, I do find this one a quite clever hack.

It seems to me you didn't understand what the article was all about.

Re:It uses flash? it uses flash?

[tod_miller]

No I understand, and I have seen this in the field. Little adblock tags on my page. It sucks, use a graphic or stick to my fonts, that is me talking as a power user (someone who wants control).

I see that is works, yes fine, I am not condemning the technology of the solution, but redefining the fact that not having the right fonts isn't a problem (for me).

Anyway, it is a hack, surely the efforts could have been made to foster the liveFonts initiative? Was this badly written? patented? I don't know, but I understood what this was about.

Re:It uses flash? it uses flash?

[ESqVIP]

I see your point now, and it's like they said in an earlier comment... sIFR doesn't interact well with flash blockers (and now that you mention, Adblock tabs -- I have disabled the tabs long ago because of how annoying they got on pages with several flash objects, and completely forgot about them), and that's why I too agree it's just a clever hack, not a final solution.

Btw, thanks for being nice and writing an intelligent post. After my last paragraph I was afraid of ignorant replies :-)

Good point about accessibility

[Anonymous Brave Guy]

It gives me an idea how things will look to search engines, and is also a decent first pass at testing text-to-speech browsers.

I was going to raise the accessibility issue, but you beat me to it.

One of the problems with using images for text is that it makes it very difficult to render properly in a non-visual browser. Even with alt tags, you don't have the usual accessibility-friendly CSS to indicate whether things should be read normally, spelt out (as for abbreviations), etc.

It would be nice if a future (X)HTML standard could provide a slightly more general "accessible alternative" for non-text data, be it images or embedded content like Flash. At least then those who are visually impaired would have a fighting chance of understanding the content. In the meantime, I'll take an approach that at least degrades gracefully because the text is in there somewhere.

Re:Good point about accessibility

[Anonymous Coward]

One of the problems with using images for text is that it makes it very difficult to render properly in a non-visual browser.

It's dead simple. Supply some alternative text in the alt attribute. User-agents that don't load images use the text instead.

Even with alt tags

There's no such thing as an alt tag. Not everything remotely related to the web is a tag. In this case, it's an attribute.

you don't have the usual accessibility-friendly CSS to indicate whether things should be read normally, spelt out (as for abbreviations), etc.

Huh? Aural CSS is implemented in Emacs-W3, and no other user-agent on earth. There's nothing "usual" about it.

It would be nice if a future (X)HTML standard could provide a slightly more general "accessible alternative" for non-text data, be it images or embedded content like Flash.

Define "more general".

In the meantime, I'll take an approach that at least degrades gracefully because the text is in there somewhere.

sIFR breaks browser features and makes headlines disappear in common configurations. It does not degrade gracefully.

Done better with images

[jaques]

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

The above works better IMO as it uses plain old images to do the job (I dislike flash), plus the markup does need to inlcude these messy tags - it just uses the element text.

e.g.

<h1>Some Heading</h1> is auto-replaced by
<h1><img href="generated_url.png" /></h1>

where the generated img contains the text "Some Heading" in whatever font you use.

ok, so there's a performance hit, but images are cached, so its only for the first viewing. The real beauty of it is you just have to chance the text and not worry about the font! Magic

Re:Done better with images

[IronicCheese]

Images don't resize with the browser.
Images can't be selected and pasted as text.
Images can't be read by external devices for accessibility purposes.

There are huge tradeoffs to using images, which is why people keep trying to do find a real text based solution to the font problem. Images are just a hacky solution.

Re:Done better with images

[jaques]

> Images don't resize with the browser.

Flash doesn't either, AFAIK. Quick test confirms.

> Images can't be selected and pasted as text.

True, but again neither can flash.

> Images can't be read by external devices for accessibility purposes.

Again, true, flash wins in this case, although its not easy I suspect. Are there accesibility tools to render flash as html or similar?

However in the case above, accessibility is well catered for as if images are not supported, the plain html is used, which is exactly the same content as for with images.

My point was that this uses flash, which is not great, I'd prefer to use images. It also involves a lot of extra markup to the html, which is not necessary with the above method. However I agree it's a hack until svg fonts or similar are available.

SVG is more appropriate

[MoogMan]

I would personally say this kind of thing is exactly the purpose for SVG. I also believe that change and innovation has to come from drive either in the web browser or on popular web pages. I don't mind upgrading my web browser for enhanced features... thats intuitive really.

So hopefully, new versions of web browsers (IE) will have proper SVG support, and web designers will adopt SVG - as opposed to Flash, as I believe Flash should be more of a peripheral function (along with Java applets), rather than core functionality.

This is not the solution you're looking for.

[Anonymous Coward]

Honestly, Inman image replacement techniques work fine for the present state of the web. But what we really need is better font support in our browsers.

h1{ font-family: url("my_font.ttf"); }

All the W3C would need to do is add support for the above. CSS also has a history of degrading gracefully, as anything not understood doesn't cause the browser to do anything unexpected.

Re:This is not the solution you're looking for.

[bedessen]

Something simple like that would never happen. The reason is because if the browser just requested a standard .ttf file from the server and used it to render text, there would be no protection from the user keeping the .ttf file and having a new font. It sounds ridiculous, but high quality .ttf files cost money and you're not allowed to distribute them (just like software.) Go check the price on the Adobe Font Folio. The font bureaus would scream bloody murder and start suing anyone distributing those unmodified .ttf files.

There have been several methods in use for many years of "bastardizing" the font file so that it either contains only the specific glyphs needed for the text (so that it's useless as a general purpose font) or by including some kind of DRM so that the operating system will not allow it to be installed as a general purpose font. But they never really caught on for obvious reasons.

[TT Fonts] is more appropriate

[Anonymous Coward]

I see it as pointless. In case everyone's forgot. TT Fonts are splines with hinting. Send the fonts needed, and let the client handle it.

But Macromedia is evil incarnate.

[Anonymous Coward]

I mean as a corporation, not the products. The problem is precisely that the products they dominate with cruel, calculated precision are precisely the ones that should be open.
They leverage their core SVG position into educational markets and they're probably the one reason major reason that American education is the last place on earth you're ever going to see open source. It will happen eventually, but that will be the last bastion of closed source and that is not only ironic but a sad condemnation of American values.