Depth-First: Tag svg

A Simple Vector Graphics API for Chemical Structure Output Part 1: In Search of a Simplifying Approach for ChemPhoto

Rich Apodaca — Fri, 31 Oct 2008 18:25:00 +0000

One of the main design goals of ChemPhoto, the chemical structure imaging application, was to support all Web-relevant image output formats, both vector-based and pixel-based. Like most things in software development, there are far more approaches that add complexity to this problem than there are approaches that remove it. And for some reason, the complexity-reducing methods tend to be the last to be considered. This article, the first in a series, will discuss how ChemPhoto simplifies the problem of supporting multiple chemical structure image output formats from a common representation.

The Problem in a Nutshell

ChemPhoto uses an internal representation of molecular structure based closely on the industry-standard MDL molfile format. Given this representation, ChemPhoto needs to be able to write a variety of vector- and raster-based image formats. Raster formats are fortunately limited to PNG and JPG, which are supported directly by the standard Java library.

Vector formats, on the other hand are more diverse and less accessible. Currently, ChemPhoto supports Scalable Vector Graphics (SVG) and Encapsulated PostScript (EPS). Complete support for Adobe Flash (SWF) output is expected soon. Proof of concept for Microsoft's Vector Markup Language (VML) has already been demonstrated. Support for Adobe Acrobat format, through the iText library is anticipated. Last but not least is Java2D itself for use in Swing components such as renderers and editors.

Clearly, supporting all of these formats requires rendering code that is minimally coupled to the underlying display system. But how to do this in practice?

The Batik Approach: Extend Graphics2D

Batik is a widely-used library for creating and processing SVG in Java. At its core is the SVGGraphics2D class which extends Graphics2D, overriding many of its methods in the process. The idea seems simple enough - create your drawing code using the Java2D API like you normally would. When you want to generate SVG, just pass an instance of SVGGraphics2D and then read out the SVG document using stream method.

The problem with this approach is that every new image output format to be supported needs to extend Graphics2D and essentially re-implement most of its methods. Graphics2D is a large and complex class with many associated helper classes. Just knowing when you've completely covered the API is a major challenge, aside from the even bigger challenge of implementing the overridden methods.

Fine, you might say, given that so many SVG interconverters exist, why not just use SVG (created by Batik) as the universal interconversion format and get a third-party-library to convert SVG into other vector formats?

This approach is appealing in principle, but fails in practice. Many SVG implementations are partial at best - and many lack the documentation that would warn that a problem might exist with the exact form of SVG you're using. For example, in an early iteration of ChemPhoto, Batik was used to create SVG from some representative chemical structures. Unfortunately, the way Batik represented path data was not fully interpreted by any of the SVG->SWF converters that were examined. The result was bumpy instead of smooth curves for atom labels, and other unacceptable abnormalities.

Finally, after spending some time reading J. David Eisenberg's excellent book about SVG, it became clear that for drawing 2D chemical structures and even reactions and reaction schemes, only a fraction of the SVG specification was relevant.

In this case, Batik, and its approach of extending Graphics2D was simply overkill that made the problem more complex than it needed to be.

A Better Approach: Create a Custom Vector Graphics Interface

Batik has the right idea: isolate drawing code from the specific format being generated. The problem is that the Graphics2D class wasn't really designed for this purpose. For one thing, it's a concrete class that inherits from another concrete class. And as mentioned before, Graphics2D a very complex class with many dependencies.

How can we create a simple vector graphics API tailored to chemical structure image creation, which is easily re-implemented, and which works with the existing Java2D API?

Part 2 of this series will describe one approach.

Conclusions

Creating the ChemPhoto rendering engine has been an evolutionary process. It started with the idea of directly using the Graphics2D class in rendering code, but has since moved on to the definition of a vector graphics abstraction layer to simplify the addition of new image formats.

I'd like to thank those beta testers who have already offered valuable feedback on ChemPhoto. If you'd like an unlimited 30-day trial for yourself, please drop me a line.

Image Credit: estherase

Smarter Cheminformatics: From SD File to Image Collection with ChemPhoto

Rich Apodaca — Mon, 08 Sep 2008 19:04:00 +0000

The old adage says time is money. Unfortunately, working chemists are often forced to spend a remarkable amount of valuable time and mental effort on menial chemical information processing tasks. These are things that could be done faster and with better quality by the right software, if it were available. Most importantly, these tasks take resources away from much more valuable work that can't be automated.

