Documentation file format

John Ralls jralls at ceridwen.us
Fri Dec 13 10:03:26 EST 2013


On Dec 13, 2013, at 2:41 AM, Mike Evans <mikee at saxicola.idps.co.uk> wrote:

> On Fri, 13 Dec 2013 08:26:42 +0100
> Christian Stimming <christian at cstimming.de> wrote:
> 
>> I know I'm jumping in rather late in this thread, but here's my take  
>> on the ever-long question of our documentation file formats:
>> 
>> I think the priority of the documentation file format should be:
>> - to generate HTML and PDF output from it
>> - and to make it easy for documentation writers to edit the text
>> 
>> As secondary goals, I think it is nice to be able to generate epub and  
>> mobi output and also yelp's output from this (or does yelp read  
>> docbook natively?!), but I think those are not as important.
>> 
>> Given these priorities, I think both our current documentation file  
>> format and also a potential wiki workflow might not be the best  
>> solution. Instead of the current file format (docbook xml, split into  
>> several files using xml entities) we should very well think to switch  
>> to some other solution that makes the text much more accessible for  
>> documentation writers. For example, if libreoffice/openoffice would be  
>> able to use the docbook xml file, except for the fact that it's split  
>> into multiple files using xml entities, then we should just as well  
>> drop the split file approach and merge the full text into one single  
>> docbook xml document.
>> 
>> However, this wasn't the only problem with libreoffice, IIRC, but I'm  
>> not sure. If we just don't fine any up-to-date word processor that can  
>> work with the docbook xml, I would suggest to switch to a different  
>> file format instead, such as ODF or similar, and just continue working  
>> on the document with libreoffice et al.
>> 
>> If a wiki approach is possible without too many extra steps in a  
>> workflow, that's fine as well, but I'm afraid it adds a whole lot of  
>> extra problems into the process. For example, what would be the  
>> process to generate a new gnucash-docs release package so that gnucash  
>> can be installed with at least as much offline available documentation  
>> as we have today? If there are solutions for this, then fine, a wiki  
>> based solution might be a good way to continue. Otherwise I'd suggest  
>> to simply switch to a better file format.
>> 
> 
> Since no-one has mentioned it yet, what about asciidoc?  It's much simpler that the xml we have now, is very easy to learn, it is plain text, it handles multi-part books, and AFAIK the current docbook can be converted to asciidoc without *too* much effort.
> 
> It's just a thought because I use it for pretty much all the documentation I write.  It's not WYSIWYG but it's a lot better than directly editing docbook.xml.  I guess LibreOffice can be used as long as it doesn't introduce artifacts into the plain text, although a plain text editor would be better, vi|emacs|geany perhaps.
> 
> Anyway, my 2p|2c

Looks like it would work. What do you see as the advantages over better-known markups like markdown and wiki? How would we get the existing DocBook documents into ascitext format?

Regards,
John Ralls




More information about the gnucash-devel mailing list