Diaries

As a website architect in Asp .Net technology, I just ran into one of my colleague who told me about SVG. Ever since, I have been reading some online materials and learned about this site too, which is filled with lots of information about it. So I thought to write up my first story in the diary. As a teaser, I am going to implement something really cool with SVG on my online dating website pretty soon. I am hoping to wrap it up in few days and probably post up a link of my work to get some thoughts from you experts. I believe in learning everything I can, as everything learned helps in the future.

My previous entry had too much code so I've created a shorter version. Read my other entry, this code has the same issue. Why?

In an attempt to get smooth transitions within an SVG bar graph that can display data equally distributed or chronologically on the x axis I have run into some confounding complications.
While all the bar elements incrementally change their x coordinates after each iteration, none of these increments are visible. The SVG bar graph jumps from one state to another once the transition has completed.
While this would be easy to do using animations, Firefox requires a JavaScript workaround.

A recent discussion (in German) about the proper way to kick start a new website from the "under construction" into the "live" state fired some of my synapses.

I'm about to totally redesign my coupons website and I'll use SVG to do it. I'll keep you posted so you can review it.

Oh, what a wonderful day. Today is the first day with much sun and i used this great time for chilling on my balcony ;-) I only want to blog about this nice day, because i have high spirits ;-) I also have created a new weblog where i will post my funny life. :) Yes, whatever.. i wish you a cool time and much fun... Bye, Foxi

Still waiting for SVG to work on IE without a plugin.

This is my first post. I looking here for SVG experts for my site Vorsorge Versichern but first I wanted to say Hi.

At least if you look at the running 2008 total of visitor statistics for the SVG link resource. Both IE and Mozilla are now at 44%, where IE is shrinking and Mozilla is growing.

Isn't SVG much more powerful than WebCGM?
Of course it is. But that completely misses the context of our overall conclusion (that WebCGM is better suited for technical graphics). The context is a specific set of requirements for technical graphics. Most of the vastly greater power of SVG is irrelevant to these specific (and modest) requirements, and in fact SVG functionality has some gaps that miss some of the requirements. WebCGM was specifically profiled to those requirements.
There are a lot more than two SVG viewer implementations
Correct. And there are a lot more than five CGM viewers also. But we are specifically concerned with plugin-type viewers, which are the component that is most necessary and interesting in real-world technical graphics scenarios. A year ago, May 2003, there were only two SVG plugins (now we identify four).
But can't you do <that> with scripting?
Here, "<that>" represents a number of difference areas in the detailed technical comparisons where SVG advocates pointed out that scripting could solve the problem: multi-links, out-of-line-links, etc. General response: The authors agree that there is almost no limitation to what you can do with scripting. However, scripting is anathema in many real world technical scenarios where graphics must remain stable, viewable, editable, and maintainable for long periods (e.g., 10, 20, 30 years). A declarative syntax solution as part of the graphic is preferable and often essential. Full SVG becomes more an operating environment and rendering toolkit than a graphical file format.
To be clear about this issue: large scale users in the area of technical graphics are adamant about not using scripts inside a graphics file. There are several reasons for this, one is that e.g. JavaScript can not be used in hazardous environments requiring fail-safe performance, e.g. in aerospace or defense. Another important experience is that graphical content per se is not easily transferred into another format without losses; presense of scripting makes it much harder yet.
The raster comparison distorts the capabilities of SVG
The updated version of the base paper attempts to clarify this critical topic. The authors admit that the 2003 paper unnecessarily confused the raster topic by not separating the arguments about the format from those about the implementations (both of which have bearing).
    * Theoretical. WebCGM integrates one or more raster images compressed with a technique from a standard list of techniques (Group 4, as well as JPEG, PNG, and a couple others) into the binary body of the picture. SVG has two options:
         1. external reference to compressed raster images from within the SVG file (PNG and JPEG are the standardize, required formats);
         2. or, embedding the compressed raster into the xlink:href attribute of the 'image' element, using the "data:" URI scheme with base64 encoding.
      #1 is unacceptable in high-volume real-world technical graphics scenarios that might involve tens of thousands of technical illustrations, each of which might have multiple raster sub-images. For #2, base64 encoding introduces a 4/3 expansion of the binary data (which might be negated if the SVG file is then svgz compressed). In limited experiments with rasterizing a typical b/w line drawing (technical illustration), we have not yet been able to get the PNG compression to be any better than about twice the size of the Group 4 compression. Further experiments are warranted here.
    * Implementations. In the 2003 paper, we mingled some data that derived from attempts to measure SVG-WebCGM comparative raster handling, from experiments with an SVG-capable illustration tool. We got vastly different results than what theory would suggest. After distinguishing the theoretical from the practical ... should this problematic implementation behavior matter? Yes. An experienced graphical-tool implementor and technical illustration practitioner were unable to get reasonable results with an industry dominant commercial OTS illustration tool. However, the implication is not on the raster capabilities of the formats, but on the maturity, completeness, and correctness of implementations (an interoperability topic, not a static-graphics functionality topic).
      In particular, the handling of black and white raster images is critical in TG, because most of the legacy data that has been scanned is pure b&w data. The deliberate conversion of such data to RGBA is not tolerable with regard to file sizes and memory requirements. A typical size could be 4800 x 3200 pixels (roughly A2 format). As a b&w it requires about 1,875 KB of memory, as an RGBA image it would be almost 60 MB.
