[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: DOCBOOK-APPS: best tool for docbook?
If a writer can chime in: the issue for me anyway is not so much WYSIWYG (I do get the markup paradigm) as good GUI design. There are so many pieces to deal with (entities, IDs, etc.) that it becomes a little like herding bumblebees to manage them all. What the masses (like me) need in an editor is a tool that overcomes the limitations of serial text navigation. That's what GUIs are for, not just to prettify things. To put it another way, the point is not to hide the document structure, but to reduce the complexity of the authoring process. For example, Emacs is probably powerful enough to provide everything an editor needs if you know about modes and such, but its interface is so damn complicated that, as you say, it takes more effort to use the tool than to write content. At least for non-programmers. Denis -----Original Message----- From: Rafael 'Dido' Sevilla [mailto:email@example.com] Sent: Thursday, August 23, 2001 11:20 PM To: firstname.lastname@example.org Subject: Re: DOCBOOK-APPS: best tool for docbook? On Thu, Aug 23, 2001 at 05:21:34PM +0100, email@example.com wrote: > >> But they need at least approximation of visual appearance during editing. > They aren't able edit text without some level of WYSIWYG. If they have this problem, then they have not completely internalized the philosophy behind DocBook. > I agree with the statement but not sentiment. > > Don't the vast majority of users who author content want an easy life when > it comes their editor? Why should they do battle with their editor > (remembering Emacs keystrokes, Docbook syntax, symantics & structure, > constantly customising stylesheets & upgrading their toolchains for > example) when all they really want to concentrate on is the content of the > document they're authoring? > Remember, the semantic information that DocBook allows you to encode with its elements can be a significant and very useful part of the content of a document. > I remember my growing pains when I first started using Docbook & XML. I > constantly see clients in the field who would benefit from using Docbook > but I don't recommend it to them because I know what a headache I'd get > supporting them. > That's because it looks like all the tools available for processing DocBook are immature to some degree. Arguably, this includes even the stylesheets. > Don't get me wrong. The current open-source solutions are great. They do Are you kidding? Current open-source DocBook tools are in varying degrees of immaturity. We have the DSSSL toolchain, which is stuck with just a single tool (OpenJade). We have the XSL toolchain, which builds on top of a standard which has yet to become a W3C Recommendation, and currently consists of two FO processors that can't yet produce proper output for a lot of the cases the draft standard defines. > the job and there's an army of motivated users, experts & developers work > on improvements all the time (how many commercial software vendors can say > the same for their software?) but in my opinion there is a vast market out > there for some sort of GUI tool to aid the content authors. > Perhaps, but not one that would give them any sort of WYSIWYG editing capability. > To me, that tool would be a mixture of a Plain Text Editor (Emacs, > Notepad, whatever), the Delphi/Kylix Code Editor (colour coded tags, > code-completion etc.) and XMetal (for their XML support and XML tag > Context support). Features like drag & drop would help and also a ^^^^^^^^^^^ What for? I'm not sure what you would drag and drop. Dragging and dropping XML elements into a document is an extremely cumbersome way of doing business, especially when you have the hundreds of elements in DocBook. > dedicated Docbook parsing & compiling engine that works straight off the > shelf and supporting all the usual formats - RTF/DOC, HTML (chunked & > unchunked), PDF. > Among the XML tools I've used the xslide mode under Emacs has come the closest to this; it's FAR, FAR better for editing XSL stylesheets than PSGML will ever be. Unfortunately, it's XSL only, and while I believe Norm once tried to convert it to use the DocBook tagset (dbide), the attempt didn't seem to work. It acted very funny under XEmacs/Linux, nothing at all the way xslide works. At the very least we need a better Emacs major mode for editing DocBook, one comparable in functionality to AucTeX for TeX/LaTeX. I don't think it would be too hard to make such a creature... I think another useful thing that content authors might want will be a way to interactively customize the stylesheets. The first step has already begun with the CGI scripts Norm has on his page that create custom XSL stylesheets, but they don't go far enough in what they allow you to customize. The non-trivial customizations I've had to make to cause my documents to conform to my company's standards for internal documents required that I learn XSLT and XSL Formatting Objects; it took me about a month of studying the standards, looking for tutorials on XSLT and XSL-FO (thanks Norm!), understanding the idiosyncrasies of the various tools for processing formatting objects, and studying the stylesheet code before I could do it (fortunately Norm's coding style is very clear, thanks again!). This sort of editing however, is not something an average joe can do, and I believe a lot of the skill needed is beyond that of even some members of this list. I think this is a bad thing. It should not be necessary to learn XSL (or DSSSL) just to be able to customize the stylesheets more than superficially. (In my case it was ok as part of my job required that I learn these technologies anyway, for projects completely unrelated to DocBook.) Any tools that can allow you to make more than superficial customizations to the stylesheets easily would be very useful. If any WYSIWYG system should be available, it is one that allows you to see your document formatted with the stylesheets, interactively customize them, and immediately see the results of customization. -- Rafael R. Sevilla <firstname.lastname@example.org> +63(2) 8177746 ext. 8311 Programmer, InterdotNet Philippines +63(917) 4458925 http://dido.engr.internet.org.ph/ OpenPGP Key ID: 0x5CDA17D8 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
Powered by eList eXpress LLC