The Problem in a Nutshell

As a case in point, consider the creation of 2D chemical structure images. If you maintain a compound collection of any kind, sooner or later you may end up asking yourself how you can create a set of images depicting the chemical structures in your collection.

A Specific Example: Chemical Suppliers

For example, you might work for a chemical supplier that maintains a Web-based eCommerce site, one or more PDF catalogs, or printed brochures. Your customers are chemists and they expect to see chemical structures in your product listings. How can you make this happen?

If you look around for software that automates this job, you'll more likely than not come up empty-handed. The software that solves this problem well simply doesn't exist yet.

Doing it the Hard Way

In the absence of software to solve the problem, the only way to get the job done is to buckle down and do it manually. Most chemical structure editors allow you to save output as a raster image. Provided that this output matches your requirements, your system might consist of the following steps:

(1) For every product in your catalog, create a single molfile or its machine-readable equivalent.

(2) Load one file into your editor.

(3) Save the file as a raster image, being careful to make sure all of the drawing settings and image size parameters are identical to the rest of your images.

(4) Repeat Steps (2)-(3) until you have all of your images.

There are many problems with this approach. For example, if your images ever need to be made larger (or smaller), you'll have to create all of your images over again (which can easily number in the thousands). Similarly, if for some reason you want to change the appearance of the images such as background, atom label coloring, or line thicknesses, you'll be forced into a lot of manual work. Finally, this system requires you to keep track of structures that have been imaged and those that haven't, which can in itself be nontrivial and error-prone, especially for thousands of products.

With the right software, this problem would disappear.

One Solution: Customized Imaging Service

My company, Metamolecular, has recently provided custom imaging services to a few chemical suppliers wanting thousands of good-looking structure images rendered automatically. The service made use of the versatile ChemWriter rendering engine together with some custom code written in Ruby.

Although the imaging service works very well as a one-off solution, it's less than optimal in the longer term. Any changes to the image collection must be processed by Metamolecular, and then sent back to the client. A cheaper and faster solution would be to offer software that implements the functionality of the service.

A Better Solution: Chemical Structure Imaging Software

Wouldn't it be great if easy-to-use software existed that could automatically generate thousands of chemical structure images with the press of a button?

In particular, the software should:

Run on any modern platform (Windows, Mac OS X, Linux).
Read industry-standard Structure Data Files (SD Files).
Be capable of working with tens of thousands of chemical structures at a time even on older machines.
Store fully-customizable drawing settings in a format that could be used over and over again for a consistent and professional look.
Allow the output to be previewed exactly as it will appear in the generated images ("what you see is what you get").
Output to a variety of image formats, including: Portable Network Graphics (PNG image); JPG image; Flash (SWF file); Scalable Vector Graphics (SVG); and Encapsulated PostScript (EPS file).

Introducing ChemPhoto

ChemPhoto is designed to solve the problem of consistently creating large numbers of high-quality 2D chemical structure images. Currently in development, the first versions of ChemPhoto will be available for review within the next two weeks.

ChemPhoto consists of a lightweight and intuitive user interface layer built on top of the ChemWriter rendering engine. ChemPhoto focuses on doing one thing very well, so it wouldn't be useful for creating or editing SD Files (a task for which many tools already exist). The software is specifically designed to work well with large SD Files, such as the 25,000-structure sets that can be obtained from PubChem. Written in Java, ChemPhoto runs on Windows, Mac OS X, and Linux. Future articles will discuss ChemPhoto's design and implementation.

If you're interested in evaluating ChemPhoto, feel free to drop me a line.

Adobe Flash for Cheminformatics: Fast, Scalable, and Attractive 2D Depiction of Chemical Structures with Vector Graphics

Rich Apodaca — Tue, 10 Jun 2008 11:05:00 +0000

The previous article in this series discussed the use of vector graphics markup languages for cheminformatics, in particular for the display of 2D chemical structures. Although vector graphics are well-suited for creating responsive and appealing cheminformatics Web applications, the lack of universal native browser support makes both Scalable Vector Graphics (SVG) and its cousin Vector Markup Language (VML) unattractive at this time. This article highlights Adobe Flash as a 2D chemical structure renderer for Web applications, and features a fully-functional proof of concept based on the ChemWriter rendering engine.