Isn't it an advantage that SVG is clear-text XML?
Clear text is no advantage at all in real-world technical graphics scenarios. Because of the number, size and complexity of the graphics, hand-editing and even human interpretation of the graphics code (e.g., debugging) are out of the question. In fact, there are strong arguments that clear text may be a detriment -- file size, data security, etc. The fact that SVG is XML might confer an advantage for integration with other contents types, but this can also be achieved in other good ways (e.g., XML companion files). In fact, here too there are stong arguments against intermingling non-graphical contents and metadata within the body of long-lived technical graphics. (By the way, CGM also has a human-editable clear text encoding, equivalent to its binary encoding -- it is prohibited as the delivery format in all technical profiles of CGM -- WebCGM, ATA, etc.)
Doesn't (CSS) styling give SVG an advantage?
There is a strong view in the technical graphics (TG) industry that support for user-defined styling, changeable default style sheets, etc, is actually something that you do not want supported in a TG format. Among other things, it presents data integrity and security issues. On the other hand, there is some need for controlled change of appearance, e.g., for binding transient changes during interactive viewing of things like link-target highlighting. The control should not be in the hands of the user, but rather controlled by the application program (browser).
There are some rare use cases for styling though if a contractor has to deliver the same illustration in different styles to two different customers. However, this would only be acceptable if the user couldn't change it.
Aren't you confusing SVG format issues and implementations problems?
We agree that we should clearly separate the format versus implementation considerations within each topic. That said, both the format comparison and implementation considerations matter. We are looking at the question, "how do the formats measure up for application to real-world technical graphics problems today?" From the perspective of a mission-critical application, there is little difference between the format missing needed features, on the one hand, and the implementations being incomplete or broken, on the other.
Can't you use SVG <g> to achieve the effect of 'name'?
A couple of commentors have mentioned this. The answer is, "in general, no". WebCGM can tag each item in a collection of objects that aren't consecutive in the file with a common name, and navigate (link) to that collection. A SVG group requires that the objects all be consecutive in the file, which might be impossible to arrange because of the constraints of display order. Example: 5 bolts and their associated 5 nuts. If the illustration package draws then in the order bolt/nut/bolt/nut..., there is no way to group the bolt collection with a <g> and the nut collection with a <g>. Another example is where several bolts using the same name belong to different groups (<g> tags).
Isn't SVG 1.2 going to fix <that>?
Yes, a handful of technical additions to the static and dynamic functionalities will remove some (but not all) of the differences. See the tables and text in the next section. But SVG 1.2 is not finished, and won't be reach a technically stable/frozen state until later this year (2004). The new features are not uniformly implemented yet, although some prototype implementations are tracking the SVG 1.2 changes. It then becomes an issue of when the new features will penetrate and become available to technical graphics users in multiple, stable, production versions of SVG implementations.
You make it look like WebCGM was perfect, and SVG not
WebCGM is not perfect at all. There are quite a few things that need to be improved, some of them are discussed further down in this paper. Very often, the authors feel that the development on the CGM side should progress more quickly.

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 Xmovies 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.

Hi 2 all!
This is my first entry.
I'm glad to join this community :)

i´m Olli from Germany and i´m happy to be a part of this community.

Just posted is a nightly build of the Flex 3 SDK that will let you actually program with some of the new features in Flash Player 10. The SDK includes a new playerglobal.swc and compiler so that you can start creating Flex applications that use Flash Player 10. I haven't seen any docs yet on the new APIs but I'll try and figure out if they're coming or how you can find them. They may be out there, so if you see them, let me know. http://opensource.adobe.com

I am interested in learning xml. I think this is the hottest in making websites. I own a text-based site, アーティクル but better graphics with SVG can be still useful. I hope I can get good information here to learn more about SVG stuff!