Newsweek has a fascinating article about an archaeological site at Göbekli Tepe in Turkey that is well worth a look.

The site is the oldest religious temple ever discovered.  Preliminary carbon dating has determined that some of the artifacts date from 9,400 BC, which makes the place about 11,500 years old. (Which, just to be clear, is 7000 years before the Great Pyramid and 6500 years before Stonehenge.)  The article further explains:

The ruins are so early that they predate villages, pottery, domesticated animals and even agriculture – the first embers of civilization.  … [It] may be the very first thing that human beings ever built.

And yet, the site is amazing.  The pillars show beautiful stone carvings and there are examples of sophisticated engineering techniques.  The stone circles are nearly 30 yards across with pillars that stand more than 17 feet tall.  Many of the stones (some weighing up to 50 tons) were first quarried and then transported half a kilometer to the site, where they were erected.  What staggers me, though, is that the stone circles were roofed.

This quote from Ian Hodder, head of archaeology at Stanford University, summarizes my response pretty well:

[Göbekli Tepe] is unbelievably big and amazing, at a ridiculously early date.  The huge stones and fantastic, highly refined art [changes everything].  It overturns the whole apple cart.  All our theories were wrong.

This doesn’t happen often.  Scientists don’t admit mistakes and call for established theories to be overturned.  But when faced with such a revolutionary piece of evidence, you have little choice.

Göbekli  is literally an outlier in every way.  It shows engineering, organization, and artistic sophistication that seems to materialize out of nowhere.  The only other comparable examples won’t appear for five thousand years.

To really put this in perspective, consider the timeline below.  Arrayed across the bottom axis are the reigns of several ancient civilizations: the Chinese, Romans, Egyptians and Mesopotamians.  In addition to this information, I’ve also placed the approximate dates of the the ice age, stone age and examples of religious and cultural monuments (the oldest of which dates to about 3500 BC).

When compared with Göbekli, the great civilizations and monuments of the ancient world seem to to huddle in an upstart mob at the right of the chart.  Even the very oldest of the examples, a Mesopotamian palace, is separated from Göbekli by the same span of time that divides the ancient age from the modern day.

Such an amazing and sophisticated example at such an early date, literally, boggles my mind.  It's absolutely amazing.  And, paradoxically, the amazement and wonder helps to explain why Göbekli has remained essentially unknown.  A discovery of this magnitude demands enormous attention and dedication.  It takes almost as much as it gives, particularly from those that discovered it; and not every scientist is willing to give that kind of commitment.  Thus, I completely understand the response of the man who discovered the site.

[Unable to interpret what he saw], the [American] archeologist who stumbled on [on the site] in the 1960s simply walked away.

But, even so, the evidence at Göbekli has the potential to completely transform the history of civilization.  And I, for one, look forward to seeing what emerges.

Note: You can view a high resolution PDF of the timeline by clicking on the image, or here.

Similar Posts:

• Moving to blog.oak-tree.us
• Typeset Your Curriculum Vitae – Part 1: The xetexCV Document Class
• Big Things, Little Things and Unassociated Thoughts
• Image Gallery: The Notebooks of Leonardo Da Vinci
• Photos of Horses

Copywrite 2009: Rob Oakes. Apolitically Incorrect

Temples and Timelines

No study of the history of scientific communication can be complete without mention of Joseph Charles Minard, a 19th Century French civil engineer and cartographer.

At the end of his life, Minard created two very famous examples of statistical charts, called flow maps, that every scientist, engineer and student should be familair with.  The first showed Hannibal’s crossing of the Alps (218 BC, Second Punic War), and the second describes Napoleon’s disastrous invasion of Russia (1812-1813).

Both examples are beautiful works of art and masterful examples of evidence.  But they are also more than that, they tell cohesive and interesting stories.  In this post, I thought it might be interesting to take a closer look at the history of Hannibal and Napoleon, and highlight the ways which Minard’s charts help us to explain their eventual outcome.

(Note: High resolution, PDF versions of the two maps are available for download.  These versions have been translated from the original French.  To download, either click on the images, or here for the Hannibal invasion of Northern Italy, and here for the French Invasion of Russia.)

Hannibal Invasion of Italy (218 BC, Second Punic War)

Hannibal was perhaps the single greatest threat to Roman power to ever live.  At the same time that Roman legions marched unopposed through most of the Mediterranean world, Hannibal lead a force of twenty-five thousand soldiers into the heart of Roman territory. He then spent the next fifteen years occupying portions of the Italian peninsula and generally wreaking havoc.  But even though he ravaged the Roman countryside, Hannibal was never successful in subduing Rome.  Ironically, this might be due to one of his greatest exploits: the overland crossing of the Alps.

Hannibal departed his home base in Spain with nearly 90,000 troops (one of the largest armies that had ever been fielded at that point in history) and had a number of early successes.  He marched north over the Pyrenee mountains and into Gaul (modern day France).  He subdued the Celtic tribes and crossed the Rhone River before the Romans could take measures to stop his advanced.  He forged important alliances and found unexpected friends in his fight against the Romans.

