WYSIWYG Editor for DocBook DTD Content?

Saqib Ali asks: "This week I saw a demo of the Tagless Editor by i4i. The editor is a plugin to Microsoft Word, which can be used to create XML based content. The plugin can handle various custom DTDs. However it can not properly handle the DocBook DTD. I was wondering if there is any WYSIWYG XML editor that can be used to edit DocBook DTD based content? Any ideas?"

Comments

Conglomerate, maybe?

[DeadMoose]

I was looking for the same thing not too long ago, and came across Conglomerate, which despite its web page, is no longer dead, and back under development.

I've had a few problems getting it compiled/running well, but from what I've seen, it looks like it's a fairly decent bit of code, so once it gets some polish, it could be pretty handy.

Re:Conglomerate, maybe?

[Anonymous Coward]

Where's some info to show that it's active again? I might like to get involved.

Re:Conglomerate, maybe?

[DeadMoose]

Where's some info to show that it's active again? I might like to get involved.

Well first off, the page has finally been updated since I last looked at it (looks like just today actually), but even with that, it's out-of-date & misleading.

There's been a decent amount of activity on the developers' mailing list however, so you should check out the archives/subscribe to that.

Re:Conglomerate, maybe?

[Anonymous Coward]

Thanks!

not necessary

[Anonymous Coward]

One of the great things about XML is that it's human-readable and -writeable. You don't need a WYSYWIG editor, because you can just edit it directly. Once again, we find that open standards are superior to the proprietary alternatives pushed by the likes of Microsoft and Sun.

Re:not necessary

[DeadMoose]

One of the great things about XML is that it's human-readable and -writeable. You don't need a WYSYWIG editor, because you can just edit it directly. Once again, we find that open standards are superior to the proprietary alternatives pushed by the likes of Microsoft and Sun.

Except for the fact that it's really convenient to not have to edit the raw XML. Yes I can, but I really don't want to; I'd much rather save myself that agrivation and just write what I'm trying to write.

It's just like a lot of other things that people go "well, you can do it manually, so why do you need a fancy tool?" about. Yes, I can manually patch/build/blahblah my own kernel. Do I want to? No, I want to just have things work. Same story here: do I want to sit here remembering what all the docbook tags are? No. Did I want to learn them in the first place? No. There's a time and a place for good tools to make tedious tasks easier.

Just because I could edit a file and manually set all the colors for all the pixels, doesn't mean there's no need for Photoshop/The Gimp.

Re:not necessary

[Anonymous Coward]

Same story here: do I want to sit here remembering what all the docbook tags are? No.

That's what Emacs and the XML sensitive macros are for.

Re:not necessary

[GigsVT]

You are missing the point, the whole point is to seperate the content from presentation. WYSIWYG is totally contrary to that. I'd go as far as to say that it's entirely impossible to have such a Docbook editor, since you have pretty much no say in the presentation when you write it. It's the same with any good implementation of XML.

Re:not necessary

[Twirlip of the Mists]

You are missing the point, the whole point is to seperate the content from presentation.

No offense intended, but I think it is you who is missing the point. The average person doesn't think in XML. The average person thinks in formatted text. When I'm writing, I don't think "<ital>foo</ital>," I think "foo." Being able to see foo on the screen, but get "<ital>foo</ital>" in the output is a big win.

I'd go as far as to say that it's entirely impossible to have such a Docbook editor, since you have pretty much no say in the presentation when you write it.

Oh, sure you can. The editor doesn't need to display it the exact same way the end-user will display it; it just needs to display it in a way that makes the user feel comfortable. On your machine, chapter titles are 24 point serif type; on mine, they're 18 point italic sans-serif type. I don't care that yours are different from mine; I only care that mine look the way I expect them to.

Re:not necessary

[GigsVT]

The presentation is more than just typefaces and formatting, in docbook it goes as far as what gets put on what HTML page, and how they are linked together, or even if some structures are omitted from the presentation.

You have one docbook file that get broken up into make multiple HTML files, or a single TXT file, or whatever.

You designate sections/chapters/whatever, and the presentation decides how to parse those. The point is that only the structure of the document is defined, nothing is assumed about presentation. Nothing at all!

A tool could be developed to assist this, by basically making sure you don't nest improperly, or use tags in an invalid context, or even give you a hint about what some things will look like on the final output using a common style sheet, but ultimately there is no way to approach even close to WYSIWYG.

