LinguaGrafica
Monday, September 29, 2003
 
CGM versus SVG for technical graphics
Source: www.cgmopen.org/technical/cgm-svg-20030508-2.htm Lofton Henderson & Dieter Weidenbrueck

Introduction
I came across the above article the other day and was interested as I don't hear about CGM (or WebCGM) very often. I was hoping for an unbiased comparison of the two formats. Actually, I'll confess my bias was that these must be complimentary technologies since WebCGM also comes from the W3C. I was looking to see how they fit together. To be fair, the authors are pretty honest about their own bias, "The authors confess a bias towards WebCGM as currently 'the right tool for the job.' But we have tried to be objective and measure the two formats against objective requirements and criteria.

I appreciated their candor and hoped they would live up to this promise. Unfortunately, I believe that they have fallen short of their goal — perhaps because of a lack of experience with SVG?

With the hope that was the only issue involved, I dedicate the following blog entry to the hope of creating a dialog and balance of information.

Details
In the Forward, the authors say, "Caveat. Some of the information in here, particularly regarding implementations and interoperability, is volatile and subject to rapid change. For example, in the few months between the previous draft of this paper and the present version, a second SVG plug-in implementation has joined the long-time single one, and a WebCGM interoperability and product directory has been initiated."

I assume the "one" viewer they mean is Adobe SVG Viewer and that they are alluding to Corel's SVG Viewer as the second. Although Adobe clearly leads in SVG user agent distribution, there have been several SVG viewers for sometime (8 desktop and 5 mobile implementations are currently listed on the W3C page. So it is a little misleading to make the choices seem so limited and support so thin.

Later, the article criticizes some SVG authoring tools by saying, "So far, there has been little focus on re-authoring and re-use of SVG files. SVG files are created, used, and deleted. In today's world an illustrator would almost always retain a copy of the illustration in a proprietary format for further editing. The authors are aware of the fact that some products perform a native editing in SVG, however, the bulk is converted from other formats with losses, because most high-level primitives like circles or similar get converted into Bezier paths. There are products on the market that seem to include a copy of the entire content in their proprietary format inside the SVG."