After crossing the Rhone, however, Hannibal’s luck began to change.  He received word that a large Roman force was marching from the Mediterranean coast to intercept and destroy him.  As the force outnumbered him by a significant margin, Hannibal was faced with a difficult choice.  Should he stay at his current location and engage the Roman army or retreat and prepare a defense?

Not content with either choice, Hannibal ultimately chose a third option; which, ironically, would have enormous consequences for his overall campaign.  To evade the Romans, Hannibal took the unprecedented action of turning inland and marching over the Alps.  (It is thought that he probably crossed over the valley of the Drome and south of the Col de Montgenevre or near the Col de Mont Cenis.)  This had never been done before – indeed many thought it impossible – and has long been praised as a brilliant tactical decision.

Minard’s reconstruction of Hannibal’s journey shows the journey from Spain, through Transalpine Gaul and eventual arrival in Italy, allows it to be seen a slightly different light, however.  Through use of a flow line, Minard shows how the strength of Hannibal’s army waned through the march, with a disastrous loss of twenty thousand men while passing over the Alps.  This steady loss of strength, subtly reinforced by Minard’s map, helps to explain why Hannibal failed to subdue Rome.

Hannibal’s brilliant tactical decision was also a strategical disaster.  It came at a dramatic loss of men, war elephants, and material with the most disastrous loss being the destruction of his siege engines.  Without the siege engines, Hannibal was never able to successfully attack Rome.  And eventually the Romans realized this and changed their tactics.  Instead of engaging Hannibal directly, they instead fought a long-pitched war of attrition and eventually destroyed the one resource he couldn’t replace: his men.  Thus, even though crossing the Alps helped Hannibal to win a few stunning victories, the decision eventually caused him to lose the war.

Napoleon’s Invasion of Russia (1812-1813)

Like in the case of the Hannibal, Minard’s depiction of the 1812-1813 invasion of Russia also tells an extraordinary story.  It combines information about the size of the army, geography, sub-campaigns and temperature into a single narrative.  This time, though, it is anything but subtle.

Note: Because of  the elegant management of all this information – at any time showing the army’s direction, size, and loss relative to the start – some statisticians and data visualization experts (such as Edward Tufte, Etieene Jules Marey and Howard Wainer) have declared Minard’s depiction of Napoleon’s Invasion of Russia to be the greatest numerical graphic ever created.

From the very beginning, the army met with tremendous hardship.  The cold temperatures and lack of available resources took an enormous toll.  Napoleon had planned on scavenging for supplies to support his massive army, but the Russians had destroyed all of their crops and burned their villages so that Napoleon wouldn’t be able to make use of them.  As a result, the army was heavily reliant on slow supply trains from Europe that were unable to keep pace with its quick advance.  Hundreds of thousands died from starvation and exposure, greatly outnumbering those lost in combat.

Minard’s map shows this trend of devastating loss.  Napoleon’s Grand Army starts out as a wide, brown line to the left of the map.  As the army progresses across Russia, the number of men decreases dramatically.   A few ribbons of men are dispatched to other targets, but by far the majority succumb to the elements.

Eventually, a substantially reduced force (100,000 men, about 20% of those who began the campaign) arrived in Moscow.  What they found did little to improve their circumstances.  The city had been abandoned and burned to the ground.  No food was available.  The only available option was to return to France.

Demoralized and broken, the Grand Army began a slow retreat to the west.  Their progress is shown in the black.  As they crossed the vast Russian wilderness, the temperature turned bitter cold (shown in the bottom third of the map).  When the army arrived at the Niemen river, there were a scant 10,000 troops.  More than 400,000 had died.

Such a devastating loss of life crippled Napoleon’s young empire and left him open to invasion by his enemies.  He was defeated later in 1813 and exiled to the island of Elba.

Conclusion

Minard’s graphics are successful because they demonstrate powerful trends and place evidence within its proper context.  In the case of Hannibal, it shows how he began in a position of strength and then undermined himself through a brilliant tactical innovation.  In the case of Napoleon, it shows how distance and temperature ravaged an army and destroyed an emperor.

The clear evidence and thoughtful presentation define the story, they show where things are headed and help to foreshadow the inevitable conclusion.  For this reason, they are powerful examples of clear communication.

____________________________________________________

Unrelated Thoughts: Re-Visioning Minard with Open Source Tools

Since first seeing these charts as part of an undergraduate statistics course, I’ve been obsessed with them.  I even have a poster sized copy of the Russian invasion (available from Graphics Press) hanging in my office.  Given this obsession, it should come as no surprise that I’ve wanted to include the maps in my book.

There is, however, just one problem; there is not anything new to say about them.  Edward Tufte has held up Minard as a “Da Vinci of Data” for the better part of thirty years.  Nearly every one of his books includes a copy of the maps (in the case of Beautiful Evidence, his most recent work, there is an entire chapter devoted to the graphics; including eight different reproductions).  Other than, “They’re beautiful, study them carefully, read Tufte’s analysis,” there just isn’t that much to say.