And no offense intended likewise, but the "average person" shouldn't be trying to write XML documents if they can't understand the concept of seperating content from presentation.

Re:not necessary

[JohnFluxx]

It isn't a WYSIWYG editor if it isn't displayed the same way the end user will display it. And so you can't have a WYSIWYG editor for DocBook.

Re:not necessary

[DeadMoose]

It isn't a WYSIWYG editor if it isn't displayed the same way the end user will display it. And so you can't have a WYSIWYG editor for DocBook.

In general, you can never have a WYSIWYG editor for most things on a computer. That doesn't stop people from using the term as long as it's fairly accurate.

If you check out the help for the Mozilla's HTML editor, "Composer is a WYSIWYG (What You See Is What You Get) editor, so you can display how your page will look to the reader as you're creating it."

We all know this is a blatent lie, though, since HTML's actual rendering on my machine will differ from yours, since I might have different fonts, I might have overridden colors, I might refuse to load images, or maybe I just have my web browser window a different size than yours. All those things alter it, so you don't actually know how it will be displayed when the end user sees it. I don't see people scampering to alter the documentation to change it to WYSIWYWYWGBTNWTGI (What You See Is What You Wish You Would Get But There's No Way To Guarantee It).

Even going further out on a limb; depending on how someone's monitor is color calibrated, something may look enough different for it to have an impact on a document's content. What if it's something to be printed? What if their printer isn't color calibrated? What if it feeds paper badly & skews printing?

People need to accept the fact that sometimes a working attempt at a solution to a problem is far better than going "You can't have a WYSIWYG editor for DocBook, so go edit the raw XML instead." Something that intelligently gives access to the DocBOok elements so that someone can do correct layout, but shields them from having to deal with rawl XML is a Good Thing[tm].

Re:not necessary

[JohnFluxx]

But docbook has no display info at all! At least with HTML it is fairly close. With docbook you don't even know if it will have a contents page, etc.

And who said anything about editing the raw xml? I'm just saying what he is asking for is just a GUI editor of some kind - not a WYSIWYG. - See lyx for example.

Re:not necessary

[Twirlip of the Mists]

ultimately there is no way to approach even close to WYSIWYG

I think you need to go take a look at FrameMaker. It predates all this new-fangled XML hoo-hah; its native format is SGML. It is entirely WYSIWYG. Your point is thus demonstrably false.

And no offense intended likewise, but the "average person" shouldn't be trying to write XML documents if they can't understand the concept of seperating content from presentation.

Ah, the ugly face of snobbery and elitism raises its ugly head once again. Thanks for the input, GigsVT; since I'm obviously not wanted here, I'll just go back to using Microsoft Word for my documentation. You XML folks have fun playing in your little sandbox all by yourselves.

Re:not necessary

[King of the World]

I think you need to go take a look at FrameMaker. It predates all this new-fangled XML hoo-hah; its native format is SGML. It is entirely WYSIWYG. Your point is thus demonstrably false.

When displaying a docbook file tell me what font I should use, or where I should get this font information from?

Then how can what I see be what's actually encoded in the file?

Re:not necessary

[Twirlip of the Mists]

When displaying a docbook file tell me what font I should use, or where I should get this font information from?

Sensible default, with user-configurable options.

Then how can what I see be what's actually encoded in the file?

Magic.

Sometimes I think people just don't get it. It saddens me... but only a little, because I soon get pulled back into my real life where this "docbook" thing pales in comparison to whether table 11 got their watercress soup or not.

Re:not necessary

[King of the World]

Sensible default, with user-configurable options.

Would that be a serif or sans-serif font when I print it?

Magic

Oh, so you've conceded that as Docbook doesn't contain style information you can't do wysiwyg. Good good.

If you included XSL-FO, DSSSL, or CSS then I might have agreed with you.

Re:not necessary

[Twirlip of the Mists]

Would that be a serif or sans-serif font when I print it?

By default, serif. Serif always for body text. You're free to set the option to 666-point Zapf Dingbats if you like.

Oh, so you've conceded that as Docbook doesn't contain style information you can't do wysiwyg. Good good.

