But I still say that the introduction of the iPad is a signal of doom for Flash-as-a-format. On the other hand, as Adobe gets more serious about producing HTML5, SVG, Canvas, JavaScript from their Flash IDE, well…

Don’t worry, Flash isn’t dead yet, but it’s clear that the tides are changing these days, with more devices entering the market that do not (and cannot) have Flash installed. Frankly SWF is no longer the reliable format it once was. Yes you can reach 90+% of the desktop browsers, but what about the millions of mobile web users?

So lots of people have had the same idea: Adobe needs to update its tools to output in Open Web formats. Simple, no? Instead of Save As SWF, Save as Web App, right?

“But wait!”, I hear some Adobe lovers cry. Rendering across browsers isn’t consistent! The DOM is a mess! There are tons of CSS layout bugs! SVG/Canvas support across browsers is uneven at best! There are many features that aren’t even supported in some browsers yet!

Hogwash. OpenLaszlo foresaw this transition years ago. GWT does the same thing.

You Adobe folk are bright engineers. You just have to make it work. Exactly like you made it work, and continue to make it work, across Windows, OSX and Linux graphics systems. The rendering layer is at the browser now, not the operating system.

There are lots of JavaScript frameworks that help to smooth out the script and DOM bumps. There are tricks you can do until SVG/Canvas feature X is consistently supported. Someone already figured out how to render SWF files using SVG+JS, for goodness sake.

And guess what – two of the major browser engines are open source – which means if a particular feature is missing in those implementations you can put an engineer on it for two months so that in the next version of the browser, it will be there for you.

You just need to think ahead.

As I’m sure you are.

At the moment, the issue is dead in the water. Ian Hickson suggested that query parameters could solve this issue. However, query parameters are part of the URI. In my experiments with PHP, I found that query parameters are a good way to ensure the browser actually re-fetches a document and doesn’t rely on the document in the cache. This means that using query parameters would defeat one of the purposes of parameterizing the SVG in the first place (one document in the browser cache that could be used for many purposes).

It’s sad because plugins like Flash have the luxury of being able to pass parameters into their content, but we can’t do that for content the browser understands natively (like SVG and HTML). I failed to convince the benevolent dictator that this is an important capability that the open web stack lacks.

I think this would be a nice way to turn bits of HTML/SVG into simple components without requiring script on the embedding side and without requiring heavier technologies like XBL and/or waiting for browser support of postMessage(). For example, it seems like web page authors using things like Adsense could benefit from this by not having to include foreign script in their pages, but apparently Google has no interest in this.

Eric Meyer’s link-anywhere proposal inspired me to at least float this issue in my blog in case someone else thinks it important. For now, I’m tired. Hm, I wonder if I can use the window.name hack…

Speaking of plugins, I’ve been watching this guy continue to improve his SVG viewer (a SWF file that runs in Adobe’s Flash player) with about an update per week. Interesting idea (which has been pursued before incidentally). I’ll be really impressed if he can get the thing to a point where SMIL and scripting can be implemented.

Still, nothing beats some type of native support. In the meantime, I’d even accept ‘native’ plugin support from the big stick-in-the-muds. I still haven’t ruled out the idea that one day in the future, the Silverlight or Flash plugins might suddenly be able to render SVG directly, with no translation step in between. Here’s hoping for Flash 11 and Silverlight 3… Why not? They both already support a scripting engine, interactivity, XML parsing, animation, vector graphics, gradients, etc. Hm, why not, indeed.

Caveat: I’ll be the first to admit I have zero experience with AIR (or Mozilla Prism for that matter), so if anyone can educate me, please feel free below.

If I’m a desktop application developer, I’ve got to decide on a language and framework. Is it easier to build an application using HTML+CSS+DOM+JavaScript (+SVG+XUL) or to use Flex+ActionScript or to use C#+CLR or to use Java+JDK or to use C++ with Qt/Gnome?

I think Adobe is right that picking from the “Open Web” stack is a slightly easier in-road to application development due to the declarative nature of the markup and the lack of a compilation step. But I don’t think it’s why web applications are seeing such an upsurge. To me, the answer is the complete lack of a need to worry about deployment (web app developer) or installation (web browser user). The fact that the web app developer does not have to maintain older legacy code is also a huge win. Once a new version of your application is released, no one in the world is using your older code, it’s instantly retired.