That is, until I started looking for examples of scientific illustration that could be reproduced using the vector illustration program, Inkscape. Any such example should have simple lines and clean integration of text and images.  I'm not sure that a better description of Minard's work exists.

The two images above (and attendant PDFs) were my first pass at re-drawing the maps.  And I have to say, I’m rather happy with the result.  For the most part, I was able to get a very faithful reproduction (with the exception of the type face, which I deliberately changed because I hate script fonts), and only required a couple of hours worth of work.

I think that I may have found my book examples.  It allows me to include one of the best statistical charts of all time, talk about flow maps, and even include some interesting how-tos which show how the graphics can be built in an automated fashion.  Which, come to think of it, might just count as a new contribution after all.

Acknowledgements and Further Reading

More information on the book can be found at the publisher’s website.

The source images for the two maps included “Re-Visions of Minard” by Michael Friendly (1999) and the reproductions in “Beautiful Evidence” by Edward Tufte.  Translation for the Hannibal map was adapted from those available on Edward Tufte’s website (Dawn Finley) and sources available at Re-Visions of Minard.  Translation for the Russian campaign map were taken from the reproduction in Edward Tufte’s “Beautiful Evidence”, Wikimedia Commons and sources available from Re-Visions of Minard.

Additionally, the Re-Visions of Minard Website include a number of interesting adaptations of the Napoleon graphic that might be of interest, including both Matlab and GGPlot2 reconstructions.

Similar Posts:

• Anathem: Big Book, Big Ideas
• Customizing LyX: Character Styles and the LyX Local Layout
• Heart Arrhythmias and MRI
• WPF – SVG Graphics and XAML – Part 3
• Typeset Your Curriculum Vitae – Part 1: The xetexCV Document Class

Copywrite 2009: Rob Oakes. Apolitically Incorrect

Hannibal, Napoleon, and Joseph Charles Minard

There is a reason why the tuxedo hasn’t changed in more than a century.  Put simply, there is no need for it to.  Unlike other things, it doesn’t need to evolve or mold itself to the fashions of the current age.  It’s just fine the way it is.  It’s traditional.

And barn architecture should be traditional.  They are practical buildings, and as a result should be made of relatively impractical things.  That means natural materials.  Most of the structure should be made of wood (preferably oak) or stone with big timbered logs being an even better choice. Steel and concrete can be acceptable, but edge out on the tacky side.

Thus, there is only one word to describe the structure being proposed by MVRDV and Mole Architects near Suffolk in the United Kingdom: travesty.  (Though monstrosity comes remarkably close as well.)  First, they are proposing an “open” architecture with beautiful bay windows and gobs of free-space.  While barns can certainly be open, they should not include bay windows.  Have you ever seen the type of slime a dedicated horse can produce?  Second, it’s made out of modern materials: specially treated steel and composites …  and it’s cantilevered.  Words do not even begin to describe how wrong it is to cantilever a barn.  (Even if it is really a vacation home that some hack decided to call a barn.  I would never house animals, much less people in such a disgusting and clearly unsafe building.)

Traditional barns are so much better.  Traditional barns have character.

Similar Posts:

• Mud with character
• Greetings From a Horseman
• A Better Previous Versions: Time Traveler
• Trials and Travails of a Tack Snob
• So You Want to Learn to Ride

Copywrite 2009: Rob Oakes. Apolitically Incorrect

Barn Architecture

It’s a beautiful day outside.  We've been very lucky to have five or six such beautiful days in a row.  They are the type of beautiful day that generally encourages irresponsibility and miscellaneous recklessness.  The practical and otherwise successful have argued that being able to put off temptation, in this case enjoying such an amazing day, show the type of tenacity required for achievement.  They’re probably right, and while I might make claims on practicality; I harbor no delusions of success.  As a result, yesterday I decided to lay aside work and do things other things.

For the past several months, I have intended to write a series of small posts about basic and not so basic horsemanship.  Part of this desire stems from an utter dearth of information on important things: rawhide braiding and the making of a saddle horse, amongst others.  While I have the posts more or less drafted, I’ve felt that they lack a certain degree of clarity.  Horsemanship is a visual and physical activity and cannot be learned from reading, no matter how clear the words.  My little articles require pictures and illustrations.  A beautiful day gave me the perfect opportunity to go and take those pictures.  There was only one problem, I lost the telephoto lens to my camera several months ago.

(Actually, that’s not quite true.  More accurately, I loaned my very expensive camera and telephoto lens to my younger brother so he could photograph a car race.  The problem of having professional equipment is that everyone likes to borrow it.  And while the camera returned, the telephoto lens did not.  Of course, this isn’t his fault, it’s mine.  After all, “You shouldn’t have loaned me the camera!” was his response when interrogated about the lens.  The only response to such an accusation is, “Apparently not.”  Persuading him that he should replace the lens is beyond my ken; short of breaking bones that is.)