Neither does HTML, you hard-headed nitwit, yet WYSIWYG HTML editors have been around for nearly a decade now. In HTML one encloses a paragraph in "P" tags, and the browser handles the rest. WYSIWYG HTML editors pick a sensible default (this sounds familiar) and let the user change things around in the preferences (where have I heard this before?).

Re:not necessary

[sporktoast]

When I'm writing, I don't think "<ital>foo</ital>," I think " foo."

Ok then. Why should foo be italicized? Is it important? Is it an example some something? A variable? A citation? A proper name? A bit of sarcasm? Maybe you just *like* the way italics look and don't really mean anything more by it. Then, perhaps "<ital>foo</ital>," is something of a win. But if "foo" means more than that, then "<ital>foo</ital>," actually loses that meaning.

Oh, sure you can. The editor doesn't need to display it the exact same way the end-user will display it; it just needs to display it in a way that makes the user feel comfortable. On your machine, chapter titles are 24 point serif type; on mine, they're 18 point italic sans-serif type. I don't care that yours are different from mine; I only care that mine look the way I expect them to.

But that's not really WYSIWYG then, is it? (Unless you want to get all semantic about the Ys in the acronym.) The thing is, if you lobotomize the meta-data so that what you create as a <chapter title> is encoded as <ital>, then you are pretty much forcing the hand of my machine. Your "big win" becomes my loss. Sure, I can remap <ital> so that it renders as 24 point serif, but then everything else that you've flattened down to <ital> for the sake of how it looks (footnotes, dates, marginal commentary, etc.) gets the 24 point serif treatment, too.

WYSIWYG for DocBook? You're gonna need a bigger wrench if you want to pound in that screw.

Re:not necessary

[King of the World]

you hard-headed nitwit,

Oh grow up you brat.

Yet WYSIWYG HTML editors have been around for nearly a decade now. In HTML one encloses a paragraph in "P" tags, and the browser handles the rest. WYSIWYG HTML editors pick a sensible default (this sounds familiar) and let the user change things around in the preferences (where have I heard this before?).

1. HTML "wysiwyg" editors were lying. Everyone knows this. If I call a horse an HTML WYSIWYG editor it doesn't mean that there's ever been one.

2. HTML with CSS has some style information, and anyone can define entirely physical real-world measurements. With newer editors such as VS.NET and Dreamweaver MX it's possible (although usually not desirable) to produce onscreen WYSIWYG content that prints the same.

Docbook however can never be WYSIWYG without additional style information.

Re:not necessary

[Twirlip of the Mists]

Why should foo be italicized?

That was just an example, and maybe, in retrospect, not the best one. Yes, in a real case the tag wouldn't be <ital> but rather <cite> or <xref> or some such. Same idea applies. I would want an editor to show me foo instead of <cite>foo</cite>, using whatever the appropriate default rendering style is for <cite>.

Re:not necessary

[Twirlip of the Mists]

Oh grow up you brat.

Takes one to know one. ;-)

Okay, are we done reliving our playground years, here? I'll kiss and make up if you will.

1. HTML "wysiwyg" editors were lying.

Well, I certainly don't have the energy to get into a fight over what WYSIWYG means. Let's just agree that we're talking about a program that shows formatted text instead of XML tags, and that allows the user to apply XML tags using buttons or mouse gestures or speech recognition or synchronized farts or some other method that doesn't involve typing the fucking things out.

Re:not necessary

[King of the World]

Let's just agree that we're talking about a program that shows formatted text instead of XML tags, and that allows the user to apply XML tags using buttons or mouse gestures or speech recognition or synchronized farts or some other method that doesn't involve typing the fucking things out.

Now that's comedy.

Re:not necessary

[Twylite]

But if "foo" means more than that, then "<ital>foo</ital>," actually loses that meaning.

No, it only "loses" that meaning if you want to parse it. While that may be useful for certain computer applications, or if you need to reformat the text into another style, ultimately the message conveyed (visually) to the reader is the same.

Re:not necessary

[GigsVT]

Neither does HTML, you hard-headed nitwit, yet WYSIWYG HTML editors have been around for nearly a decade now.

HTML is nothing like Docbook or any other pure XML/SGML implementation that enforces a good seperation of presentation and content. HTML is tainted with tons of presentation information.

You strike me as someone who has never even written a docbook.

Re:not necessary

[vbweenie]