Here’s a snip from AIR’s own documentation where it states:

“On Mac OS, to install an updated version of an application, the user must have adequate system privileges to install to the application directory. On Windows, a user must have administrative privileges.

If the updated version of the application requires an updated version of the runtime, the new runtime version is installed. To update the runtime, a user must have administrative privileges for the computer.”

To me, the bits about the runtime sounds like the same sort of mess that Java and .NET application deployment have with mismatched JREs and CLRs for the past decade. Hopefully changes to the underlying platform are kept minimally disruptive – but the developer really has no control over that.

It does sound like Adobe is trying to make it easier for application developers to employ auto-update functionality (incidentally, so is Sun). It just sucks that each developer has to worry about this individually still.

To me, the sweet spot with these Light-weight Offline Application Frameworks (LOAFs?) will be when enabling auto-update is as easy as it is with Firefox extension development. But that still doesn’t solve the problem of every user having to first download the runtime to ‘bootstrap’ him/herself.

And yes I’m aware that there are some big down-sides to Web Applications. Lessee, differing behavior of platforms (user agents) is the biggest cost. Lack of local storage (which may change in a decade with HTML5) and the cost of a server are also biggies.

• Wikipedia’s adoption of SVG as preferred image format
• Browser take-up of native rendering: Opera, Webkit, Firefox
• Platforms like Qt and Gnome continuously improving support for SVG
• Mobile industry take-up of SVG as the graphics format of choice (even mandated by 3GPP in Europe)
• Continuously improving tool support: Inkscape, NetBeans, Xara, Sketsa, GIMP, Ikivo
• Toolkit and CMS are now starting to take-up SVG: dojo and drupal
• Lots and lots of Free Clip Art (woops, the secret is out)

It’s definitely a different world than it was 3-4 years ago. I don’t think there’s anything stopping the SVG train. Based on this, I think Microsoft and renewed Adobe support of SVG is inevitable. It’s just sad that we’ll likely have to drag them kicking and screaming (and only after Silverlight gets decent penetration, probably).

The CVS Quick Reference Card is a 3-columned, 2-page document consisting of 99% text, 2 horizontal lines, 2 vertical lines and a couple bullet symbols. Here is a screenshot of the top-left of the document:

Looks nice. The PDF weighs in at 84kb. Not bad, really. But what I want to do is add a couple more items to the cheat sheet and send it back to Laurent (like cvs annotate for instance). This is not easy with a document in PDF format. These are the types of modifications that I’d like to do to PDFs every once in awhile and it’s why I consider PDF more of a closed “publishing” format than a true collaborative document format. I can see the appeal of an electronic document that you know cannot be changed, but for my day-to-day use such documents are far and few between. Plus I just can’t stand the Acrobat Reader, I’m sorry.

Adobe Output

I was surprised to see a variety of formats listed in Acrobat Professional under Save As (though unsurprised that SVG was not present). I decided that since I recently started experimenting with GTDTiddlyWiki on my thumb drive for note-taking, that I would keep everything HTML-browser-centric and settled on the format “HTML 4.01 with CSS 1.0 (*.htm, *.html)”. What’s the worst that can happen?

Well, the first thing that happened was I got back some errors saying that some of the glyphs could not be converted. Ok, I can live with some glyph funkiness.

Then I brought up the resultant 249kb .htm file in Firefox and was dismayed to see it was not at all laid out in the nice 3-column layout of the PDF. This pretty much makes the HTML+CSS output from Adobe Acrobat unusable.

Then I looked at the source and was a little dumbfounded:

Maybe someone understands the logic of how contiguous text is broken up into many <span> elements with the same style, but I certainly do not.

I tried Plain Text – not a very legible document (well, at least not the nice 3-column layout of course).

I tried PNG – good but each PNG page was 2339×1654 pixels requiring some manual scaling down for readability on my screen.

I tried JPG – good, but fuzzy if not fullscreen.

In fairness to Adobe, the RTF output was pretty legible and only 44kb.

SVG Output

So then I thought – I’m already half-into this, let’s try to get a decent SVG out of it.

I was going to try Inkscape, but their PDF Import feature is still not there yet. Too bad.

I next tried the evaluation version of the PDF2SVG command-line tool. The SVG output was two pages, totalling 526kb uncompressed. Bringing it up in the best available desktop SVG viewer pretty much crippled the browser (extremely sluggish) and resulted in the following:

Firefox and Safari were worse.

I then looked at the SVG source:

Next up was matterCast’s SVG Imprint. The output clocked in at 334kb uncompressed. The SVG was similarly mangled with <tspan>s breaking up the text as above. Finally, they didn’t produce valid SVG (the root <svg> node was missing the namespace declaration: xmlns=”http://www.w3.org/2000/svg”). Once I fixed that, the files looked similar to the above, though the browser wasn’t as sluggish.

I then found this service which converts submitted PDFs to SVGs and then sends you a link for free. It’s really a promotion of its TextCafe conversion product which sounds nice in theory, especially the “Detection of text blocks and paragraphs, which can be reflowed automatically”. I sent the PDF to them and didn’t hear anything back for an hour. So I emailed them and got a response from Martin Hensel that it takes 6-12 hours. When I got it, it was a zip file containing an HTML harness and some SVG, JPG files. The SVG files have the same problems as other similar tools – basically a whole bunch of <tspan> elements instead of text blocks. The HTML harness is kind of a neat idea because it provide bookmarking/search pane similar to Acrobat Reader (provided via JS). However, the HTML harness insists that you have to install Adobe SVG Viewer. This might have been a good idea 2 years ago, but these days not only is ASV no longer supported by Adobe, but all but one browser supports enough SVG these days to be useful.

This isn’t Opera or SVG’s fault. I guess it’s really just an algorithmic problem? The SVG output is similar in nature to the HTML output: contiguous text is mangled into subsequent spans/tspans with the same style applied. I’m really curious if anyone has a clue why this happens – is it that the conversion engines are trying to duplicate (down to the pixel) Adobe’s kerning from the PDF source and fails so it just defaults to fragments of text? Is it that the PDF is “optimized” in such a way that it’s not possible to determine what was a contiguous chunk of meaningful text? Looking at Texterity’s metadata.js it seems that at least they can determine a list of indexable terms from the PDF…

I don’t buy the idea that SVG is too verbose for something like this either. Zack Rusin’s git Cheat Sheet has fancy flow charts as well as hunks of text and was produced by Inkscape (not known for the conciseness of their SVG, shall we say?). That files weighs in at only 161kb and that’s not even compressed. And it looks great in every browser that supports SVG (ok, I saw one glitch in Firefox).

Costs

Adobe Acrobat Profressional Version 8 = $450 USD

matterCast’s SVG Imprint = $199.95 USD (requires .NET 1.1)

PDFTron’s PDF2SVG = $549 USD (without annual maintenance contract)

Texterity’s FreeSVG = Free service if you’re willing to submit your PDF to them

Texterity’s TextCafe = Must obtain a quote

Conclusion

Like I said at the top, I can appreciate the need for a document format that you know will render pixel-perfectly the way you want. I can also appreciate that some authors want to make it difficult/impossible for other people to modify their documents. My gripes about PDF these days are mostly about using Acrobat Reader, but I think my experience this evening did indicate to me how difficult it is to convert from optimized PDF to some other format… it was an education. I think it’s fair to say that conversion to PDF is more-or-less a one-way street. [Update: See François's comment below - he thinks it's the fault of the TeX->PDF conversion. Since I don't know enough about TeX and don't have the time to really dig into the source, I'll believe him.]

And yeah, I’m aware that my Google ads will probably be all for PDF converters. The universe is funny that way.

I ran the tests on various flavours of Firefox, Opera, Konqueror, Safari, Adobe SVG Viewer, Renesis, and Batik. Go check out how your favourite web browser or SVG plugin scored when I ran it through all 280 tests: Click Here.

This is one of those times when I almost hesitate to even publish this because people will officially know I wasted hours of my life browsing web pages to obtain these results. Then again, we all waste hours of our lives browsing web pages – the only difference is we don’t record our findings in a spreadsheet.

I hope some people will find this interesting. Some people might consider it a challenge. Other people may find it discouraging, disappointing, a waste of time, an over-simplification, or even offensive. Oh well, at least now I have my own scoring system for anybody who wants to put out a SVG plugin or support for SVG (Microsoft, care to give it a whirl?).