The authors are correct only in as much as SVG has been added to tools with huge installed customer bases, like Adobe Illustrator and Corel Draw. To date, these tools have sometimes failed to take into account native SVG concerns like making a circle a '<circle>' element rather than converting them to a '<path>'. However, AI 11 now includes SVG primitives. To be fair, Adobe only announced Illustrator 11 today. So first, better SVG tools are evolving all of the time. Secondly, and much more importantly, any such criticism is properly directed at the tools, not SVG. (Now if SVG didn't have a '<circle>' element that would be another story.)

But lets move to more substitutive issues. The article says, "In SVG, an object is clickable only if a link is attached to it. This is comparable to text on an HTML page that becomes clickable only if a link has been specified for it. Thus the entire concept of out-of-line links is not possible with SVG."

I'm not sure what the authors meant here. Every SVG element automatically has events associated with them: mouseover, onclick, etc. regardless of the presence of a link. Moreover, an HTML document can cause part of a graphic to change attributes (e.g. highlighting, appear/disappear, change color, size, etc.). No link needs to appear in the SVG for this to happen. (An XML.com article included a wonderful example of a CAD drawing using this technique.) Note, because SVG has CSS style sheets that can be modified via the DOM, there are virtually no limits on this. It seems to me that this is far more powerful than WebCGM can offer since there are no style sheets in WebCGM.

The article also says, "It would be impractical to write an explicit event handler and assign it to each object in a parts catalog, that would result in thousands of assignments. So perhaps it is possible to write one single event handler that uses the DOM to find an element under the mouse and then handles accordingly. All this is cumbersome and not very practical." A single event handler can create an action for an entire graphic without being "tightly coupled" to any given graphic. Therefore, Javascript is neither cumbersome nor impractical. After all, XML (and therefore SVG) offer the freedom that comes with the separation of content, presentation, and programming logic.

When discussing "Multilinks" the authors say,"SVG does not have multi-link functionality. It could perhaps be imitated somehow with a nesting of groups, but obvious SVG semantics for nested 'a' tags are very different than the required functionality -- the choice mechanism would be difficult or impossible to support in any simple manner.

It is true that so far SVG has only adopted XLink's notion of "simple links". I would agree with the authors that the working group should consider adopting more of XLink to make multiple targets easier for tool and content developers to use. But it is quite possible to use a scripting language to create multiple links on an object in the meantime.

The authors also complain there is no tooltip feature in SVG. In SVG 1.0 and 1.1 tooltips were only optional. Many developers have worked around this by some very simple script. SVG 1.2 has added tooltips officially.

The article continues by saying:

"It does not appear to the authors that it is easily possible to zoom in on a particular object in SVG unless a view element has been specified," and also complains that highlighting isn't possible via a link. While it true that SVG doesn't take care of this automatically unless you define a view, these features are generally handled easily via scripting as well. This allows content to be handled in a general way and the same diagram to be handled differently from one use case to the next. Separation of content, programming logic, and presentation are some of SVG's key value propositions.

The article also says that CGM offers links to all objects using the same non-unique name but SVG lacks this feature. On the SVG-Evangelist, Randy George noted that this could be accomplished in SVG using the '<g>' element. The authors also talk about linking to a specific picture in the file which Randy associates (and I agree) with a use element or using the DOM to set a link to a specific picture, or setting a view.

Talking about SVG file size, the article later says that:

"SVG supports embedding of raster images using the 'image' element (see [SVG Image Element]). However, whereas in WebCGM the raster content is stored completely inside the WebCGM file, SVG references external files in JPEG, PNG, or other raster formats. The inclusion of raster data within the SVG file is possible by encoding the pixels as base64 characters inside the xlink:href attribute. This is done by several applications on the market.

"This leads to significant differences between the formats when using raster portions as a part of the illustration. With SVG, either two files need to be handled, or the file size is significantly larger than the one of the WebCGM file."

Yet later, the authors say, "SVG (.svg) is clear text and can be as much as 8-10 times bigger. SVGZ (zipped SVG, .svgz) is about the same size as WebCGM."

The way this is written is very oddly and encourages misunderstanding. First, let's deal with SVG without rasters. SVG gives you the advantage of human readable text plus compression efficient enough to at least equal CGM. Seems like a win to me.

Now let's look at SVG which include rasters. SVG allows rasters to be linked or embedded. The authors claim that the file size is significantly larger than WebCGM but that makes no sense at all. There is virtually no difference in terms of total file size--regardless of whether you use compression on the SVG since the raster file is usually already compressed (or should be).

I think what happened is the authors used Adobe Illustrator 9 incorrectly and blame their mistake on SVG. They left in all kinds of Adobe specific information which helps you roundtrip SVG but isn't necessary or meant for a production environment. When you turn all of this off, the resulting SVG is less than 1k bigger than the original raster itself. I'm sure it wasn't their intention to create a bogus bogeyman here. The authors are probably just not familiar with Adobe Illustrator. I point it out not to embarrass anyone, but because it is dangerous to come to the conclusion that using raters with SVG is automatically less efficient than WebCGM.

By the way, there are workflows that benefit from external links to images rather then embedding them into the SVG. This allows servers to process images in all kinds of ways — e.g. dynamically convert, down-sample, crop, remove color, etc. to optimize for a specific device). It also allows for the separation of ownership of various assets as well as the presentation, logic, and content. For example, if I want to offer a service where I overlay street maps over a USGS satellite photo, I don't have to pre-fetch all of the possible satellite photos and store them on my server so that I can embed them inside my final product. I simply need to be able to link to them in their original source. To create an even better experience, one could use a low-resolution image for initial orientation and allow the user to link to a higher resolution image--perhaps for a subscription fee? This allows the developer to create a single flexible architecture that provides a better experience that can be monetized without any substantial change in code.

Also on the SVG-Evangelist, Randy George observed, that the authors have a significant issue with SVG's line style issues, line-widths, engineering line types, (particularly with regard to zooming) and offset controls for vertex inking. Currently, these are valid issues and can only be overcome in SVG by some complex scripting work arounds. Randy concluded, "However, these appear minor when compared to the benefits of SVG over CGM in the DOM/JavaScript/Internet Server triumvirate." I would agree, but I think that SVG should continue to dialog with CAD customers and tool developers regarding their needs. Just as it has clearly done with the GIS and design communities.

Conclusion
Overall the article seems to cast SVG as only for "creative graphics" and accents its high presentation qualities ala PostScript and PDF. While I wouldn't deny SVG's relationship with these de facto standards, I think SVG is far more than pretty pictures and precise presentation.

After all, as the blog says,
"SVG is the language for dynamic, interactive programming--
SVG: it is not just for graphics anymoreTM"

Thursday, September 04, 2003
 
The fall of writing...what makes communication technologies fail
source: The fall of writing, Washington Post (via the San Jose Mercury News)

The other morning I read the article above as I drank my morning coffee.

"In the first study of its kind, three experts in the study of written language have described the common characteristics that caused three famous scripts -- ancient Egyptian, Middle Eastern cuneiform and pre-Columbian Mayan -- to disappear.

"The study's basic conclusion: Writing systems die when those who use them -- priests or scribes or invaders, for instance -- restrict access to them."


This was an article that I might easily have skimmed or passed by all together. But something seemed strangely familiar about these issue to me.

``The sociological and cultural dimension is crucial,'' said Brigham Young University archaeologist Stephen Houston, the study's Maya specialist. ``Successful systems don't have these prohibitions. Once there's this perception that the writing is only for this function or that function, script death is almost a self-fulfilling prophecy.''


