developerWorks Authoring Tools
This blog is about authoring tools. Mainly about the set of XML authoring, 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.
See you soon,
We've created an author package update (Build 20120928) with the following changes.
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>You can delete this block from your article template or, if your article is part of a developerWorks series, supply the needed values.
PDF transform also handles entities (example: <Aacute/>) properly in series/series-title
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.
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.
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:
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.
The authoring tools build team has made an update to the developerWorks author package available that features the following fixes and enhancements:
Note: We've updated the article Authoring with the developerWorks XML templates to point to this updated authoring package, which you can find here: