Sign In/My Account | View Cart  
advertisement


Listen Print Discuss

ComicsML: A Simple Markup Language for Comics
by Jason McIntosh | Pages: 1, 2, 3

Reasons to use ComicsML

There are several reasons why comics with a standard markup language applied to them could be cool.

Syndication

When I first started thinking about ComicsML, I had in mind the very successful XML syndication application known as RSS, Netscape's Rich Site Summary format. Thousands of web sites, including news sites, weblogs, and other sites whose content changes rapidly, publish a special version of their latest material as an XML page in compliance with the RSS document definition, allowing web applications to swoop in and collect the site's latest headlines without knowing anything else about the site -- in other words, it doesn't have to know where the site keeps its normal, human-readable headlines, or how to parse the HTML once it gets there, since the RSS page uses the same standard elements as every other RSS page in the world.

RSS gives web publishers an easy way to invite automated entities to grab pointers to their latest information. This little bit of extra work can pay off immensely for the site, as now people visiting web sites that collect and display a user-configurable collection of content from these many RSS 'channels' -- like my.netscape.com or (my favorite) Meerkat -- can effectively surf several sites simultaneously, paying one an actual visit when an item of interest pops up on its channel.

This is the heart of web syndication: sites agreeing to share a little bit of their content with other sites, which are free to do with it what they will, but it's presented so that each clump of content ties back into its origin. RSS has changed my surfing habits so that nearly every site I regularly visit now I hit by way of Meerkat, where once I would randomly bop around my bookmarks every so often, seeing if anything new and interesting was immediately obvious on various sites, a far less efficient or fun method.

I think a similar model might be able to work with online comics.

The reader's perspective

I don't read a lot of online comics, and I can tell you at least part of the reason: I am far, far too lazy to hunt them down. One could argue that this isn't too hard to overcome with a standard browser: just bookmark all these sites and, once a day, visit them all in order.

But many fine online comics come out less often or (like mine) on an entirely irregular basis. Nothing's stopping me from still hitting them every day if I wanted to, but I probably won't, because I'll feel like I'm wasting time.

The creator's perspective

There are many more comics available online than there are in your favorite newspaper, more even than there are of all the different comic strips published in all newspapers by every print comics syndicate. Getting a syndicate's attention is hard. Being a talented artist with an intelligent and sustainable idea for a regular comic isn't enough; one also needs a great deal of timing and raw, dumb luck to make one's pitch exactly when the syndicate is looking for a particular niche to fill. The number of new comics accepted by an average syndicate in a given year can usually be counted on one hand.

It may be a little easier for a talented creator to get into comic books, since their editors -- at least with smaller, less superhero-centric publishers -- tend to look more for creativity than pure mass-market appeal. But there's a reason for that: the audience for comic books is much, much smaller, often dwindling down into single-digit thousands where newspapers have a potential for millions.

So the Web provides a great opportunity for the comics creator to reach millions of people.

The Web perspective

If there were enough online comics using a standard markup language, then aggregators could regularly snarf up information about them, just like RSS aggregators do, and web applications would summarize what's new in the world of (XML-clueful) comics without anyone anywhere doing (much) extra work. The contents wouldn't have to be the comics themselves, and many comics artists might prefer if people still had to visit their site in order to see the full thing. That's OK, and it's why I put the teaser element in place. In any case, though, users still get informed that this comic has been updated. Syndication is cool.

What if I wanted to use panel-describing elements so that I could add search engines to my comics website? What if I also wanted to syndicate my comics, but didn't want to let these syndication sites also grab all my content? I'd build two separate ComicsML documents. The first, without panel elements, would live at a URL I'd freely share with aggregators, while the other would reside in some private location, so that my own site-building tools could take advantage of them, without the whole Internet peeking in. This might be ideal if I relied on income from advertising, micropayments, or merchandise sales.

Some intermediate solutions already exist which partially address these same issues. Lots of people have written Perl programs that sneak off to their favorite comic web sites and download the most recent image from each, but this means playing the tired old game of accounting for every site's unique HTML style, which is a hassle to create and a burden to maintain. Other sites try to be something like web comic portals, but take extensive human input to maintain properly.

Searchable Archives

Just about every comic with a web presence has an archive collecting older strips. As these often stretch back to their first issue, archives of older strips can be massive. The normal way to read through them is to start at the beginning and step through the comics, one by one. Most comics archives have a ubiquitous suite of first, previous, next, last controls, and not much else. Let's say I wanted to find all Dilberts that mention downsizing. I'd be out of luck. Since all Dilberts are archived solely as images, no software can easily find what I want, and I'm not about to click through years of cartoons to find what I want.

