[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 required. * 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 FrameMaker. * 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: http://sourceforge.net/projects/db-xsl-cfg/ 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: http://www.getnet.net/~swhitlat/DocBook/docbook_section.html * 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. Steve Whitlatch > -----Original Message----- > From: David White [mailto:davidw@kencook.com] > Sent: Wednesday, April 20, 2005 1:46 PM > To: Bill Lawrence > Cc: docbook@lists.oasis-open.org > 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: docbook-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: docbook-help@lists.oasis-open.org > > > > > > > > > -- > > David White > > Web Application Developer > > Ken Cook Company > > 9929 West Silver Spring Drive > > Milwaukee, WI 53225 > > 414-466-6060 (voice) > > 414-466-0840 (fax) > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]