About Adobe Flash

Although Adobe Flash is practically an industry unto itself today, at it's core, Flash is a lightweight vector graphics renderer. Introduced in 1996, the Flash Player can be found on millions of Internet-enable devices today. According to a study by Adobe, the Flash Player was running on nearly 99% of Internet-enabled desktops as of March 2008. The player has also found its way onto a host of handheld devices and phones.

Many technologies have been layered on top of the Flash Player. One of the first was the ActionScript scripting language. More recently, Adobe has introduced Flex, a full-fledged application development framework.

Unlike SVG and other vector graphics systems, Flash is ready today, proven, and about as close to universal as is possible on the Web. If you want to do vector graphics on the Web with the most convenient user and developer experience, Flash is your tool.

But what can Flash do for cheminformatics?

A Demonstration

The table below is composed of twelve cells, each of which display a chemical structure through the Flash Player.

zoom	zoom	zoom
zoom	zoom	zoom
zoom	zoom	zoom
zoom	zoom	zoom

Several points are worth mention:

Each of the structures can be zoomed by clicking on its 'zoom' link.
Each cell contains a lightweight embedded "SWF" file, or "ShockWave File," and the zoomed view displays exactly the same file. No matter how the SWF file is resized, it will always be proportionally-scaled to its smallest dimension and centered.
The size of each SWF file ranges from a low of 563 bytes to a high of 8.5 KB, with an average of around 1.5KB. The larger the molecule, the more space is required. A comparable PNG with a resolution of 150x150 pixels would require on average for each structure about 6-8 KB.
Each image was generated from a molfile using a development version of the ChemWriter rendering engine via the open source Transform SWF Java toolkit.
SWF Files, unlike applets, are highly optimized for multiple instance display on all major platforms and browsers. In every case, startup will be nearly instantaneous and scrolling will be smooth. The performance of Flash should be at least as good as, if not better than, raster images.

The Right Tool for the Job (is Probably not a Raster Image)

One of the first challenges developers of cheminformatics Web applications are faced with is how to render 2D chemical structures. For an overview of the technologies now in use, see the previous article in this series. Each option has its own set of trade-offs.

The most widely-used 2D structure rendering option, raster images, is both inflexible and inefficient. Unlike a vector image, a raster image by definition has only one resolution, which is fixed at creation time. If image dimensions need to change, then all structures must be re-imaged. Given the size of many of today's chemistry databases, such a system-wide re-imaging of structures can involve a non-trivial amount of processor power and bandwidth.

To compensate, many sites store relatively large images, say 300x300 pixel, and then use the HTML <img> tag to shrink it as needed. But this creates problems of its own: both storage and bandwidth requirements are far larger than they need to be, resulting in the need for more powerful server hardware and poorer application scalability. And then there are the application's users, who must wait through a 30KB or higher download for each 2D image.

A significant number of structures in any compound collection will be so large that even a 300x300 pixel image will be insufficient to render the necessary detail. For example, a recent Depth-First article discussed a vector graphics solution this problem within the context of Chempedia, the free chemical encyclopedia. Vector graphics simply eliminate this issue.

Many cheminformatics applications would benefit from being able to show 50 or more structures at a time, with each structure having a zoom view for closer inspection. To a non-chemist, this might seem unnecessary. But for today's chemists dealing with large chemical catalogs and high-throughput screens, it's not only possible, but a routine part of the practice of chemistry. The raster image approach makes it extremely difficult to meet this important need on the Web. Vector graphics, possibly delivered through the Flash Player, offer a much simpler and more efficient way to do it.

2D chemical structures are vectorial in nature; using raster images to depict them is in most cases the more costly and lower quality option.

Summary

Vector graphics are a near-perfect match for the job of depicting 2D chemical structures on the Web. Although there are many vector graphics platforms to choose from, the Flash Player is by far the most universal option. This article has demonstrated a working example of multiple 2D chemical structures rendered as lightweight vector images via the Adobe Flash Player, the first and only such demonstration of which I'm aware.

The key technologies behind this demonstration are the ChemWriter rendering engine and the open source Flash developer toolkits available from Flagstone Software. If you're interested in learning more about how vector graphics and Flash can improve both the user and developer experience in your cheminformatics Web applications, I'd be happy to hear from you.