I would consider that it is not beyond the wit of even "the 'average person'" to understand the concept of separating content from presentation, and that understanding this is a reasonable prerequisite for using a format like DocBook - otherwise what exactly do you think you're using it for? I can't see how recognising this prerequisite is "elitist". There are some very non-l33t people out there who have proved quite capable of getting their heads round it, after all.

Using MS Word has its prerequisites, too; certainly using it effectively does. I once spent a couple of fairly tedious evenings tidying up a friend's Word document - an MA dissertation - where she had used spaces for indentation throughout. Understanding how to define and use custom styles for consistent presentation, or even how to place tabstops to line things up with each other, is not something that everyone in end-user land is born with.

Re:not necessary

[Twirlip of the Mists]

I would consider that it is not beyond the wit of even "the 'average person'" to understand the concept of separating content from presentation

The concept? No. But expecting a technical writer to wade through a sea of angle-brackets to produce his documentation is laughable at best.

The vast majority of technical documentation in the world is written by technical writers, not programmers. (I played around as one myself for a while.) That's why the majority of documentation is written with user-friendly tools like Word and FrameMaker. Programmers, of course, will choose things like XML because... I don't know, maybe it makes them feel superior or something. Couldn't say why. It certainly doesn't offer any useful benefits over Frame.

Like so many other "open source" technologies, "Docbook" is irrelevant to most of the world because it's more trouble to use than its worth. Why do you think the submitter is looking for a WYSIWYG tool?

Oh, and elitism is telling someone, "the "average person" shouldn't be trying to write XML documents if they can't understand the concept."

Re:not necessary

[Twirlip of the Mists]

You strike me as someone who has never even written a docbook.

Once. Well, half of once. One day in a fit of blinding rage, I called up Adobe and moved the whole damn thing over to FrameMaker and SGML the next morning.

Re:not necessary

[King of the World]

WYSWIYG doesn't just mean any graphic editor where when you make a table you see a table. If you throw the term around like that then it loses all meaning. There are other, better, names such as the WYSIWYM mode of Lyx and Conglomerate. But to call it wysiwyg you've got to at least have a canvas!

I think we're in agreement that you shouldn't expect people to bother with XML tags themselves.

All authors I have found have loved to express structure through their editor (be in styles and headings in MSWord, or their software of choice) that we can then later map to Docbook or TEI elements. Structure helps them edit as they can see how many chapters at a glance, and drag around branches of the document tree easier than cutting and pasting. They can know that 'MSWord styles' will be converted to a certain visual output and that unlike the past they won't have to trust the editor - who often doesn't understand the content - to style it correctly.

Re:not necessary

[vbweenie]

Nobody should be trying to write XML documents if they don't know why they're doing it. As you seem to be suggesting, for many purposes it's a lot more trouble than it's worth. I would suggest that if you think you want a WYSIWYG tool, then you probably don't really know why you want to use an XML format explicitly designed to separate content from presentation.

Having said that, I can't see any harm in automating conversion from Word to DocBook; one could fairly easily write VBA code to do it. The original author would probably have to adhere to some conventions, effectively mapping presentation styles to structure, in order for it to work at all well. I don't have any insight into the kind of mind that would automatically prefer that kind of arrangement to using angle-brackets and explicit structural mark-up, but I suppose I have to acknowledge that some people's minds do work that way.

"Elitism" is a cant word used by chippy so-and-sos to belittle those of us who've put the hours in trying to learn something they never attached any real value to in the first place, that they now find gives us some material advantage they don't like us having. Stuff 'em. All it takes is a little effort, and a little humility (I mean the kind needed to say to oneself, "the fact that I don't understand this indicates that I myself have something to learn"; after that, of course, it's hubris all the way). To my mind, it's the people who chunter on about the supreme importance of the "real world" - meaning that tiny subset of the real world that they themselves inhabit - that are the real self-deluding snobs.

have you tried

[Hubert_Shrump]

LyX? I know it's not a true WYSIWYG, but it does have a DocBook mode. I haven't tried it in awhile (went back to xemacs), but it might have all sorts of new goodies.

Docbook and WYSIWYG...

[Papineau]

The only problem I see is that Docbook doesn't have a visual representation, it has many, depending on the backend you want (HTML, PDF, PS, TXT, etc.). So a WYSIWYG editor would only show one type of representation.