Thus, I also used the beautiful day as an excuse to purchase a new telephoto lens.  After all, I need spectacular photos!  The lens a Quanta-Ray, 18 mm to 200 mm zoom with a 3.5 to 6.3 F aperture.  If you don’t follow the numbers, don’t worry.  Just know that my new lens does wide angle to super-zoom, very nice!  Oh, and it has image stabilization.  I decided that horse photography requires image stabilization.  The fact that I’ve never owned a stabilized lens is a mere detail.

With the right conditions (a beautiful day), and the right equipment (telephoto lens); I figured that I could easily create stunning photographs that would wow, amaze and generally illustrate my points and desires.  After all, the pros make it appear so easy!

As the first photo of this post shows (which I grabbed from iStockPhoto.com), horses and cowboys with a helping of dust make for an amazing image.  Of course, part of this is due to the mythology of the cowboy, but a great deal more is simply due to a fantastic visual elements.

Turns out, though, that taking incredible photos of horses and riders is substantially harder than taking photos of landscapes and sunsets.  During a stint where I fancied myself a pro photographer, I learned that amazing photo shoots require absurd attention to detail.    Like painting or illustration, beautiful photography is all about fore-thought and planning.

Great landscape photographers will often visit the site where they intend to take their photos the day prior.  They think about where they want to be and at what times they need to be there.  This doesn't work when trying to photograph horses, in fact, horsemanship is essentially a chaotic exercise.

There is a reason why so many clinicians present their material in free form.  You have to adapt to the horse, not the other way round.  You can’t walk into a stall and patiently explain the material before hand, or the goals of a planned session.  Some horses insist on thinking and voicing their opinions.  I generally find this particular insistence to be quite obnoxious, at least when it comes to photography.  (It's one of the main reasons I'm fairly dedicated to horsemanship at all other times.)  For my little photography session, I wanted to work on one thing, and the horse I was riding decided that we needed to work on another.  Quite unfair, if you want my honest opinion.

After a half hour of wasted shots, I finally decided to adapt to the conditions and I was pleasantly surprised.  Rather than try and take photos for my posts, I decided to capture the stories unfolding around me in the arena.  Some of those stories were practical (and the photos will work great for my series of articles), while others were more artistic.  I figured that some of the artistic shots deserved their own post.  Enjoy!

Similar Posts:

• Greetings From a Horseman
• “Just let him kind of be there to explore a little…”
• So You Want to Learn to Ride
• The Head Balances the Feet
• On the Surface Versus Working Deep

Copywrite 2009: Rob Oakes. Apolitically Incorrect

Photos of Horses

As described in part 1 of this article, vector graphics offer a tremendous number of advantages over their raster counterparts. These benefits include the ability to enlarge the image to any size without a loss of detail or quality and better reproduction in both print and online form. Combined with the existence of many high quality icon libraries, vector graphics represent a valuable source of art for desktop applications.

In part 2 of this article, we looked at a way to convert vector graphics using Adobe Illustrator. While useful, the XAML export plug-in has a number of limitations and is not always able to faithfully convert the image to XAML. Thus, while Adobe Illustrator is a good conversion method when working directly with artists and graphic designers who are able to provide art files in Adobe Illustrator (AI) format, it is not so well suited to existing OpenSource libraries which tend to be distributed in the SVG format.

Due to their use of alpha transparency, Adobe Illustrator is always able to read the images from other editors, though it contains basic SVG support. This is unfortunate as these icon libraries, such as the Oxygen Icon Set, are freely available under permissive licenses. Fortunately, there is a way to overcome some of these limitations. In this article, I will look at how to convert SVG icons to XAML using the stand-alone utility XamlTune. We will also be using the OpenSource SVG editor, Inkscape.

SVG Icon Sources

Prior to delving into the process by which SVG can be converted to XAML, I thought it might be good to take a minute and highlight some excellent sources of high quality SVG art. These include a number of general resources as well as dedicated SVG libraries.

Wikimedia Commons

One of the better art libraries can be found at Wikimedia Commons. It includes an enormous number of public domain and free-licensed media content with a healthy section of SVG images. Some of the more popular examples include the Nuvola and Bluesphere themes. The database of images is both searchable and browseable.

While the vast majority of the images are available in the public domain or under permissive licenses, it is important to read the specific license of each image which will be used. Even when using OpenSource artwork, the type of license is important. Images released under the GPL cannot be used in commercial projects, for example.

Oxygen

The Oxygen icon theme is the default icon set for the KDE desktop. The sample artwork at the beginning of each of the parts in this series were taken from the Oxygen project. The set is licensed under both the LGPL and Creative Commons, as a result, it can be used in both commercial and OpenSource applications. There are a huge number of individual icons which cover actions, file types, and applications. Thus, between its beauty and permissive license, in addition to the fact that it is available in svg format, Oxygen is an ideal source of artwork. The Oxygen theme will be the source of the art used in this tutorial.

Figure 2. Sample images from the Oxygen icon set.