Once again, some web-savvy comics have taken this matter into their own hands. User Friendly's site, for example, has its own search engine to match text queries with appropriate comic strips. This may work well for that one strip, but it sure doesn't scale across the Internet. If I wanted to grab a handful of geeky comics that dealt with some particular topic, perhaps in order to lighten the mood at some presentation, I could only easily find User Friendly comics. On the other hand, if all my favorite comics marked themselves up in a standard way through something like ComicsML, I could use an application to run my query across all their archives, returning with a result list likely comprising many different comics.

This would allow for searches with quite a bit of refinement, as the textual (and hence searchable) information about each strip would already exist in a hierarchy with implied levels of interest to a search engine. Strip titles and captions would probably have the most prominence, followed by dialogue, and then description.

One could also find more abstract information. Returning to the Dilbert example, were I particularly fond of Catbert, I might want to see all comics that have Catbert in them. That might be quite a few, so I could mix search styles to constrain the search, perhaps to all strips where Catbert says the word "outsourcing". Thanks to the descriptive elements that handle characters and dialogue, the software can return a list of relevant matches.

Accessibility

I am not blind and I don't know any blind people, so I don't know what resources may exist to help the visually impaired read comics (beyond what web searches tell me, which doesn't seem like a lot). I feel fairly certain, however, that a blind person can't pick up just any comic book or visit any web comic site they desire and give it a read. I think that sucks. Here is a part of your potential audience who might really enjoy your comics, but can never hope to do so unless they get friends to read and describe it aloud. OCR software might be able to read the text parts of the comic (if they're typed or written very neatly by the cartoonist) but can't describe the visuals that accompany them.

Proper markup could do a lot to help the blind enjoy comics. The W3C, the organization principally responsible for XML's creation and continuing development, has always held web accessibility for all as one of its primary goals. XML is already being used in several accessibility projects. Since the most obvious way to make comics readable to blind computer users involves keeping a text version of the comic as accessible as the comic itself, so that software can locate it and pipe it through a text-to-speech device, it follows that keeping this text in a predictably structured format would let this software quickly pull out the comics' content without any extra parsing.

Additionally, while it's an entirely different sort of accessibility, I'll note that descriptive markup would also let people with any level of sightedness read comics in a text browser like lynx. Perhaps the only Web browser I have to hand at a certain moment is the LCD screen on my cell phone, for example, but I'm stuck in a traffic-bound taxi, and I really want to see what's new with my favorite comics.

Conclusion

In the short time since I first shared a draft of this document with friends and coworkers, I've seen glimmers of wonderful ideas for directions to extend ComicsML that I doubt I would have ever conceived myself, covering everything from cross-referencing to story line management, and lots of folks seem game to try and catch the elusive problem of sanely describing layout. What's more, each of these people seemed to name a different reason why they liked the idea of a comics markup language. Given enough time and testing, I think ComicsML can live up to its name, becoming a method to let digital comics, no matter who produces them, hook into the vast information potential their presence on the Internet offers, while remaining simple enough for any aspiring comics creator to use.

Please contact me if you have feedback or leave comments in the forums at the bottom of this page.

References

  • I've made a separate ComicsML resource page, an index to more information and support for this idea, as I develop or collect it.
  • A draft of the ComicsML DTD available as well as a very chatty example document.
  • The coworker who made the comment about Tupperware has written a very nice book called Learning XML, which I highly recommend. (Look for me in the Acknowledgments section, right above his list of favorite mustards.)
  • Scott McCloud's website has all kinds of good stuff about digital comics (including many excellent examples from his own hand, one hilarious Web-collaborative effort, and lots of links to other groundbreaking work), but his big treatise on the issue is Reinventing Comics.

Comment on this articleInterested in finding out more about ComicsML? Got any suggestions for improvements, or software? Share your thoughts with the author and other readers.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only Titles Only Newest First
  • Meaning of the "url" element
    2001-04-25 03:54:40 Damian Cugley [Reply]

    Is the "url" element intended to be a web page displaying the comic -- with banner ads and suchlike -- or just the image of the comic strip itself? Obviously the former will be preferred by commerical comic-strips web sites, the latter by amateurs who value being able to knit together their own comics page.


    You could replace the use of the "url" element with an XHTML "object" element. This would allow the use of arbitrary multimedia formats in the rendering of the comic strip. Nested "object" tags allow for the author to offer the content in a variety of formats, and for the consumer to choose the one that is best for them.


    Your example uses a single GIF document to represent all four panels. An alternative approach is to use one GIF or PNG per panel (example: http://www.alleged.demon.co.uk/pdc/fabulous.html) or to have the story represented as several pages, each containing several panels (example: http://www.alleged.demon.co.uk/jrd/r12-1.html). My suggestion for handling this is as follows.


    First add an optional element "page" which goes within a "strip" element and encloses some of the "panel" elements Newspaper stips will generally not need to be subdivided in to pages; comic books will.


    Second to allow the "object" (or "url") element to appear as a child of "strip", "page" or "panel"; the "object" in the smallest enclosing scope is the one containing the current panel.


    Third, "panel" elements can be decorated with the "shape" and "coords" attributes used to describe areas in client-side immage maps ("area" elements in XHTML). The idea is that the panel says which part of the image represented by the "object" tag represents this panel.

  • Effort to define an Infinite Canvas for comics
    2001-04-21 15:02:22 John Scott [Reply]

    A group of us are working on another project that is headed in almost the same direction as the ComicsML. At this point, we're trying to define the requirements for the kind of Infinite Canvas for comics that McCloud proposes in 'Reinventing Comics.' Eventually, our effort will probably blossom into a DTD that might end up being built on this ComicsML.


    That discussion is ongoing at the forum for a webcomic called Zwol (www.zwol.org). The current draft of the requirements for an Infinite Canvas is at http://cmug.com/~john_scott/ic/ICrequirements.html


    Everybody who is interested in 'net delivery of comics is invited to join in.


    John

  • finessing the hard part - comics = sequence = layout
    2001-04-20 09:27:20 David vun Kannon [Reply]

    OK, Jason beat me to it! I've been thinking about a "DTD for comics" for a long time.
    My attempts have been similar to ComicsML as described here. I think the ingredients of a successful comics markup are:
    text markup - leverage XTHML modules
    visual markup - leverage SVG
    layout markup - leverage SMIL or XSL-FO


    What's left to innovate? Putting it all together and sprinkling it with some metadata.


    As my subject line shows, I do think the deep issue for comics qua comics is sequence and panel layout. So as important as intra-panel markup is, the real meat of capturing the "meaning" of comics in XML relates to sequence of panels, aka layout.

    • finessing the hard part - comics = sequence = layout
      2001-04-23 19:10:48 Jason McIntosh [Reply]

      ComicsML as it stands does sequence, with panels appearing in the sequence the creator intends the reader to read them, but it doesn't handle any sort of layout beyond this implied linearity yet. Determining how and how much ComicsML will handle layout will be an interesting puzzle.


      Personally, I predict it will end up working hand-in-hand with other grammars (you already mentioned SVG) if someone actually wants to use a ComicsML to render a comic from scratch. We'll see what happens!

  • responding to demand
    2001-04-19 11:55:24 pat donovan [Reply]

    xml as the latest in open stalker-ware?


    neat, but you need a web-wide index to even GET to the product first.


    I (had) an netscape.net xml channel whicj died after they changed my URL on me.


    the code etc is there, the channel isn't.


    yes, I comix. no, I do not index.
    pat


  • another vocal-effects element
    2001-04-19 11:44:30 Susanna King [Reply]

    I think adding a "curse" element to the vocal-effects palette would be useful. For example, when a character says "@!!#*!" that would be represented by <curse/>.

    • another vocal-effects element
      2005-04-12 16:59:56 The_Rumour [Reply]

      I think what you're looking for is not an element but more of a entity, like '&curse;', that would make a bit more sense.

    • another vocal-effects element
      2001-04-23 19:05:19 Jason McIntosh [Reply]

      That's a brilliant suggestion, actually. I guess I'm used to reading "mature" comics where the characters usually just come right out with it, but even then you sometimes see those naughty squiggles.


      Thanks!

  • collections / series
    2001-04-19 02:00:03 Damien Dewitte [Reply]

    Wouldn't it be a good idea to hold some metadata somewhere that can categorize comics belonging to a particular collection/series.

    • collections / series
      2001-04-23 19:03:55 Jason McIntosh [Reply]

      Yep. Categorizing "story arcs", or maybe just "chapters", is an oft-requested feature that's squarely on the TODO.


      I discuss a lot of possible future directions on the formal documentation available from the main resource page (at <http://www.jmac.org/projects/comics_ml/>).

  • interactivity
    2001-04-19 00:18:23 tony a [Reply]

    If the markup also describes the structure of the
    comic, then a less artistic user could take
    their favourite characters, arrange then on the
    panel and add dialogue to suit... a new comic!


    You could also personalise a comic. In a Dilbert
    comic, you could specify a url that contains a
    picture of your boss, and other characters, and
    then forward a reference to this new comic to
    your co-workers...


    Using techniques similiar to SMIL, you could
    create animated comics...


    The possibilities are endless!




  • Authoring it !!
    2001-04-18 22:24:40 jaison joseph [Reply]


    I wonder if some authoring tools can be devised for the artist to generate the ComicsML !

    • Authoring it !!
      2003-03-31 20:57:01 Dave Horlick [Reply]

      Yes.


      http://mywebpages.comcast.net/dhorlick/renoberator/index.html