Three and a half ways to use SVG in a blogger post
There are three ways to include SVG in your blog.
1. You can link to an SVG object by using the Blogger HTML editor to point to SVG hosted somewhere else. For example:


You end up with:

Note, that blogger doesn't like the embed tag which is what Adobe generally recommends using. With the embed tag, blogger complains that there is an open tag. This is because blogger uses XHTML 1.0 Transitional by default and the embed tag is not kosher because it doesn't close properly. It may be possible to change the Blogger template to something that tolerates the embed tag like HTML 4, but I don't know if blogger permits anything except XHTML 1.0 transitional so you'll probably have to use the object tag. Keep in mind that the image will display in the Adobe SVG Viewer, but not in Opera because it is not an SVG Tiny document. If you are an Opera user, hang in there, I'll get to you in a momment.

There's a good tutorial about how to embed QuickTime movies which may be helpful since they also use object tags.
Now above you should have seen this svg like you do on this page. If you didn't, try downloading the Adobe SVG Viewer.

Keep in mind that you can host your blog on your own server. See How do I setup an FTP (or sFTP) connection to my external web host? for details about how to do this. Why? In some cases, the Adobe Viewer is purposefully limited in what it can do in the sense that data can't be exchanged between servers from different domains. I don't believe some of the other SVG viewers and SVG enabled browsers have the same problem that Adobe does with cross domain linking, but I have not tried them.