In contrast to the icons available at Wikimedia Commons, however, the Oxygen Icons can only be downloaded via Subversion. You will thus need either need to download the command line toolset, or a GUI client like TortoiseSVN. The Oxygen icons can be found at:

    svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase/runtime/pics/oxygen/

If you are working from the command line, go to the directory where you would like to save the icons., then type:

    svn co svn://anonsv.kde.org/home/kde/trunk/KDE/kdebase/runtime/pics/oxygen Oxygen

The icons will be downloaded to a folder called 'Oxygen.' If you want to only download the SVG versions of the icons, use:

    svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase/runtime/pics/oxygen/scalable

Method 2: Inkscape and XamlTune

Installation

To convert SVG icons using XamlTune is a two step process. You will need to have both Inkscape and Xamltune. A Windows Installer for Inkscape can be found here. XamlTune can be downloaded from its CodePlex download page. Click on the "Download Now" button on the right part of the page.

After XamlTune has downloaded, you will need to extract the binary and supporting libraries to a folder. It does not have an automatic installer. To run XamlTune, double click on XamlTune.exe. Alternatively, there is also a WebApp version, which can be found here. The in this tutorial were converted using the desktop application.

Program Use

XamlTune is only able to convert well-formed SVG to XAML. When I tried converting compressed SVG (svgz), it caused the program to crash. Thus it is very important to make sure that they are plain, vanilla SVG. If they were created by Inkscape, Krita, or OpenOffice Draw this is likely not the case. All three programs use markup not part of the SVG standard to properly render and edit the images. While this additional markup is ignored by viewers, it may cause a converter to crash.

Convert SVGZ to SVG

The first step is to then convert the distribution format to vanilla SVG. To do so:

1. Open Inkscape and load the file. 
2. Choose File > Save As
3. Select the destination and provide the name of the file. In the list of file types, choose Plain SVG and then click "Ok."

Conversion to Xaml – Desktop Application

The XamlTune UI includes two windows, which are shown in figure 3 below. The first window is used for input and the second window is used for output. You can either cut and paste the SVG into the text box or load it from file. The second window contains the conversion options, the converted XAML, and a preview of the converted image. It is possible to convert to both WPF and Silverlight XAML.

Figure 3. The XamlTune User Interface. There are two windows in the XamlTune UserInterface. The first is used for the data. The second window includes the conversion options, the converted XAML text and a preview of the converted image.

Once the image has been converted, it can be saved to the active directory by typing a filename and clicking the "Save" button. You will need to add the .xaml, as this is not done by the program automatically.

Examples

The examples below show images that were converted with XamlTune from plain SVG. In each case, there were significant differences between the source image and the converted XAML. The most common discrepancies were seen in shadows and complex gradients which used alpha transparency. I also noticed problems in images which made use of extensive typography, however.

The first example (Figure 4) is a beautiful rendering of a newspaper. It includes a number of complex gradients and makes extensive use of typography. In the exported XAML, many of the gradients were not correctly exported nor was the text.

Figure 4. The top panels show how the original SVG image appears in Inkscape. The detail at right has been zoomed to 400% of the original size. The bottom panel shows the XAML created by XamlTune. While most of the gradients and much of the illustration was converted without difficulty, the fonts and type were ignored.

In the second example (Figure 5) shows similar issues as the first. The color effects on the controls in addition to the shadows were not correctly exported. Other elements were shifted from their original location, which suggests that there may be an issue in keeping track of coordinates.

Figure 5. In this example, it is possible to notice some distortion in the converted Xaml. Some of the gradients were not properly converted and some of the controls have shifted location. The shadows have also not been correctly rendered.

In this third example, we see a complex example with gradients, shadows and lettering. Again, there are major discrepancies between the source image (left) and the exported XAML. In addition, there is also some distortion of the chip body.

Figure 6. As in previous examples, there are some major inconsistencies between the source image and the converted XAML. Shadows and some gradients did not transfer correctly. The background image of an X on the top of the chip was also omitted.

Conclusion

Much like XAML created with the Adobe Illustrator plug-in, there are often discrepancies between the source SVG and the final image. XamlTune struggled to consistently portray complex gradients (making use of alpha transparency) as well as to properly render shadows. Simpler images which lack these elements appeared to export without distortion. While not a perfect solution, both techniques allow for SVG assets to be converted to XAML and used in both WPF and Silverlight applications.

Similar Posts:

• WPF – SVG Graphics and XAML – Part 2
• WPF – SVG Graphics and XAML – Part 1
• Learning IronPython – Part 5 – A Rudimentary Download Manager
• Backup, Sync and Share – Part 5.2: Windows Vista Backup (Disaster Prevention)
• IronPython - Data Binding and Data Templates - Part 1

Copywrite 2009: Rob Oakes. Apolitically Incorrect

WPF – SVG Graphics and XAML – Part 3

