Re: Michael Kay's comments
> I'm afraid to disappoint you and other readers, but the technology and
> process that Wiley use is not bleeding edge. All content is authored,
> reviewed, and corrected in Word; then it gets moved into (I believe)
> Quark
Some of you know that I work with XML and traditional publishing
applications as well as XSL-FO (to a limited extent, not to the level
of the major contributors to this list).
As Eliot Kimber said later in the post, human factors such as
author's preferred writing applications and publisher's preferred
design and layout tool are what keep us from better structured
publishing. Markup is unnatural to writers (even those who know how
to use "styles" don't immediately get the concept of structured
markup). The factors that drive efficiencies in production systems of
XML and XSL are content volume, throughput, translation and
personalization, which are important in business document production.
Customization of presentation page by page, as traditional book
publishers do, is a different worldview, more of a craft or even
rising to the state of works of art.
Technical publishers are in a unique position of having more
tech-savvy authors who could create structured content, but the
layout person at the publisher has to understand how to use the
content in their publishing application. So design folks need to
understand how to import and flow XML content, for example.
The most freeform (tweakable) XML publishing application IMHO is
Adobe InDesign. The best developed application for structured
publishing in book form is Adobe FrameMaker. Arbortext Editor and
JustSystems XMetal are both good XML authoring tools but lacking in
page layout, color separation and press pagination capabilities. The
most widely used authoring application is MS Word.
We have found that depending on the circumstances, you might find
Infinity UpCast (MS Word to XML) application an excellent starting
point for moving into any of the other application, due to the
ubiquity of Word. You can get a good generic XML output from Word
with UpCast (including nested sections and properly formed tables and
lists, and footnotes/references) and then transform it to match your
governing schema or DTD. We can batch process Word docs with UpCast,
post-process them to our preferred XML standard and then either use
XSL-FO to PDF with Ant for output that doesn't need page-by-page
customization, or import the XML into InDesign or FrameMaker for book layout.
Interestingly, DITA is becoming a new universal medium of exchange --
in technical documentation for example -- and most publishing
applications that handle XML are now offering DITA plugins (ie.e
DITA2InDesign) or built-in DITA handling, including ditamaps
(FrameMaker). This might mean eventually a form of DITA may become
useful in non-fiction book publishing generally. The hardest thing is
to keep the tag set simple enough to do the job but rich enough to
provide semantics when they will be helpful downstream. For example,
we had to add ISO character entities to the DITA OT, and also subset
the DITA elements to keep authors from having too many element choices.
Every time I look at the book publishing business, I feel like that
industry is caught in a terrible bind between the difficulty of
getting good content from authors, and getting it into publishable
shape. There is a vast disconnect between the two activities.
Eventually a sophisticated browser-based authoring tool that captures
content in structure "under the covers" would seem like a logical way
to bring them together. We really need to get people away from MS
Word, and blogging, wikis etc. will help get more people used to
browser-based writing and publishing. On the back end, if the
publishers capture the online content with structure and flow it
directly into publishing applications, better collaboration between
writers and publishers' designers will arise. It's not that far away
from happening.
Regards, Dorothy