The Other Vector Graphics Markup Language

Rich Apodaca — Fri, 06 Jun 2008 14:39:00 +0000

Scalable Vector Graphics (SVG) is a technology that enables the creation and publication of high quality images that can be scaled to any resolution. SVG is ideally suited for the Web, and all major browsers now support it - except Internet Explorer (IE). This poses a problem: vector graphics are by far superior to raster images for many applications, but the lack of native IE support makes SVG a non-starter for most developers. This article discusses a little known IE capability that might provide a solution.

Oh Brother, Where Art Thou?

Way back in 1998 a group of companies including Microsoft submitted a proposal for a vector graphics language called Vector Markup Language (VML) to the W3C. This set in motion a series of events that culminated in the development of what we know today as SVG. But while use of SVG quickly expanded, VML remained almost exclusively limited to Microsoft products.

Soon after, IE 5 introduced the ability to decode and display VML - a capability that exists today in IE 7.

SVG and VML are two vector graphics languages, each designed to do essentially the same thing. For basic shape rendering, their similarities outweigh their differences.

About VML

To understand why VML never caught on, you need look no further than the documentation - or the lack thereof. The original VML submission is a decade old and has not been updated.

For the most part, VML documentation is scattered and incomplete. Nevertheless, there are some useful resources. Here, in no particular order are some of them:

Microsoft Documentation Authoritative, but lacking in examples.
VML, SVG, and Canvas Discusses some of the differences between VML and SVG.
Cum mortuis in lingua mortua Good history of VML.
Examples of the Vector Markup Lanugauge There are far too few of this kind of site.
VectorConverer A PHP library that uses XSLT to interconvert SVG and VML. Unfortunately, the stylesheet didn't work in my hands under Xalan or Ruby/xslt - and I know almost nothing about PHP.
Julie Nabong's Masters Thesis Julie wrote and documented an SVG/VML XSLT for interconverting the two languages.

JSDrawing: Interconverting Vector Languages on the Fly

One VML resource deserves special note - JSDrawing. This library seems to be capable of generating Flash, VML, or SVG from a common vector graphics language precursor. I'm not sure how practical this approach would be, but it does provide some food for thought.

Why It Matters

Chemistry is in a good position to take advantage of vector graphics. Chemical structures, being closely based on graph theoretical constructs, would seem to be a perfect match for vector languages like SVG and VML, especially on the Web. So far it hasn't happened, primarily for the reasons outlined above.

Currently, if you want to display 2D chemical structures in Web pages you're faced with some tradeoffs:

Raster Images. This is by far the most common practice. This option unfortunately makes it very difficult to redesign the layout of a site or support multiple views of the same structure, especially with databases of one million plus compounds becoming commonplace. Even if images are never regenerated, they need to be stored and retrieved, adding to cost and complexity. Images could be dynamically generated, but at the expense of substantial memory and CPU requirements.
Applets. This is the approach currently taken by Chempedia, the free chemical encyclopedia, and gives complete flexibility in page layout and structure appearance. Changing the dimensions of a structure is as simple as changing the size of a div. Unfortunately, some browsers handle multiple applets better than others. Firefox on OS X is very slow at refreshing applets while scrolling, and IE requires a Javascript trick to remove the 'click to active' message that causes some flashing when in progress.
Vector Graphics Through Plugins There are at least two SVG plugins for IE (one by Adobe and the other from Examotion). Will all of your users be able to find and install them? Unless the answer to both questions is 'yes', this option is probably best left as a last resort. Another option is to render SVG on IE through the Flash or Silverlight plugins. But as far as I can tell, neither approach is ready for prime-time.
Native Vector Graphics Available on all major browsers including Internet Explorer 5/6/7, Firefox 1/2, and Opera 8/9. Combines the flexibility, lossless depiction, inlineability and low data storage/retrieval overhead of applets with the speed of images. Interactivity and other special effects can be achieved through DOM manipulation. All of this depends, of course, on the vector graphics format being compatible with the rendering engine.

In some circumstances, serving VML to IE clients and SVG to everyone else would be a viable option - if it were possible to generate VML.

Conclusions

Vector graphics have a lot to offer chemistry, especially when used with Web applications. The combination of VML and SVG offers a proven technology platform that's ready today, but only if you can generate VML.