In part 1 of this article, I introduced some of the difficulties in converting SVG graphics to WPF XAML. These included inconsistent implementations across SVG editors and the lack of a high quality XAML export. I also introduced two methods for the conversion of vector graphics to XAML. The first uses Adobe Illustrator and the second makes use of free standalone program called XamlTune. In this article will take a detailed look at the first of these methods. In part 3, we will look at the second method.

Method 1: Adobe Illustrator

When working on most vector graphics projects, there is really only one software program that really matters: Adobe Illustrator. While I'd like to say it is the 800 pound gorilla in the room, it is probably more accurate to say it is the only gorilla in the room. Given its near omnipresence in the artistic community, it is hugely convenient that there is a highly capable plug-in which can export high quality XAML directly from Illustrator.

Installation

Installation of the plug-in is simple and straightforward. You can find it at MikeSwanson.com, under XamlExport. After it has been downloaded, unzip it to the Illustrator Illustrator plug-in folder. For a Windows default installation of Create Suite CS3, the path is C:\Program Files\Adobe\Adobe Illustrator CS3\Plug-ins. If you don't have access to the administrator account on your computer or if you prefer to install to an alternate location, that is also possible. Go to Edit > Preferences > Plug-ins & Scratch Disks and put a check in the "Additional Plug-ins Folder." You can then specify a folder other than the default.

Once you have copied the XAMLExport.aip file to the proper folder, you will need to restart Adobe Illustrator. The export to XAML option can be found under File > Export. There will be options to export to both Windows Presentation Foundation XAML and Silverlight XAML. The export plug-in works with Adobe Illustrator CS, CS2 or CS3.

Plug-In Use

Using the plug-in, it is possible to export any file which Illustrator is capable of reading. This includes AI files, Illustrator compatible SVG files, and PDF files. The size of the exported images is adjusted by changing the document properties, found under File > Document Setup.

While the plugin will work on all file types, not all of the features of Adobe Illustrator are supported. Mark Swenson gives a detailed list at the download site, but there are a few import limitations that should be mentioned.

1. Text Export. In the current implementation, there is no support for WPF native text rendering. While it is possible to work around this limitation by choosing Select > Object > Text Objects then changing the text to an outline prior to performing the export (Type > Create Outlines), this is an imperfect solution.
2. Raster Images. There is no support for raster images that are part of the AI image. Illustrator images that incorporate any Photoshop documents or other bitmap style objects will not export correctly.
3. Illustrator Meshes. Illustrator meshes cannot be exported and will be ignored in the final output.

While the lack of text and raster image support prevent the export plug-in from rendering XAML that is 100% identical to the source image, it nonetheless produces high quality output from most Adobe Illustrator objects. I experimented with a number of logos and design elements with generally good results, though there were some issues with complex paths and gradients. Some examples are shown below.

Examples

In the first example (Figure 1), I have used a simple logo from the Scientific Computing Institute (SCI) at the University of Utah. A screenshot of the original as it appears in Illustrator is shown (top left panel) as well as two different exports. The first time I performed the export (seen in the top right panel), I did not first convert the text elements to outlines. As a result, the lettering was not converted to XAML correctly. In the second export (bottom panel), I converted the lettering to an outline prior to the export.

Figure 1. Original SCI Logo (top left) and XAML Export from Adobe Illustrator. In the first instance (top right), the text was not changed to an outline prior to export. As a result, it was ignored. In the second instance (bottom), the text was transformed prior to export.

In a second example (Figure 2), we see an example where an icon contains unsupported elements. While most of the image is faithfully rendered, there are two major issues. First, an error occurred when rendering the color of the inner path, which is supposed to white. This region appears as an off grey in the XAML. There was also an issue with the beautiful blue to violet gradient on the left of the image. In the XAML, it is rendered as a single color.

Figure 2. Amarok Icon. The image at left shows the original artwork in Adobe Illustrator and the image at right shows the exported XAML. There are two problems in the export. The center path is no longer white and the blue to violet gradient now appears as a solid band of light blue.

Figure 3 shows a particularly complex example which was rendered without any issues. The original image was created from a photo using Illustrator's LiveTrace feature. The image contains hundreds of individual paths, gradients and other elements. Yet, despite its complexity, it was rendered to XAML without problem.

Figure 3. XAML export of an Illustrator LiveTrace Image. Even though the image contains hundreds of paths and complex elements, the XAML export is an extremely good representation of the original image.

Summary

The XAML exporter plug-in provides high quality XAML directly from Adobe Illustrator without requiring any intermediate steps. This is convenient due to the near omnipresence of the Adobe products among artists and designers. However, the plug-in also has some serious limitations. It is not able to export native text and may have issues with complex gradients.

In Part 3, I will look at using XamlTune, a standalone converter utility.

_____________________________________________________

Acknowledgements, References and Further Reading

Further Reading

There is 25 minute video which explains the basic use and function of the XAML export plug-in. It is hosted on MSDN Channel09.

Legal Acknowledgements

