Python is showing up everywhere. We're thinking about making it show up in the author tools as well. Members of our developerWorks team lovingly use Python for text processing, XML parsing and transformation, all kinds of system tasks. It's all over the place inside many distributions of Linux, which is the OS we favor here at developerWorks. We're finding more and more ways to use the programming language, and more and more adherents here at developerWorks.

So Python seems like a logical choice to put inside the authoring tools, especially given its robust cross-platform support, its legibility and ease-of-use. What do you think? We need some glue language in there--some scripts and programs that provide author aid in the creation of the XML content we publish on developerWorks. Python seems like a great candidate for this community of authors, developers, and readers.

Currently, we want some way to automate the creation of a new article or tutorial, a process that uses templates also stored in the author tools package, checks various things about the path and environment itself, provides a graphical wizard-like interface in some cases. Currently, we're using a mix of shell scripts and visual basic files to support the different platforms our authors use (OSX, Linux, and varieties of Windows), but maintaining the mix of environments is difficult and brittle. In fact, we don't really have a good OSX story for the author tools. Moreover, we have Big Plans for expanding the guidance and aids we provide to authors, and Python looks like something we all could grow into here.

We'd love to hear from you:

Would moving toward a single scripting environment inside the authoring tools such as Python be good for you as an author?

We can ship compiled versions of Python scripts as EXEs and other binaries. Would that be useful? Do you prefer binary executables to installing new scripting and programming environments?

Do you use Python? What other opportunities for scripting the authoring tools do you see?

Are there other cross-platform glue languages or environments you think would serve us better as we build and maintain tools for helping authors create and publish content on developerWorks?

Several of us on the developerWorks development teams have been refreshing our systems, using Linux a lot more, having to go through our backups and application lists to get new systems set up and running.

I have been a CorelDRAW user for some time. Was never very good at it--designers really dig deep and master this vector drawing product--but I was competent enough to appreciate its power and, frankly, the reason for its expensive price tag. Since I'm not doing much authoring these days I'm not licensed to use Corel any more at IBM, which is a bummer, and so I went looking around for drawing tool substitutes, wondering especially if I could press the open source GIMP paint tool, which is perhaps best supported on Linux, into service as a draw tool and not just a photo and paint tool. People do it. But that wasn't feeling right and in the same places where I was seeing discussion of drawing beziers &c with GIMP, I saw references to Inkscape, which like GIMP is an open source product ("Inkscape: Draw freely.").

I downloaded and spent a bit of time with it and man! It's pretty nice. As with many free and publicly available software products, there are a couple of areas where you might wish for some additional polish or specialized support. But the quality of the editing and the basic toolset, not to say the drawing features that put it way above very basic drawing tools like OpenOffice, such as filters, extensions, paths, and layers, make it a fantastic drawing tool, and one I'd recommend heartily to authors.

Even if you're doing diagrams, simple boxes and arrows, the editing flow can be quick and nice, and it supports a bunch of output formats from its native SVG editing, such as PDFs, ZIPs, PNGs (though some version of the PNG output lose transparencies and some layer details).

Image below, lame but the work of just a couple of minutes, shows an Inkscape drawing with some shapes, gradiants, connectors, and transparencies.

Custom sidebars not styled properly in CSSWe've updated the CSS that comes with the template so that element sidebar-custom is styled appropriately.

Author package transform scripts do not support spaces in paths

Remove techbriefings resource from article templateAmong the list of resources in the authoring template was a link to "tech briefings", which is a type of event we no longer manage separately on developerWorks. We've removed this from the template.

This blog is about authoring tools. Mainly about the set of XMLauthoring, editing, and validation tools we use at developerWorks, and addressed mainly to our authors, but not just. We're interested in authoring technologies in different contexts, for different purposes. We'd like to create content here that responds to the needs of our authoring community, sometimes in quite specific, nerdy, tools-patch ways, but that also treats more general authoring topics, such as OpenDocument and XML, XSL, text processing, natural language processing, information development.

As you will know if you're a part of the developerWorks community, our processes, technologies and direction change continually (not to say abruptly!). The merely general and interesting may at any time become the practical. For example, developerWorks is experimenting with ebooks; this is a hobbyish technological interest of mine, also an authoring technology of sorts. It may well be that we'll find some good way to produce ebook versions of our content, and perhaps update our authoring tools to better support this new set of formats. We'll see. Just as an example.

Please feel absolutely free to comment here (for instance, by commenting on this first, introductory post), to share this content in your networks -- or even to be a co-author of this blog! (which is how I've set things up in anticipation). We will use this as the forum where we post specific information about the authoring tools we maintain (this thing's broken, here's a workaround, don't do this, &c), also where we'll solicit your input on those and other requests, questions, and so forth (new templates, what improvements you need, &c).

Empty <series> blocks in the XML are handled properly in the PDF previews and CMA transforms

Some versions of authors' article templates include the following XML structure, which, when not filled out with series-title and/or series-url values, created PDF preview transform errors because the FOP was expecting a series-url value that was not present.

<series> <series-title/> <series-url/></series>

You can delete this block from your article template or, if your article is part of a developerWorks series, supply the needed values.

As part of this fix in the <series> area, we've also updated the way that series title transform works; it now handles entities such as accents properly. Admittedly this is a bit of an edge case. :-)

developerWorks JAR tools regression fixed

More recent compilations of the developerWorks java tools in the author package -- with a 1.6 compiler -- raised compatibility issues with author VMs and the way that the author package article transforms look for Java on client machines. This regression has been fixed.

Here's a list of the main tools, articles, and entry points for developerWorks authors, plus some explanation about what these are.

About developerWorks - Submit article proposals Do you have a great idea for a how-to article or tutorial that you'd
like to share with the rest of the technical community, one that will
help readers build expertise with an IBM product or underlying
technology? Our editors will review your proposal and contact you within
six weeks. Note: We will only consider original content not published elsewhere.

Authoring with the developerWorks Word and OpenDocument templatesThis article shows you how to prepare
English-language technical articles and tutorials for publication on the
worldwide developerWorks site using Open Document Text editors such as IBM
Lotus Symphony®, Apache Open Office™, LibreOffice, or another
editor that support the OpenDocument format (ODT), or using Microsoft®
Word. The steps are simple. You download our template package for either
OpenDocument or word, fill in the fields in the template, and then compose
your article or tutorial according to the guidelines in the template. Tips for
composing your content and submitting it to the developerWorks staff are also
included in this article.

Authoring with the developerWorks XML templatesThis article shows how to prepare
technical articles, tutorials, and knowledge paths for publication on the developerWorks site.
The steps are simple. You download our XML-based template for articles,
tutorials, or knowledge paths, fill in the template using any validating XML editor or your
preferred Microsoft® Windows® or Linux® text editor, check it
to ensure it follows the tagging structure as defined in the developerWorks
schema, and preview your article or tutorial. Tips for composing your content
and submitting it to the developerWorks staff are also included.

Using the developerWorks XML validation toolsIf you can't find a validating XML editor you like, or prefer
not to take the time now to learn how to use one, you can edit the XML for
your developerWorks articles and tutorials using your preferred text editor.
Ian Shields has created some great tools to help you validate, transform, and
preview your article or tutorial. This article shows you how easy it is to use
those tools on Microsoft® Windows® or
Linux®.