2. Using the HTML editor, include JavaScript that will emit the SVG. [I'll add an example of this when I get a chance.] The main thing this provides is the ability to keep the SVG on the blogger server, rather than linking somewhere else. This probably also gets you around the security problems mentioned above.

3. Using the HTML editor, include the SVG inline with the HTML. This won't work with the Adobe SVG Viewer either, but it will work with some others like Firefox' Deerpark.

The Adobe Viewer is no longer the only alternative out there. You can view SVG that is SVG Tiny 1.1 compliant using Opera 8. No plug-ins required.


For some reason, the Adobe SVG Viewer does not like it when you include the type="image/svg+xml" attribute to the object tag. I believe this is a failure to follow the relevant specifications. In any case, for now just set make sure to set mime type on the server where the SVG will reside and I think everything will work just fine.

4. In theory, you can also use SVG content embedded inline as a fragment within a parent XML document. In this case, your blogger entry, which is an XHTML document. For example:



The only problem with this is that I'm not sure if anything but the Adobe Viewer can render this type of embeded namespace. For more information about including namespaces, check out this paper. Note, also will require modification to the blogger template, and I'm not sure if it will break anything on the blogger end.

While I haven't gotten inline name spaces working yet, here's another way to include svg. The following iframe links to an HTML document which has an SVG inlined namespace.

While the SVG displays, the downside with this approach is the SVG isn't fully interactive&emdash;you can't search text, zoom in, etc.
- posted by Michael @ Sunday, August 14, 2005

 
Article: When Do Web Services Make Sense?
Source: http://www.ftponline.com/wss/2003_06/magazine/columns/trends/default_pf.aspx

Douglas Kerwin provides an excellent article about when using web services is appropriate. Usually I try to keep this blog focused on SVG, but I think web services are such a strong application for SVG that this is worth mentioning. The article is short, so I won't summarize.
- posted by Michael @ Tuesday, November 25, 2003

 
Article: A tale of two Cairos
In a A tale of two Cairos, Jon Udell talks about standards (or the lack thereof) in Microsoft's Longorn release. "And as the 2003 PDC made clear by conspicuous omission, CSS -- along with some other Web standards including XHTML and SVG (Scalable Vector Graphics) -- won't be embraced or extended in Longhorn's presentation system, Avalon. To call attention to this fact is to risk being branded a Luddite, but two words suffice to explain how and why Web standards still matter: network effects." Jon goes on to remind us of Cairo--an earlier Microsoft failure.

"The browser, to be sure, is not a sacred relic to be preserved at all costs. But the Web is much more than the browser. It's an ecosystem whose social and information structures co-evolve. Innovation bubbles up from the grassroots; integration can happen spontaneously; relationships cross borders. Cairo Version 1 wasn't designed to nourish that ecosystem or to flourish in it. Let's hope Microsoft remembers the past and avoids being condemned to repeat it with Cairo Version 2.

I think Jon couldn't be more right. As cost cutting blitzkriegs continue at an ever increasing pace, and as content flows from one discipline to another and one context to another, standards are the only way to share content, development cost, and promote content reuse. Not just from context to context, but device to device, not to mention the value of easier hardware and software upgrades.
- posted by Michael @ Monday, November 24, 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:


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,

- posted by Michael @ Monday, September 29, 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.



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.



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.



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.
- posted by Michael @ Thursday, September 04, 2003

 
Speaking of SVG--literally
source: SD Times

"SALT Forum consortium has enabled speech navigation of Scalable Vector Graphics by extending the W3C standard with a new tagging specification..."

SVG is well appointed for applications like GIS, Location Based Services (LBS). SVG was also designed for Accessibility. At first glance this two observations may not seem terribly related. Of course any LBS benefits greatly from following Accessibility guidelines partly because Accessibility guidelines try to ensure there is no dependency on input devices like mice.

See also svgopen.org/2003/paperAbstracts/making_accessible_svg.html

As Dean says, In an age of the Semantic Web , images can have much more value when they have relationships to the components that make the image and to other images--as well as another kind of content (text, video, etc.)

What is even more interesting perhaps, is that someone from Microsoft is mentioning SVG in an important and appropriate way. Does this demonstrate that Microsoft is finally making a public commitment to SVG (beyond the welcome step of Visio 2003 which has been announced for a while now.) It is probably too early to say that with any certainty, but it is certainly a positive sign.
- posted by Michael @ Thursday, August 21, 2003

 
SVG and real world GIS
source: Interactive SVG mapping with MapInfo location-based intelligence

Believe it or not, I'm still catching up on some of the SVG Open talks that I didn't have a chance to attend. My latest "discovery" is the talk given by Dany Bouchard of DBx Geomatics. Dany gives great real world examples of SVG in the GIS world that should make even perenial skeptics (I won't name names) stop and think.

• Geographic analysis reports


• sharing wireless network planning data


• Emergency planning


• Transportation planning

In the words of a product manager at a major company I talked to recently, "SVG is inevitable". Inevitable indeed!

Another great SVG presentation. Thanks Dany!

For more information and more demos of what's possible with GIS, see www.dbxgeomatics.com/

By the way, I couldn't help but notice the new features in their new 2.0 product. (Forgive my choice to link to the English page. French is also available.)
- posted by Michael @ Thursday, August 21, 2003

 
News: Microsoft looses law suit
sources:

• http://archive.infoworld.com/


• Washington Post


• news.com.com
  

Not specifically related to SVG, but this could have an impact on the delivery of web content, and future browsers or thin-client platforms.

"Eolas Technologies, which develops Internet technologies that it licenses to third parties, is alleging that Redmond, Wash.-based Microsoft's Windows 98, Windows 95, and Internet Explorer products infringe on its patented technology. Eolas says it holds a patent on technology that allows a Web browser to access interactive programs embedded in a Web page, such as plug-ins, applets, scriplets, or ActiveX controls."

"[Eolas] developed the technology that allows a Web browser, such as Microsoft's Internet Explorer, to access interactive features of a Web page.

"Those features, such as altering data or viewing objects from different angles, are central to the way Web browsers now operate, particularly enabling online commerce."

"A federal court jury yesterday decided that Microsoft Corp. must pay $520.6 million to a Chicago technology entrepreneur and the University of California after deciding that the company's popular Internet-browsing software infringes an existing patent."

This is interesting in light of Microsoft's announcement that they would not be developing Internet Explorer for the Mac and that IE will no longer be available standalone.

"As part of the OS (operating system), IE will continue to evolve, but there will be no future standalone installations. IE6 SP1 is the final standalone installation," said Brian Countryman IE Program Manager.

As an aside, Microsoft has also said that it will discontinue Outlook Express in favor of MSN and Hotmail. Kind of interesting since OE is currently the default news reader. (Outlook doesn't read News.)

These moves show a great deal of confidence or arrogance on Microsoft's part that they can own the everything from clients to servers and everything in between. From a marketing perspective, it will be difficult for anyone to launch a successful browser to compete with Microsoft's monolithic fat client approach given their 90% or so of the market but nearly everyone in the tech industry has a vested interest in something being done.
- posted by Michael @ Thursday, August 14, 2003