The logo of the Scientific Computing Institute is copywrite (2008) by the University of Utah. It may not be used for commercial purposes without written permission from the University of Utah. The Oxygen Icon Theme is dual licensed under the Creative Common Attribution-ShareAlike 3.0 License as well as the GNU Lesser General Public License.

Similar Posts:

• WPF – SVG Graphics and XAML – Part 3
• WPF – SVG Graphics and XAML – Part 1
• Backup, Sync and Share – Part 5.2: Windows Vista Backup (Disaster Prevention)
• Learning IronPython – Part 5 – A Rudimentary Download Manager
• A Better Previous Versions: Time Traveler

Copywrite 2009: Rob Oakes. Apolitically Incorrect

WPF – SVG Graphics and XAML – Part 2

In a perfect world, most would be judged on the quality of their ideas and depth of character. However, more often they are judged by looks and dress.  What is true in the world of people is also true in the world of software. More than one website, computer program, or presentation has suffered because it is unattractive. In the inevitable fight between style and substance, substance often exerts more than its fair share of influence.

Given the importance of stylistic presentation, it is somewhat ironic that one of the most neglected components of many software projects it that of the artwork. While the code may be carefully vetted and analyzed, often icons and other artwork are chosen at the last stage of the design. While this might be unfortunate, it is due to an important reality: high quality artwork can be very, very expensive.

Fortunately, there are a number of beautiful graphics libraries that are either cheap or free of charge. Most are available under permissive or OpenSource licenses and can even be used in commercial products. There is just one problem; nearly all of these libraries are available in formats which don't play nicely with WPF and XAML. With a little bit of planning and strategy, however, it isn't too difficult to use these resources in your own applications.

Working with Vector Graphics

While there are a huge number of beautifully done vector graphics, it is important to understand a few basic things about vector images prior to working with them. These include how they are both similar to and different from traditional graphics formats, as well as some practical limitations and realities. It is also important to know which programs you will be working with. SVG vector graphics created in one program can't always be opened in another editor.

Traditional Image Formats Versus SVG: What Are the Differences?

Anyone who works with computers is familiar with the familiar types of image formats: jpeg, png, bmp, etc. These are the file types that come from digital cameras, scanners, and raster based graphics programs (such as Photoshop). A raster graphic is composed of a collection of (usually) rectangular pixels. In black and white images, there is value at each pxiel that describes the intensity. A value of zero corresponds to black while large values correspond to white. Values in the middle are differing shades of grey. Color images, in contrast are coded by values that correspond to red, green, or blue. These disparate values are then mixed to arrive at the final shade. Programs such as Photoshop and the GIMP edit the individual pixel values.

Figure 1. Example of a Raster Based Graphic. Raster images are composed of arrays of pixels. At each pixel location, there is a value that corresponds to the color of the pixel. Image Source: Wikipedia.

Raster images are dependent on the resolution which they are displayed. As can be seen in the example (Figure 1), the image looks better at low resolution. When it is enlarged to a high resolution, it becomes blurry.

In contrast to raster images, vector images are based on mathematical models. They combine different geometrical elements (such as points, lines, curves, shapes, etc) to describe the shape and color of the final drawing. They also make it easier to use a variety of advanced filters and processing tricks to generate effects such as transparency or light.

Vector images also offer another important benefit over raster images. They can be enlarged without a loss of quality. Figure 2 illustrates this point; it show how a vector image appears when it is enlarged. A bitmap, enlarged to the same size, is also shown for comparison

Limitations and Realities

While SVG has been adopted as an official W3C standard, it has never been really endorsed by any of the major software developers (which is ironic since it was initially developed and advocated by Adobe). This has led to a large number of parallel implementations, on both the proprietary and OpenSource sides of the fence. In addition to parallel implementations, SVG has suffered from limited penetration. The most common type of vector graphics in the art world isn't SVG, but rather the native file format of Adobe Illustrator, AI.

To further complicate things, many of the programs which read SVG files support different parts of the specification. While Adobe Illustrator can export directly to XAML through use of a plugin, the most common version of Illustrator (CS3) uses a rather basic implementation of the SVG standard. It lacks support for alpha channels and other advanced features, which makes it impossible to open images from other SVG editors.

It doesn't get much better from the OpenSource side of the fence either. File conversion and portability might charitably be described as "promising." The most popular editor, Inkscape, implements most of the features available in the WC3 standard; it doesn't, however, play nicely with other programs. It includes its own extensions to the file format. While these extensions should effect image portability in theory, I found otherwise in practice. In multiple tests, I was not able to export images to a format which could be read by Illustrator or other OpenSource editors. And while Inkscape has a plugin to export XAML directly, the output is garbled and unusable. Other OpenSource programs, such as OpenOffice Draw and Krita, offer only very basic support for the file format and are still under active development.

Figure 2. Example of a Vector Based Graphic. Vector graphics are composed of different geometrical shapes (points, lines, curves, etc) to describe the shape and color of final image. Vector graphics can be scaled to any size without losing any quality. Image Source: Wikipedia.