Molecular Style Sheets: Combining SVG and CSS

Rich Apodaca — Fri, 20 Oct 2006 14:02:00 +0000

Cascading Style Sheets (CSS) are used by Web developers to modify the appearance of an HTML document without requiring changes to the document itself. This approach has become so popular because of the power it offers: developers can achieve a consistent and re-usable look by simply editing and/or copying a single document.

2-D molecular structures are like text documents in that context determines the best presentation style. For example, the way that a 2-D structure appears on a Web page, complete with atom color coding and anti-aliasing, may not be the best way for it to appear on a handheld device. Consider these use cases:

An online publisher may want to achieve a consistent "look" for their 2-D molecular graphics, regardless of who generated them. For portability, they want to avoid hard-coding the styling information into the software they use.
You want to be able to re-use the 2-D structures you've downloaded from a blog in your presentation. The appearance of these structures needs to match those you already have.
An online substructure query may return results to a user that have been highlighted to indicate the atoms and bonds where the query hit. The user may want to set his or her own highlight color, or disable the feature altogether.

Users of ChemDraw and software like it are probably familiar with its concept of styles. This is the right idea, although limited in practice. The main limitation is that these products are aimed at single users on desktop machines that are willing to do a great deal of manual work to achieve consistency. Something far more general and automated is going to be needed, and to my knowledge it does not yet exist.

Could the style sheet concept be applied to 2-D structure diagrams? It turns out that SVG may offer a solution. Just as the appearance of an HTML document can be styled with CSS, so too can the appearance of an SVG document.

A Demonstration: Highlighting Bonds

As a demonstration, we'll see how a style sheet can be used to highlight one of naphthalene's rings, possibly as a result of it being hit by a substructure search.

Consider the above 2-D structure of naphthalene, which was generated by Structure-CDK, the latest version of which can be downloaded here. The SVG that generated this image is shown below. I have edited the commented lines.

<?xml version="1.0" encoding="UTF-8"?>

<!-- Edit: a stylesheet -->
<?xml-stylesheet href="style_normal.css" type="text/css"?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.0//EN' 'http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd'>

<svg fill-opacity="1" xmlns:xlink="http://www.w3.org/1999/xlink" color-rendering="auto" color-interpolation="auto" text-rendering="auto" stroke="black" stroke-linecap="square" stroke-miterlimit="10" shape-rendering="auto" stroke-opacity="1" fill="black" stroke-dasharray="none" font-weight="normal" stroke-width="1" xmlns="http://www.w3.org/2000/svg" font-family="&apos;Dialog&apos;" font-style="normal" stroke-linejoin="miter" font-size="12" stroke-dashoffset="0" image-rendering="auto">

  <defs id="genericDefs" />
  <g>
    <g text-rendering="optimizeLegibility" stroke-width="0.098" transform="scale(47.2947,47.2947) translate(0.049,3.1127)" stroke-linecap="round" stroke-linejoin="round">
      <line y2="-0.7" fill="none" x1="4.8497" x2="4.8497" y1="-2.1" />
      <path fill="none" d="M4.8497 -2.1 L3.6373 -2.8 M4.5581 -1.945 L3.6488 -2.47" />
      <path fill="none" d="M0 -2.1 L0 -0.7 M0.28 -1.925 L0.28 -0.875" class="hit" /> <!-- Edit: hit -->
      <line y2="-2.8" fill="none" x1="0" x2="1.2124" y1="-2.1" class="hit" /> <!-- Edit: hit -->
      <path fill="none" d="M4.8497 -0.7 L3.6373 0 M4.5581 -0.855 L3.6488 -0.33" />
      <line y2="0" fill="none" x1="0" x2="1.2124" y1="-0.7" class="hit" /> <!-- Edit: hit -->
      <line y2="-2.1" fill="none" x1="3.6373" x2="2.4249" y1="-2.8" />
      <path fill="none" d="M1.2124 -2.8 L2.4249 -2.1 M1.224 -2.47 L2.1333 -1.945" class="hit" /> <!-- Edit: hit -->
      <line y2="-0.7" fill="none" x1="3.6373" x2="2.4249" y1="0" />
      <path fill="none" d="M1.2124 0 L2.4249 -0.7 M1.224 -0.33 L2.1333 -0.855" class="hit" /> <!-- Edit: hit -->
      <line y2="-0.7" fill="none" x1="2.4249" x2="2.4249" y1="-2.1" class="hit" /> <!-- Edit: hit -->
    </g>
  </g>
</svg>

In the image of naphthalene rendered above, the stylesheet I used was blank. However, by applying the following one-line style sheet, I can significantly change the appearance of this image:

*.hit { stroke: red }

This line is known as a "class selector." A CSS-aware SVG renderer (such as Firefox), after loading this style sheet, will apply the red stroke styling to all elements containing the hit class attribute. The output, shown below, highlights one of the rings of naphthalene in red.

Interestingly, the SVG document itself says nothing about what color the hit class should be - that's left for the style sheet to determine. So by changing one line in the style sheet, I can change the appearance of the hit highlighting to purple, green, or aquamarine. And this applies not only to colors, but to line thickness, line shape, anti-aliasing, and a variety of other properties.

Another Demonstration: Global Line Thickness

It's also possible to globally affect the appearance of naphthalene with a simple style sheet. For example, the following style sheet changes the line thickness and all line colors of naphthalene:

* { stroke-width: 0.25; stroke: green; }

When the naphthalene SVG is rendered with this style sheet, the image shown below is produced. The "*" selector is a wildcard, applying to all elements in the SVG document. This version of the style sheet ignores our "hit" styling from the example above. The hit styling could easily be added back in by adding the appropriate class selector line to the CSS.

You may notice in the image above that the leftmost vertical line appears clipped on its left side. This is because the SVG output from Structure-CDK exactly aligns the left line border with the leftmost side of the image area. By thickening the lines with a style sheet, we've overrun the image area. This could be fixed by moving the SVG viewport to the left. But that's a subject for another time.

A Limitation

It will probably never be possible to modify the distance between parallel lines, as for example in multiple bonds, with the CSS approach. These distances are set in the coordinate attributes of the line and path elements, and are independent of styling.

Conclusions

Of course, we're just scratching the surface of what's possible with CSS and 2-D molecular structures. For example, the same principles outlined here could be used for atom coloring schemes and a variety of line and drawing properties. Various forms of interactive animation are even possible. Despite its limitations, SVG and CSS make a powerful combination for developing next-generation molecular rendering platforms.

The Chemically-Aware Web: Are We There Yet?

Rich Apodaca — Wed, 13 Sep 2006 13:25:00 +0000

Recently, I wrote a tutorial on embedding 2-D molecular renderings into webpages as Scalable Vector Graphics (SVG). This tutorial also contained a small experiment on the current chemical informatics capabilities of the Web.

Here is a scenario from the near future: Joe is writing a review on Cephalosporin C that he wants to publish the modern way - directly to the Web. An entirely new concept in scientific publishing has started to take hold. Rather than submitting scientific articles to publishers, who then make hamburger out of them and strip authors of their rights to reproduce their own work, a new system in which journals simply aggregate content already on the Web is gaining momentum. Some journals specialize in only including the very best scientific Web content available, and so enjoy a prestige factor. It's still a peer review system, but with inversion of control. The trick for scientists is getting their work indexed, and so noticed, in the first place.