So what was so compelling? First, SVG is a language. As such, it is interesting to learn how linguists and sociologists think languages work, and what makes them succeed or fail. Second, there is something to be observed about how things are adopted in general from a sociological and cultural perspective. So here are some of the things that this article brought to mind for me.


  1. Restricting access to communication technologies diminishes the value of those technologies and results in their ultimate demise. This is really no different than Metcalfe's law, which says that the value of a communications system grows as the square of the number of users of the system and Reed's law, which says that the utility of large networks, particularly social networks, can scale exponentially with the size of the network. Another related argument is Andrew Odlyzko's thesis, Content is Not King that connectivity is more important than content. For me this last article speaks to SVG's inherent ability to bridge diverse data sources such as you commonly find in the GIS world. One way to look at organizations like Open GIS is that they realize that the connectivity of GIS databases often provides more value than any of the separate databases separately. I would include the lack of extensibility as one form of access restriction.


  2. Conversely, technologies that permit broad adoption thrive. In the 80's the desktop publishing revolution made technology affordable. This provided a means for inexpensive mass communication previously impossible. In the 90's a different kind of freedom was launched by web technologies including HTML, JavaScript, and CSS. This grass-roots technology spread because not only were many of the tools inexpensive or free, but they came from a multitude of vendors. When a new, better tool was released, you could move your content into it easily and inexpensively. Needless to say, that also ensured a different kind of freedom, that is, authors could never be held hostage to one vendor. Vendor's now have to compete on the ease of use of their product, quality of their implementation, price, and integration with other solutions, such as photo-imaging, video editing, and so on. I would add that around the time HTML took off, people began to value extensibility as well. The notion that no language could do everything for everyone was gaining acceptance...metadata, namespaces, and the separation of content and presentation began to become important as people shared the frustration of mixing them in early implementations of HTML.


  3. The best communication technology by any objective measure, doesn't necessarily win. Rather the ones that provide the widest access do. The article talks about Mayan and Egyptian languages, but we could also look at the infamous beta vs. VHS in our own times. It is widely understood that the betaMax format was objectively better, but because it didn't achieve wide acceptance fast enough, it was overtaken by the VHS format (which is now being overtaken by DVDs and DVRs, but that's another story.)


Another factor to the success of any language is how it is used and by whom. If a language is constrained to a select group, that group has greater, if not total control over the evolution of the language. But here's where there are differences between SVG as a language and SVG as a technology. In language, one industry's jargon or vernacular is gibberish to the rest of the world. There is often more value to that industry in keeping the language as a jargon. It provides efficient communication through precision and keeps out those who aren't part of the "in-crowd". In contrast, a language that is primarily processed through technology, such as SVG which is most often not read by humans, but rendered by a user agent such as Adobe's ASV, Corel's SVG Viewer, or Batik. Here, the language specification is also precise and hopefully efficient. However, without significant distribution of compliant viewers, SVG content has little value to Internet users or content developers. Also, SVG viewers are non-trivial to build properly and any differences between viewers or between versions of viewers hurts SVG adoption. So SVG only has value if everyone has access to the specification and the specification is embraced widely and consistently. This is not unique to SVG of course, HTML still suffers from differences in HTML browser behavior. The only differences are that HTML has been around longer and so developers have learned workarounds for coding in the browsers they care about as defined by market share. Also, that has gotten easier, as only Internet Explorer 5.x+ for Windows has any significant market share so that's the de facto standard.

But a de facto standard run by a single company is little different than the priests who "protected" the languages described in the article.

"``There's discrimination against everyday use, so that while religion may help a script survive, it does not extend its reach,'' said University of Cambridge Egyptologist John Baines, who collaborated with Houston and Assyriologist Jerrold Cooper of Johns Hopkins University. ``And when the people'' -- or conquerors -- ``begin to identify the religion and its script as something heretical or dangerous, there's nobody left to protect it.''


When languages are associated with a religion or regime that is no longer in vogue, they die a painful death. Try opening a WordStar file recently? How about Word 1.0? Do they look like they did when you had your CPM machine?

When a single company dominates a market and has no need to extend a language beyond it's own immediate needs, languages cease to innovate and therefore don't serve us well either. Moreover, no company can be the best provider in every category of tools, for every field of endevor, forever. Therefore specialized areas like chemestry, manufacturing, engineering, etc. may be held back when their needs are not addressed, or they are addressed by niche technologies which make it difficult, expensive, or even impossible to share their information with people outside their professional cliques such as government regulatory agencies, the general public, and other "downstream" uses of the information they develop.

However, when people from all walks of life experience contribute to a language, it becomes a rich, vibrant, enabler for broad communication between individuals, industries, and governments that is unhindered by language, technology, or location.

I bet the authors of this liguistic study had no idea they knew so much about SVG.


Powered by Blogger