Besides, Docbook (as many other document formats) is meant to separate the visual from the info. Linking the visual to the edition would only make people try to make it present the info in (what they beleive to be) pretty layout, when Docbook's goal is to concentrate on the structure of the document, which the backend then translates to HTML tags, or PDF fonts and layout, etc.

Re:Docbook and WYSIWYG...

[stonebeat.org]

Take a look at http://www.i4i.com 's Tagless Editor

Re:Docbook and WYSIWYG...

[booch]

When talking about semantic structured documents (like DocBook) it's true that WYSIWYG really doesn't have any meaning. But when someone asks for a WYSIWYG editor for such a document type, they really want something that shows a representation of the semantics. In other words, the tags themselves don't appear. Instead, the tags are used to apply (user-definable) stylesheets (usually CSS) to the document as you type. So you still have to deal with the underlying XML structure and tags, explicitly putting the tags where you want them. It's just that you get to deal with the tags as if they were styles in a word processor. So I wouldn't ever make something bold. Instead, I'd tag it as a new term, or emphasis, or a command, or whatever, and let the stylesheets make it bold, or bold and green, or a different font or background -- whatever helps me make the distinction in my head without having to specifically think about the tags.

Believe me, it's much easier to edit large amounts of DocBook without having all the tags mixed in. To me, it actually keeps the content separate from the presentation -- the tags are really just explaining how to format things, by giving things semantic meanings. Removing the tags from view lets me concentrate on the content. But the tags are still visible enough that I can add them when I change semantic contexts. (Typing in all the content and adding tags later tends to take almost twice as long.)

See my post on Morphon for a list of programs that support this way of editing XML.

Structured Editor

[Crutcher]

I agree, you don't really want a WYSIWYG editor for docbook, as that violates the Information/Representation sepperation.

But what would be _really_ useful would be a structured editor, which provided a good mapping at several levels (ala Mozilla's composer, where I can turn on and off tabs). The point of such an editor's representation would not be for final production, but to unambigously display the information's _structure_ to the user, and to facilitate manipulating that structure.

It would be like a very ugly word processor, where the tables would always have borders, etc.

If that editor was then linked with a set of generation tools, to make it EASY to genearte and view PostScript, HTML, XHTML, etc. productions, then you'd really have something. I'd use it, for sure, and I don't mind using docbook tags now.

In fact, would mozilla's composer be a good place to start with a docbook editor? Mozilla has good DOM tools, like the inspector, which loads XML DocBook files just fine.

Re:Structured Editor

[Anonymous Coward]

It would be like a very ugly word processor, where the tables would always have borders, etc.

Can OfficeXP do XML now?

Trollin' Rollin' Trollin'

[Anonymous Coward]

growl

XMLMind

[jdurham]

http://www.xmlmind.com/xmleditor/ Not sure what the license is.

Buzzword Stew makes me sick

[BlackTriangle]

English, please.

Re:Buzzword Stew makes me sick

[SwellJoe]

English is for secret agents and English teachers.

Nerds on the other hand know what a DTD is. Nerds that don't know, know what Google does. "DTD" aint a buzzword, it's a technical abbreviation in common use among nerds.

XMetal

[Ovidius]

If buying it isn't a problem, XMetal works pretty well for DocBook. You can view your document as a tree (i.e., structured); with minimal block formatting and visible tags; as something like WYSIWYG, formatted with a CSS stylesheet; and, preview it as HTML in browser (IE for sure -- I don't know if you could get it to use Mozilla) formatted with an XSL stylesheet. The new version adds PDF preview which I assume is done through XSL-FO, but I haven't used it.

It's not the fastest or smoothest editor to use, but it does a good job of balancing the spirit of XML with the niceness of seeing formatted text as you work.

Re: WYSIWYG Editor for DocBook DTD Content?

[Bob Bitchen]

Right from the i4i website:

Quote-
No proprietary word processing interface; it's Microsoft Word

* Your end-users can continue to generate content in the same environment they always
-end quote

But this is complete BS. MS word is not proprietary? Yes all end-users are using word.

Most of the tech writers I know abhor MS Word. I really don't like MS word either. It's annoying in that it attempts to be "smart".

Not to bag too hard on i4i, but making preposterous claims doesn't help the product IMO.

There is a commercial product to avoid..

[molo]

We use a commercial product to do this at work. It is called Epic, and is available from Arbortext. We've had some real problems with it though, so I think our tech writers are moving to a plain ascii editor. I can't recommend it, but I thought I would provide a data point.

