[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: XML suites to manage DocBook projects?
On Thu, Feb 14, 2002 at 02:21:55PM +0100, Kraa de Simon wrote: > Hello, > > I'm in a dilemma on what editorial environment I should provide to our > DocBook authors. > > The authors are used to edit their documents in MS Word: 100% wysiwyg. > > I evaluated XML editors like XML Spy and XMetaL and I can imagine that using > these editors this is going to be a shock to at least some of the authors > (editing the XML 'directly'). > > Should I add a layer on top of the XML files hiding all XML detail from the > author? How far should I go? E.g. author chooses 'Add Chapter' from the menu > instead of 'typing' '<chapter></chapter>'. E.g. content and structure is > stored in a database and valid DocBook XML output is generated by the system > based on this data. > > The argument is that some of our authors will never ever adopt a XML editor > to edit content: not wysiwyg; to difficult; don't understand it etc. > > Will such a system/interface essentially feel the same for the authors as a > really good XML editor/suite? > > Are such systems already available? Specifically designed to handle DocBook > documents? > > What is your opinion on this? I'm not sure you saw all of XMetal. It has three display modes, only one of which shows the raw XML. The Normal View with a decent CSS screen stylesheet hides all the tags and formats the display so it looks pretty darn wysiwyg (big bold headings, bullet lists, numbered lists, etc.). Authors select Docbook tags like they select styles in Word, and the stylesheet lets them think it is being formatted. The problem is that XMetal doesn't come with a Docbook CSS screen stylesheet out of the box, so Docbook looks like plain text. Try downloading the set of DocBook support files for XMetal from the DocBook sourceforge CVS contrib area. Of course, it isn't really wysiwyg and doesn't permit the local formatting options for text fragments like Word does, but it is something authors can adapt to. It is certainly better than entering text fragments into a database form, which is as far from Word as I can imagine. 8^) But they *will* have to learn about the nesting of Docbook elements, otherwise they will be very frustrated. When the editor denies certain movements of text that Word permits but that don't fit in the Docbook DTD content models, then you'll see angry rejection. Some training is essential. I usually tell authors to work in the Tags On view (still formatted) until they get used to the nesting. Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: bobs@caldera.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC