This is a test of the emerging language translation service. This is only a test. If the Semantic Web were real, we wouldn't be in this mess.
SVG (Scalable Vector Graphics) is an XML dialect that describes vector images, sort of like Macromedia Flash. What sets it apart from that format, though, is that it is a text-based (i.e. human readable), data-driven open standard. Just like with Flash, however, you currently need to have a viewer plug-in for your browser to render it properly; I'm afraid that if you want to make any sense of this page, you'll have to bite the bullet and install Adobe's SVG plug-in:
Don't worry -- it won't hurt a bit.
As I mentioned, SVG is text-based, consisting of tags similar to HTML: a <circle> tag makes a circle appear on the screen. Since it's just text, I thought there might be a chance that an automatic translation service, like AltaVista's BabelFish or Google's page translator might be able to translate the images as well. Why do I care? Many sites use images of text in raster formats (bitmaps, JPEGs, and all that) --instead of plain text-- to decorate their pages and indicate links; this is all very stylish, but it isn't machine-readable... which means that search engines won't index it, translation services can't translate it, and text-reading software for the visually impaired is at loose ends. The same is true of Macromedia Flash. SVG has the ability to make beautiful text and graphic images that are both machine- and human-readable. An example is the banner adorning the top of this page, which --if you can see it-- is made with 'inline' SVG (actually, a bit of a kluge... see the disclaimer below). Currently, however, this possibility is unrealized, due to SVG's newcomer status.
Below are a few examples of embedded and 'inline' SVG images. An embedded image is a separate file that is stuck into a page, just like a bitmap or JPEG, and so is not actually part of the document; an 'inline' image is one that is written directly into the HTML of the page (using XML namespaces), and is therefore part of the main document itself. In these cases, the SVG markup is exactly the same, though some small visual artifacts occur because of my use of CSS. Each of these SVG images has text elements as well as shape elements; ideally, the text would be translated, but the markup elements (in the tags) would be left alone lest the code become garbled. For searching, perhaps both would be indexed; for programs that read Web-pages for the visually impaired, the text might be spoken, and the shapes described, either as simple shapes, or using the description provided by the images author in the SVG file.
For the purpose of illustration, I'll conduct a little experiment using Web translating services: it's immediate, and easily demonstrated. One can extrapolate the results to searching and text-to-speech agents.
You can test the translation of this page (and the SVGs on it) into Spanish by Google and BabelFish. Also, you can test stand-alone SVGs with Google and BabelFish (use the URL “http://schepers.cc/images/labeled_rectangle.svg”).
Using Adobe's SVG Viewer 3.0 in Internet Explorer 6.0 on a Windows2000 machine, I tried several Web-translation tools (Google and AltaVista's BabelFish among them, of course) to translate this page (and the SVGs in and on it) from English into Spanish. Here are my initial results (as of February 2002):
This latter point was the most intriguing, for two reasons:
Of course, “Esto es un rectángulo” is a longer string than “This is a rectangle,” and so it ran off the bounds of the SVG, but maybe future enhancements to SVG's treatment of text will take care of that.
I'm curious as to how this test performs for people with other operating systems and/or other browsers or SVG viewers (such as Batik); if you get any interesting results, drop me a line.
When I tried to translate a standalone SVG (one not in an HTML page), I got text translations only; BabelFish just gave me the translation of the text element, whereas Google gave me the whole SVG file as text, with the contents of the text element only translated (the results render fine, once saved and opened in IE); this may depend on the MIME type of the server, however, since on a different server, nothing at all was translated.
Obviously, at least Google is capable of correctly treating SVGs (which is not to comment on the quality of the translations themselves ;-), as long as it knows that it is supposed to. I sent them an email to bring the issue to their attention, so they can translate embedded SVGs as well... it can't be that hard to scan for a MIME type or file extension, and treat it accordingly. If anyone else is interested in seeing the Web become that much more accessible, give them a holler.
Similarly, if you do a search for “circle” in this page (using the browser's “Find” feature), you will find all the instances written in HTML, but none of those in SVG (even the 'inline' SVGs); by right-clicking on the SVG images, you can perform this text search very easily, and you can also select, copy, and paste text from an embedded SVG. There is no reason the browser should not have the same capability, but most browsers have not addressed this powerful W3C Recommended standard technology (some experiments in Mozilla and certain Linux browsers notwithstanding).
All in all, I think that this experiment shows real promise, and indicates the power of data-driven graphics in an open format. If you agree, and would like to see SVG more supported, contact your favorite search engine (mine is Google) or Web browser manufacturer (such as Netscape, Opera, or Microsoft).
NOTE: The purpose of this page is not to demonstrate inline SVG, but the manner in which a translating or searching agent might treat SVG. For more on Inline SVGs, see my little exposition.
ⓢ