Good luck.

-molo

LyX

[Anonymous Coward]

try LyX - http://www.lyx.org/ . Best pocument processor ever, straight to the point. Enables you to write good looking dokuments in no time. Word - eat my dust.

jEdit support DocBook

[Anonymous Coward]

jEdit is an open-source Java text editor that supports XML tag completion and DTD validation, ensuring that you can enter DocBook XML without having to continually refer to the documentation. I use it a lot on Mac OS X, IRIX and Linux. It's not the fastest (being Java) but it works well and ensures that I spend more time writing documentation than reading other documentation.

Re:jEdit support DocBook

[Big Sean O]

Yep, jEdit is a total pig. It's slow, takes forever to load, and is quite simply the best free XML editor I've ever used. I know it's not magic, but it does the following really well:

• When I start a tag, it opens a contextural menu that displays all the valid tags.
  
• As I type the name of the tag, the list changes until I get the unique tag I want.
  
• When I type a close-tag, it fills in the close-tag information.
  
• It's XML validator does a pretty good job and has the sensible trait of stopping after listing 100 errors.
  
• Poorly-formed and invalid XML is redlined, like a spelling mistake.
  

I don't think it's productive to get into a match about XML/WYSIWIG. I like structured XML editors (like XML Spy). They definitely have their place, I especially like the table format. But for 60% of my XML-editing needs I'll be quite happy with a text editor with syntax coloring (ahh, BBEdit).

I guess it's all about the tools. The right tool in the right place. And for me, when I'm writing a DocBook, it's jEdit. It's not perfect, but it's the best tool I got.

OpenOffice

[Matts]

Try OpenOffice. My company sells an XSLT based filter that will turn OpenOffice documents (if using sensible styles) into DocBook XML. You may have to tweak it a bit to get exactly what you desire, but that's going to be the case with any tool.

re:WYSIWYG Editor for DocBook DTD Content?

[Anonymous Coward]

Try XmlMind XML Editor (XXE for short) from http://www.xmlmind.com. It's not open source, but it is completely free if all you want to do is edit docbook documents.

Morphon

[booch]

The canonical list of DocBook editors is here. The best program I've seen for editing DocBook is Morphon. It does a really good job of styling tags with CSS in real-time so that you can edit the document with various tags, but see the output in a WYSIWYG-like way. There's also a tree view. Another good program is XMLmind's XXE XML Editor. Both are Java apps, so will work cross-platform. They both come with good DocBook configurations, and are primarily used for DocBook. They've got free evaluation copies, and are reasonably priced at $100-$200.

I also looked at ArborText and FrameMaker. They claimed to support DocBook, but they supply config files only for (much) older DocBook versions. I found the out-of-the-box support for docBook to be sorely lacking. It looked like it was possible to configure them for better support, but it would have taken many hours to do so.

XML Spy and XMetaL looked pretty good. I don't remember how well they did with DocBook, but they are geared more for data-oriented XML, whereas Morphon and XXE are more suited for document-oriented XML, such as DocBook.

a list

[polaar]

As it happens, I was doing some surfing for document-oriented WYSYWYG/WYSYWIM XML editors myself. I'm a little late in the discussion, so a couple of these have already been mentioned, but here's the list I've got so far (I've not tried them all):

• Arbortext Epic Editor
• SoftQuad XMetal or Corel XMetal
• EpcEdit XML/SGML Editor
• Altova Authentic
• XmlMind XML Editor (Standard version is free)
• Morphon XML Editor
• TimeLux XPress
• GenDoc (open source, could be nice if someone wrote a docbook plugin)
• Conglomerate (open source project which seems to be resurrected, nothing available now though)
• ExcoSoft XML Client (as far as I can tell from the website...)
• SoftMagic SendStory
• 
  Anyone has experience with these? (or others that are missing from the list).

FrameMaker?

[Anonymous Coward]

I haven't used it much, but FrameMaker does just that. It does XML or SGML, and, as I understand it, you just have to give it the DocBook DTD to do DocBook -- and then you can save as HTML, RTF, etc.

I've heard it called "A document formating program masquerading as a desktop publishing program".

Of course, that said, I don't actually use it myself, mostly because there's no Mac OS X version, and it's pretty darned expensive for personal use. Such a shame.