Microsoft is hardly a champion of interoperability either. There is only one program which can read and write XAML files directly; Microsoft's own Expression Suite. In a rather egregious oversight, the Expression suite lacks an easy way to import SVG and directly convert it to XAML.

So while WPF includes support both raster and vector images, many of the more advanced features of WPF (including resolution independence) really need vec tor graphics to function properly and getting the more common SVG file formats (.ai and .svg) converted to XAML can be difficult.

The Solutions

Luckily, however, there are two ways to successfully convert SVG to XAML. Determining which method to use largely depends on the source of the file.

1. The first uses an Adobe Illustrator plugin to export AI files too XAML. This method should be used when working with professional artists or graphic designers (who are likely to use the Creative Suite of Applications).
2. The second makes use of a free standalone program (XamlTune) to convert properly formatted SVG to XAML. This process makes the most sense when using existing OpenSource libraries or other freely available samples.

In the next article in this series, I will look at these two methods in depth.

_____________________________________________________

Acknowledgements, References and Further Reading

Additional Reading

There is an overview of why WPF uses a different specification than SVG to display vector graphics on Jon Galloway's blog.

Mike Swanson, author of the XAML Adobe Illustrator Plugin, has a dedicated page which describes the installation and limitations of the plug-in. This includes a sample gallery with a number of complex examples.

On UXPassion, there is a tutorial about how to convert to XAML using a PDF intermediary.

Legal

The image examples in this tutorial were taken from Wikipedia and are available in the Public Domain. The logos and images of the Scientific Computing Institute (SCI) are copyrighted (2008) by the University of Utah. They may not be used for commercial purposes without written permission from the University of Utah. The Oxygen Icon Theme is dual licensed under the Creative Common Attribution-ShareAlike 3.0 License as well as the GNU Lesser General Public License.

Similar Posts:

• WPF – SVG Graphics and XAML – Part 2
• WPF – SVG Graphics and XAML – Part 3
• Backup, Share and Sync – Part 2: Hard Drive Preparation and Server Configuration
• Backup, Sync and Share – Part 5.2: Windows Vista Backup (Disaster Prevention)
• IronPython - Data Binding and Data Templates - Part 1

Copywrite 2009: Rob Oakes. Apolitically Incorrect

WPF – SVG Graphics and XAML – Part 1

I've been doing a bit of research for a short writing project. While doing so I came across this post over at WebUrbanist.  Though it is a bit of an oldie, it is still a goody!  In brief, the author looks at twenty four abandoned towns and cities from all over the world trough mini-photo essays.  Reading through the descriptions and looking at the images sent my wander-lust far into the red-zone. Ever thought about diving the ruins at Alexandria?

Me and Sewell

(Photo) The supply train arriving from Rancagua. The train was used to carry supplies and other materials as well as men. Everything at the site had to be brought in.

I found the little blurb on the town of Sewell, Chile to be particularly interesting as I've been to Sewell.  While living in Chile during 1999 and 2000, I and several friends made a day-trek to the place.  At the time that I went, I didn't have anything better to do and so I didn't know anything about it.  Neither, for that matter, did any of my friends.  We were there because a few of the locals said that it was an important part of Chilean history and that we should visit.  So, we did.

Unreal only begins to describe the experience.  Rather than a town, Sewell might better be described as a temporary labor camp that grew roots and notions.  It is built on the side of an outrageous cliff and was only accessible via train. We started our visit by piling onto the labor bus for the mine workers and then spent the next two hours winding our way up dirt roads that climb from Rancagua (near sea level) to the camp, which is above 6000 feet.

As the town was built off the side of a mountain, it has no streets (this becomes obvious when you look at a photo of the place; the impression you get when there is even more impressive). You can only get around via the (many) stairs. What is truly bizarre, however, is that everything is still there!  A lot of things look like the workers just stepped out and will probably be right back. The brightly colored buildings are still bright and the "streets" are in excellent condition. In fact, some of the accommodations appeared more comfortable than my apartment in Rancagua.

(Left) The abandoned mining city of Sewell, Chile during the 1930s. Sewell was finally closed in 1977, some ten years after the mine (known as El Teniente) was nationalized by the Chilean Government.

At its time, the place was an absolute thriving metropolis. There were 16,000 people that lived there from all over the world. Even more impressive, it thrived in what was otherwise a wasteland. Though 6000 feet certainly isn't the roof of the World, the mountains surrounding El Teniente are fairly barren and host snow for much of the year.

If you get a second, head over to the Wikipedia page and read a bit more about the place. Also be sure to check out the Retro Ski page, which has some really cool pictures.

Similar Posts:

• Customizing LyX: Create an NIH Grant Proposal Template
• Typeset Your Curriculum Vitae – Part 3: Automatically Generate a List of Publications
• Introducing LyX-Outline 0.1
• Filing Bugs for Time Drive or LyX-Outline
• Learning IronPython – Part 2 – A Simple Project

Copywrite 2009: Rob Oakes. Apolitically Incorrect

Forgotten Places – Sewell, Chile