This is the mail archive of the
mailing list for the DocBook project.
RE: [docbook] DocBook and Publishing Software
- From: "Steve Whitlatch" <swhitlat at getnet dot net>
- To: "David White" <davidw at kencook dot com>,"Bill Lawrence" <lawrence at mayaviz dot com>
- Cc: <docbook at lists dot oasis-open dot org>
- Date: Thu, 21 Apr 2005 13:42:18 -0700
- Subject: RE: [docbook] DocBook and Publishing Software
Most others who have already replied probably have more experience than I have,
and I should mostly defer to them, but I can offer a few more bits.
* FrameMaker (both structured and unstructured) provides excellent print
composition and many other fine features, such as auto-list-generation and
auto-number-generation. These benefits are realized by the average FrameMaker
user who knows how to set up a template. No special technical knowledge is
* Structured FrameMaker has limitations, quirks, and deficiencies. But if you
are willing to pay consulting firms with C programmers who know the FrameMaker
Developer Kit and the FrameMaker Structure Application Developer Kit, they can
probably make structured FrameMaker jump through most any hoop you want.
* I agree that Epic Editor is a very good editor. Printing in Epic requires the
Print Composer add-on. When speaking about print composition and Epic Editor,
the situation can be complicated. This is not to say that Arbortext print
composition solutions are lacking, just that it's more complicated than with
* On-screen display in Epic Editor is controlled for most Epic users with FOSI.
My impression, but not necessarily my knowledge, is that FOSI is old,
unsupported, arcane, etc. You will probably pay dearly for a FOSI expert who can
make your on-screen document appearance in Epic Editor look WYSIWYG, but that
too is just my impression. And any new investments in time and effort with FOSI
are probably poor choices. Someone can correct me if I have this wrong, but when
using Epic Editor and FOSI, your print output is what you see on screen with
your online FOSI, but I do think it is not that simple. You can set up the
system any way you want, and you can make it different for different doctypes.
* XSL-FO is the way to go for print composition, and that is true regardless of
the editor or authoring environment. The DocBook XSL package is very good.
DocBook XML, DocBook XSL, and Epic Editor go together very well.
* But what about online display and formatting rules for print composition? Try
Arbortext Styler. With Styler, one can produce a "stylersheet" that makes the
online display not exactly WYSIWYG, but very close to it. With Styler, you can
also easily create the necessary XSL for FO output. Caveat: the XSL exported
from Styler is not completely transferable and easily used in other
applications. Arbortext uses some proprietary namespaces and I think it would
take some effort to make XSL exported from Styler work in other applications.
Also, Styler does not import XSL.
* Styler solves many problems. I like it, but it is new and not %100 perfect. I
expect any of its difficulties will eventually be worked out. If one can afford
it, Styler is good. I'm using an evaluation, temporary license version.
* Using Epic Editor, you may need to pay for some add-ons. You might also expect
these add-on features to come bundled with the editor at no extra cost. It would
be best if you just ask many questions of your Arbortext sales rep.
* If you go with Epic Editor and you do not purchase Print Composer, you will
need to format your output for print yourself, perhaps with a DocBook XSL
customization layer, the DocBook XSL package, and a professional-level FO-to-PDF
or FO-toPostScript tool (not FOP yet, coming, but not yet.) If you go with this
solution, you might also want to try DocBook XSL Configurator:
That's my pet project. DocBook XSL Configurator can be easily integrated with
Epic Editor. That's the way I use it, but it requires some adjustments to the
code. The Arbortext Epic Editor authoring environment is so highly customizable
that it doesn't really make sense for me to maintain downloadable Epic-specific
versions of DocBook XSL Configurator. It's a simple app, the source is
available, and it's under the GPL.
* It's a good idea to keep FrameMaker around. I like to use FrameMaker for
one-way formatting of XML for print, no round tripping of the XML. It just dead
ends there in FrameMaker. I have a lot to say about structured FrameMaker. You
can read about my experience with it at:
* One solution is to use DocBook XML and DocBook XSL, GNU Emacs, libxml2+XSL+XEP
for formatting (PostScript, HTML, Help, PDF, etc.), and get one of the experts
on this list to set it all up. That may be the cheapest and the best. For sure,
it would give you the most freedom.
> -----Original Message-----
> From: David White [mailto:firstname.lastname@example.org]
> Sent: Wednesday, April 20, 2005 1:46 PM
> To: Bill Lawrence
> Cc: email@example.com
> Subject: Re: [docbook] DocBook and Publishing Software
> ArborText is definately a solid product but I hear their data is
> proprietary and that their XML has extra junk in it so that it works
> better with their suite of software. Does this hinder its use for
> applications outside ArborText?
> Bill Lawrence wrote:
> > David,
> > I have to agree with Dave Pawson. Epic (Dave uses the old Adept name)
> > is the cadillac and the closest fit to a WYSIWYG application. I've
> > used it in the past at other companies, and I've specified it as our
> > editor here. Dave's equally right about writers adapting to XML and
> > tag-based editing. Some do easily, others do so more grudgingly. How
> > you sell the advantages has a lot to do with the ease of acceptance.
> > Our information design group uses InDesign exclusively, and it seems a
> > very capable page layout program. Much better than Frame but perhaps
> > not as powerful as Quark. It does have XML import and export
> > capabilities, but you need to build the tables that map tags to
> > internal styles. I'm still a couple of weeks away from building our
> > InDesign import/export filter, but from the testing I've done it
> > appears capable of importing Docbook structures. Tables are another
> > matter.
> > If you don't have a fairly in-depth knowledge of XML, XSLT, and FO,
> > consider taking some classes. Having that knowledge will go a long
> > way in making your transition to the world of Docbook a whole lot easier.
> > Good luck!
> > Bill
> > David White wrote:
> >> Hello all,
> >> The company I work for is making decisions about its plans for future
> >> docbook publishing and the current situation that Framemaker is in.
> >> Given that Frame may not survive, and that docbook / XML is the
> >> format of choice for our publishing needs. What are your opinions on
> >> software solutions for a publishing department? Granted the
> >> department has individuals of different roles such as writers and
> >> editors etc.
> >> The tools I have seen are two fold: WYSWYG publishing (ala frame) via
> >> Adobe InDesign (which I hear isn't ready yet to replace Quark or
> >> Frame yet, dont know its DocBook abilities at all).
> >> OR the XMetal route where publishers essentially become programmers
> >> and use something like Sernea from Syntext to be able to view their
> >> code.
> >> Anyone willing to offer their suggestions from the Industry as to an
> >> intelligent way to merge a department into the future of docbook
> >> publishing?
> >> Thank you,
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: firstname.lastname@example.org
> > For additional commands, e-mail: email@example.com
> David White
> Web Application Developer
> Ken Cook Company
> 9929 West Silver Spring Drive
> Milwaukee, WI 53225
> 414-466-6060 (voice)
> 414-466-0840 (fax)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com