Entries tagged with “docbook” from Tools of Change for Publishing

Balancing the Benefits and Costs of XML for Book Production

Andrew Savikas
October 1, 2008 | Permalink | Comments (1) | Listen

O'Reilly engineer and XML guru Keith Fahlgren kicked off a lively conversation on an internal mailing list this week by asking whether (and how much) we're "eating our own dogfood" in terms of Tim O'Reilly's recent post about IT.

Along the way, XML.com editor Kurt Cagle weighed in with his thoughts on the importance of an XML workflow (specifically one that plays nicely with his needs running a destination Web site):

Overall, I'd like to see us move to an all XML pipeline, not because I'm the XML editor (I'm actually writing more economics articles of late than anything) but because I think that a cohesive XML workflow provides us with the cleanest implementations that we can have, and ironically it's the one type of flow that may actually make it easier us to work with the content without needing to break open the content to do tedious search and replace operations. It provides the best reuse story -- it's a relatively simple proposition to convert a DocBook publication into an embedded Web block, for instance -- and it integrates well with feed production.

O'Reilly Publishing Services Manager Adam Witwer responded, and included some critical lessons learned about the challenges with moving to XML:

Over the past year or so, we in publishing services have adopted an all DocBook XML pipeline for several of the main book series (Animal, Cookbook, Theory in Practice, In a Nutshell, etc.). Retraining staff has been a huge challenge. From a technical perspective, developing the XSL-FO has taken (and continues to take) lots of time and iterations. But the biggest challenge has been convincing others that the small sacrifices that come with an XML workflow are worth it. We have less control over things like page layout in a book, and certain style elements that are easy in InDesign or Frame are difficult to replicate with XSL-FO stylesheets. For us in publishing services, those things seem like small trade-offs for the gain of having a single set of source files that are much easier to reuse, most notably on Safari, and to update. This ceases to be an issue when the stylesheets get to be nearly indistinguishable from the InDesign/Frame templates on which they are based, so that's what we've tried to do, and we've transitioned away from the traditional page layout programs and general approach to book production.

It's worth noting that this all applies to what happens after we receive a manuscript, many of which are still being written in Word. There's a lot that can be done without ever opening the can of worms that is authoring and in XML.

Related Stories:

• Why You Should Care About XML
• Chunks and Verticals and Niches -- Oh, My!
• Can the Author Really Help?
• TOC Resource: XML
• See more StartWithXML posts

Open Source DocBook XSL Experimental EPUB Support Released

Andrew Savikas
June 3, 2008 | Permalink | Comments (3) | Listen

Publishers with content in DocBook XML format can now easily create EPUB files using the open source DocBook XSL package (which already supports output to HTML and to XSL-FO -- a format that can be turned into PDF -- along with several other formats). Here at O'Reilly we've long used DocBook as the format for Safari Books Online, and more recently been using it more for standard book production (rather than converting to XML from a format like FrameMaker).

The 1.74.0 release is experimental, and additional feedback would be a big help for improving the output. From Paul Norton at the Adobe Digital Editions blog:

The ePub target has been tested against a number of files, but I would encourage those of you who use DocBook to try out the new target and to submit any issues you find to the tracking system on the DocBook project site. The only way we'll know if it doesn't work for you is if you tell us. :)

My personal thanks to Keith Fahlgren for driving the development of the ePub target and basically making it happen.

I'll second the thanks to Keith (an engineer here at O'Reilly) for his work on the project, and also extend the thanks to Paul and to Adobe for their contributions.