Joe just downloaded a new 2-D structure editor, FooChemPaint, that he heard can make the structure drawings in his review structure-searchable. Every chemist he knows is talking about a new free search engine called Haystac (Haystac Ain't Chmoogle) that lets them substructure-search the web. For some reason, you need to create your structures using FooChemPaint if you want your own documents to be included in the search results.

After Joe finishes drawing Cephalosporin C with FooChemPaint, he chooses the File->Save As... menu item. Instead of saving as a JPG or PNG like he's done with other software, he saves the image as SVG. He then embeds the SVG into his review using a procedure similar to the one I outlined previously.

From Joe's perspective, he hasn't done anything very new. But unknown to Joe, FooChemPaint has automatically inserted the InChI identifier of Cephalosporin C as metadata into his SVG document. This enables ordinary search engines such as Google to associate the InChI with his SVG. The best part is that the entire process is essentially invisible to Joe.

Haystac is a web application that presents users with an online structure editor for preparing molecular queries. When a structure query is submitted, Haystac searches its molecular database for matches. This database, in turn, was built by a web spider specifically designed to look for InChI identifiers, maybe with the help of Google's Web API. One of Haystac's records for the structure of Cephalosporin C points to Joe's review article.

Science fiction? Maybe. This is where the experiment comes in. Before I submitted the article on SVG, I manually annotated the SVG of Alprazolam with the corresponding InChI. The XML source can be viewed in Firefox by right-clicking on the SVG image and choosing This Frame->View Frame Source, or alternatively here. Below is a fragment of the XML:

<svg ...>
  <rdf:RDF
    xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
    xmlns:dc = "http://purl.org/dc/elements/1.1/" >
    <rdf:Description about="http://depth-first.com"
      dc:title="InChI=1/C17H13ClN4/c1-11-20-21-16-10-19-17(12-5-3-2-4-6-12)14-9-13(18)7-8-15(14)22(11)16/h2-9H,10H2,1H3"
      dc:format="image/svg+xml"
      dc:language="en" >
      <dc:creator>
        <rdf:Bag>
          <rdf:li>Richard L. Apodaca</rdf:li>
        </rdf:Bag>
      </dc:creator>
    </rdf:Description>
  </rdf:RDF>

  <!-- etc. -->
</svg>

Today I searched for the title of my article in Google and found it. I then searched for the InChI in the SVG metadata and did not find it. Currently, a search of this InChI shows only one hit from the DrugBank database.

The experiment failed in its stated goal of getting the InChI of Alprazolam indexed by Google via the metadata in its SVG rendering. Was it the formatting of my RDF tags? Is metadata just indexed more slowly than other content? Does Google just ignore metadata to avoid keyword stuffing by Search Engine Optimization tricksters? Are embedded SVG documents ignored by Google altogether? Whatever the reason, the technical barriers to a system like this working today are very low and dropping rapidly.

Generating and Serving 2-D Molecular SVGs

Rich Apodaca — Sat, 09 Sep 2006 14:45:00 +0000

A previous article showed some examples of 2-D molecular rendering using Scalable Vector Graphics (SVG) embedded in a web page. This article will outline some simple steps for generating these images and publishing them on the Web.

Prerequisites

This tutorial uses Structure-CDK, a CDK add-on library written in Java. You'll need to install Sun's JDK 1.4.2 or later (or an open source alternative). Although not required, Ant makes it easy to use Structure-CDK. You'll want to make sure that your browser is SVG-enabled.

Creating a 2-D Molecular SVG File

Methylenedioxymethamphetamine (MDMA)

An SVG image like the one shown above can be created with this sequence of steps:

Download and unzip the current release of Structure-CDK.
Move into the unzipped Structure-CDK directory and run the Structure Visual Testing Framework:
```
$ cd structure-cdk-0.1.2
$ ant vis
```
From the File menu, choose Open... and use the file dialog to open a molfile. The molfiles directory contains some samples.
Resize the image to taste and choose Save as SVG... from the File menu. This writes the SVG image to a directory and filename of your choice.

Viewing the SVG File

You now have several options for viewing the SVG file. One of the simplest is to open it with the Firefox browser. Another option is to open it with the excellent, free SVG editor Inkscape. From Inkscape, you can edit your image, apply any number of special effects from the mundane to the remarkable, and save the result to disk.

Deploying the SVG File on the Web

After uploading your SVG file to a blog or other site, you may have some additional configuration to do. Because the SVG MIME type is not configured by default on all servers, you may need to do so yourself.

After uploading my first set of SVG files to my server, I tried to view them in Firefox. Instead of seeing the expected image in the browser window, I got a dialog asking if I wanted to open it with Inkscape or save it to disk.

With the help of some documentation, I was able to track the problem down to my server, which was using the MIME type "image/svg-xml" instead of "image/svg+xml". The former is the obsolete SVG MIME type, which Firefox rejects. Internet Explorer equipped with Adobe's SVG plugin, on the other hand, accepts the obsolete MIME type, rendering SVG without presenting a dialog. Web-Sniffer, which decodes header information from HTTP responses, may be useful for debugging your server's MIME type configuration.

Having configured your server's SVG MIME type as "image/svg+xml", pointing your browser to your SVG file's URL will let you view it in its full, W3C-compliant glory.

Embedding the SVG File in HTML

There are a few options for embedding an SVG image in HTML. The most universally-applicable mechanism is the <embed> tag:

<html>
  <head></head>
  <body>

  <!-- document body -->

  <embed src="url-to-svg-file.svg" TYPE="image/svg+xml" width="400" height="400" />

  </body>
</head>

Embedding SVG into HTML carries some limitations. For example, you can't interact with the SVG DOM the way you can if the SVG is inlined, or placed directly into the HTML document itself. But that's a subject for another time.

Creating and deploying 2-D molecular images as SVG documents is a straightforward process, provided that some details are taken care of. Future articles in this series will show how SVG's advanced features make it a compelling choice as a chemical informatics rendering platform.

Note: if your're viewing this article in a feed aggregator, the SVG images may have been stripped out. If so, please see the original article.

Rendering Molecules with SVG on the Web

Rich Apodaca — Thu, 07 Sep 2006 13:56:00 +0000

Scalable Vector Graphics (SVG) is an XML-based language for encoding graphical content. Unlike raster image formats such as PNG, JPEG, and GIF, SVG images can be scaled to any resolution without pixelation. Given that 2-D structure diagrams are essentially line drawings, SVG seems like a natural fit for this type of representation. SVG also boasts several advanced features that make it an especially intriguing choice.

In this first article of a series on SVG and chemical informatics, I'll start by showing some embedded SVG images of molecules (also see this demo). Later articles will discuss technical details such as writing, reading, animating, scripting, editing, annotating, and distributing 2-D structures encoded as SVG.

Now, the Bad News

SVG is a work in progress. Browser support and performance can vary widely. If you are using Firefox version 1.5 or better, you should be able to see all of the images in this article without doing anything.

Unfortunately for Internet Explorer users, Microsoft's browser lacks built-in SVG support. Still worse, IE 7 appears ready to continue this perplexing tradition. Fortunately, Adobe offers an SVG plugin for IE.

Although this page was tested in both IE 6 (with Adobe's plugin) and Firefox 1.5 (both Windows and Linux), your particular configuration may vary. Please feel free to post your experiences.

Some Simple SVG Structures

The examples below illustrate how SVG images of molecules can be embedded in an HTML document. These images just scratch the surface of what is possible. If you don't see 2-D structures, your browser may lack SVG support.

Ascorbic Acid

Alprazolam

Furosemide

DDT

Note: if your're viewing this article in a feed aggregator, the SVG images may have been stripped out. If so, please see the original article.

Computational Perception and Recognition of Digitized Molecular Structures

Rich Apodaca — Fri, 25 Aug 2006 13:52:00 +0000

Summing up, the system described here, entirely developed in C (Vax C/Ultrix-32, version 1.0), can perceive and recognize complex type-printed molecular structures and allows one[sic] for the automatic input of this graphic information to a computer system. For hand-printed molecular structures however, there are some limitations for character recognition but not for graph (skeleton) recognition.

-M. Leonor Contreras et al. J. Chem. Inf. Comput. Sci. 1990, 30, 302-307

Raster images of 2-D molecular structures are everywhere - in books, in journal articles, on photocopies, in notebooks, and most importantly, on the internet (for example, on this page and this one). Although readily interpretable by humans, these renderings are useless to computer indexing systems - unless they can be translated into machine-readable representational schemes such as connection tables.

Ideally, content providers would encode their documents in such a way that chemical structure information is machine-indexable. Sadly, there are numerous options, no standard, and few tools specifically designed for doing so. Although the recent introduction of InChI may provide a solution going forward, raising awareness to the level needed to produce a significant change will take some time. Even if an encoding system can be standardized, it can't address the problem of the thousands, if not millions, of documents already in existence.

The work by Contreras and coworkers was apparently one of the earliest reported attempts at solving this problem. A more recent work proposes the interesting possibility of using a two step process in which a raster image is converted first to an SVG document. In a separate step, this SVG document is then converted into a 2-D structure representational scheme. Free software capable of performing raster->SVG conversions is available (for example, Autotrace and Potrace). Given the heterogeneous nature of images on the web, automated image prescreening would be essential. The use of Machine Vision techniques was proposed as one solution.

As more chemical content makes its way to the web, the problem only gets worse. Fortunately, most of the raster images being posted are machine-generated with regular features. Raster image conversion has never been one of the more active areas of chemical informatics. Has the time come to revisit this problem? Going forward, what kinds of tools could content providers be given help them make their documents more searchable?