Mark, I think the point is that even though Safari renders fonts beautifully, if you're building an application that requires those fonts be rendered the same way within multiple browsers then this is a fine way to do it. You did get that, right?
Buried in the trollicious rhetorical tactics evident here there is a kernel of truth. Web sites don't need to look the same in every browser, but maybe Web apps do. So when someone advocates a particular use case (like rendering text in Flash) they should specify whether they're talking about Web sites or Web apps.
Actually, in some adhoc tests, it's control over character spacing is pretty bad. Firefox 3 has the best control--you can tweak character spacing at the sub-pixel level, but not for Safari or IE.
Firefox also has very good default character spacing, whereas IE and Safari's was a little bit off of what it should be.
> Flash completely dominates CSS/HTML/JS for rendering text accurately
Except that the resulting rendering is an image so you can't copy and paste. I suppose some content providers will consider that a feature, but as a user it seems like a serious bug to me.
Then you failed to get your point across... Both of the demos you show may as well be images.
There's lots of other reasons not to use Flash, namely that its slow for lots of text, and it doesnt display anything at all on the iPhone and other mobile platforms. Using SIFR to replace headers is OK, but beyond that, I still hold that using Flash for text (on the web) is bad form.
Just the way it worked out. I had taken many screenshots along the way, but at the time I decided to write about my findings, I was in mid-refactor and had nothing that I could run.
sifr allows copy and paste fine. There is a problem with other browser-specific features though; the right-click options are provided by the flash app rather than the browser. (like firefox's "search in google")
There are a lot of cases where sifr doesn't allow copy and paste fine. Nowadays I run into it every day when I copy blog articles into Evernote. Depending how you do the text selection and what text you actually select, it doesn't work.
I will be glad when sifr is dead--hopefully it will be next year.
What? Sure you can--Flash is one of the only ways to reliably access the client clipboard. And if you're concerned about SEO of Flash content, display plain text to crawlers or read Adobe's SEO whitepapers: http://www.adobe.com/devnet/seo/
CSS/HTML/JS can render fonts perfectly if you use <canvas/>. The copy/paste problem can be solved using the HTML5 drag and drop API. (copy=drag, paste=drop)
To make sure you have the exact font, you may want to include the font file with @font in CSS.
Three reasons to dislike Flash text. First, it does not look native. I have certain anti-aliasing settings, for example, and Flash text looks totally different. Second, copy-paste, as others have pointed out, is a problem --- yes, it can be done, but enough apps out there fail to enable it properly, so it does not really work. Third, if I have browser plugins which operate on text, they break.
I don't think this point stands, or at least it doesn't in the way you think it does.
Flash has two text rendering modes: native, and embedded. Native uses the system API and follows your system options, like when deciding on how to antialias. Embedded uses the embedded fonts with the antialiasing method the developer chooses. Many developers pick the latter because they want to know exactly how text will work on all platforms.
It's up to the developer to select which method to use. And the new flash.text.engine.* API make both a lot more powerful.
> Second, copy-paste, as others have pointed out, is a problem (...) enough apps out there fail to enable it properly
Like the first one, this becomes a developer choice, not a platform problem. It's not that "it can be done", it's that it's easy. People who don't do it, don't do it because it's the option they've picked, not because it's difficult or anything.
Your third point totally stands as having a separate DOM kills the user's control over the content and its form. But point 1 and 2 are due to conscious developer decisions and not the technology.
PNG dominates CSS/HTML/JS for rendering text accurately too.
I'd prefer something usable. Something that matches the rest of my apps, and something that used the font sizes and types that I specified (I set a minimum font size so I can read the test, for example). This doesn't do that.
You're not honestly suggesting that developers start using flash to render their body content, are you?
Besides the copy/paste argument that people have already mentioned (yes, I know there is a "solution"). It's also inaccessible, takes longer to render and relies on a 3rd party product to render your website how you intended.
I know you'll probably say "give search engines and accessible-concerned folks a text version", but who honestly wants to maintain two different sets of code for ALL body content? And all just so the text looks a little better? Why not just tell everybody to use Safari/Mac?
Adobe has done a lot of work to make Flash "accessible," if the artist is willing to put some effort into it. And, once you make it "accessible," search engines (at least Google) will be able to index it.
Safari/Mac (really, any web browser) is a horrible for typesetting.
If you need a whole document to be predictable typeset, please give me a PDF. If you don't need it to be typeset perfectly, please give me HTML.
So I'm supposed to be excited at the prospect of ditching open web standards in favor of embedding proprietary Word into proprietary Flash for minor aesthetic enhancements?
Here is what I always wondered about...we are now on Flash 10...why hasn't Adobe figured out a way to make Flash more native to the main browsers out there? How hard is it really for them to add the right click options that everyone in the world relies on?
Seriously a few lines of code(yeah exaggeration I know), is keeping them from pretty much domineering the interweb design.
We're asking the browser vendors to expose their right-click events to plugins, to provide an API to opening up in a new tab, to open up their cookie preferences so that plugins can integrate user choice, etc.
There's no need to reflexively push back against Flash. You can learn it. You're not left out. You can open up.
Wait, what? You're claming that Flash renders text accurately by comparing it to Word? If we're going to create a new typesetting system, can't we at least compare it to existing typesetting systems that have had some professional design input? I hesitate to drag out TeX, but come on - Adobe InDesign, Quark Xpress, even Mac OS X's built-in CoreText/ATSUI rendering probably pays more attention to text layout and spacing than Word does.
I know Firefox's rendering engine put some effort into supporting the underlying platform's high-quality text-layout engine (for instance, Firefox will often use the 'fi' ligature if it's available), and this will only get better with time - unlike Flash, which will now have to maintain their exact layout system forever to maintain backwards compatibility.
This approach for text rendering should really only be used if there were some sort of graceful failover whereby another browser, lacking flash, would receive the text rendered as standard HTML. It would be foolish to use it otherwise.
There's absolutely no need for that trolling headline. What would have been wrong with "Flash enables perfect replication of Word's layout engine online"? Truthful and probably more interesting.
Glad you like it. The new Text Layout Framework does a whole lot more too... it brings the classic Adobe digital-text expertise right into 98% of the world's current browsers.
44 comments
[ 3.0 ms ] story [ 109 ms ] threadExcept that the resulting rendering is an image so you can't copy and paste. I suppose some content providers will consider that a feature, but as a user it seems like a serious bug to me.
The SWF in the article were two snapshots that I overlayed, one from Flash, one from Word, so it has no interactivity with the curser.
Truth is, it's entirely possible to enable text selection, if that were a real demo of the text engine.
There's lots of other reasons not to use Flash, namely that its slow for lots of text, and it doesnt display anything at all on the iPhone and other mobile platforms. Using SIFR to replace headers is OK, but beyond that, I still hold that using Flash for text (on the web) is bad form.
In hindsight, I should have used the real deal.
I will be glad when sifr is dead--hopefully it will be next year.
That's rubbish. You can't even select flash text + native text in the same selection. It's completely broken.
Also, flash bugs are platform specific. Like printing issues on firefox in linux, z-index issues on some browsers etc etc.
None of this happens with native text.
No? Then you're using it wrong. sIFR allows each of those features.
Spiders can't crawl it.
sIFR replaces text after the page has loaded. It appears no differently to spiders and search engines.
Users can't resize it so they can read it properly.
A valid concern, but it is likely fix-able. Assuming it hasn't been fixed already. I have no recent experience with this.
To make sure you have the exact font, you may want to include the font file with @font in CSS.
(and as soon as a good majority of folks are actually using those browser versions!)
I'm not sure where's the advantage.
I don't think this point stands, or at least it doesn't in the way you think it does.
Flash has two text rendering modes: native, and embedded. Native uses the system API and follows your system options, like when deciding on how to antialias. Embedded uses the embedded fonts with the antialiasing method the developer chooses. Many developers pick the latter because they want to know exactly how text will work on all platforms.
It's up to the developer to select which method to use. And the new flash.text.engine.* API make both a lot more powerful.
> Second, copy-paste, as others have pointed out, is a problem (...) enough apps out there fail to enable it properly
Like the first one, this becomes a developer choice, not a platform problem. It's not that "it can be done", it's that it's easy. People who don't do it, don't do it because it's the option they've picked, not because it's difficult or anything.
Your third point totally stands as having a separate DOM kills the user's control over the content and its form. But point 1 and 2 are due to conscious developer decisions and not the technology.
I'd prefer something usable. Something that matches the rest of my apps, and something that used the font sizes and types that I specified (I set a minimum font size so I can read the test, for example). This doesn't do that.
Besides the copy/paste argument that people have already mentioned (yes, I know there is a "solution"). It's also inaccessible, takes longer to render and relies on a 3rd party product to render your website how you intended.
I know you'll probably say "give search engines and accessible-concerned folks a text version", but who honestly wants to maintain two different sets of code for ALL body content? And all just so the text looks a little better? Why not just tell everybody to use Safari/Mac?
Safari/Mac (really, any web browser) is a horrible for typesetting.
If you need a whole document to be predictable typeset, please give me a PDF. If you don't need it to be typeset perfectly, please give me HTML.
Seriously a few lines of code(yeah exaggeration I know), is keeping them from pretty much domineering the interweb design.
There's no need to reflexively push back against Flash. You can learn it. You're not left out. You can open up.
jd/adobe
I know Firefox's rendering engine put some effort into supporting the underlying platform's high-quality text-layout engine (for instance, Firefox will often use the 'fi' ligature if it's available), and this will only get better with time - unlike Flash, which will now have to maintain their exact layout system forever to maintain backwards compatibility.
Why I don't like Flash.
Veronique Brossier has a good intro to it all: http://www.insideria.com/2009/03/flash-text-engine.html
More examples & info: http://labs.adobe.com/technologies/textlayout/
jd/adobe