Re: Kernel docs: muddying the waters a bit

2016-03-07 Thread Russel Winder
On Fri, 2016-03-04 at 09:46 +0200, Jani Nikula wrote:
> […]
> If we're talking about the same asciidoctor (http://asciidoctor.org/)
> it's written in ruby but you can apparently run it in JVM using
> JRuby. Calling it Java-based is misleading.

Indeed, I was somewhat imprecise. Thanks to the work mostly of Charles
Nutter, JRuby is invariably a faster platform for Ruby code than Ruby
is. So yes ASCIIDoctor is JVM-based via JRuby, not Java-based.

The real point here is that in a move from DocBook/XML as a
documentation source, ASCIIDoctor is an excellent choice.

-- 
Russel.=====Dr
 Russel Winder  t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net41 
Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.ukLondon SW11 
1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part


Re: Kernel docs: muddying the waters a bit

2016-03-03 Thread Russel Winder
On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
> 
[…]
> However, I think asciidoc has two serious problems:
> 
>   1) the python version (asciidoc) appears to have been abandoned in
>  favor of the ruby version. 

This is I think true, however the Java-based tool chain Asciidoctor is
I believe the standard bearer for ASCIIdoc these days, albeit called
ASCIIdoctor.

>   2) It really is just a docbook pre-processor. Native html/latex
> output
>  is poorly supported at best, and exposes only a small subset of
> the
>  full capabilities of the input language.

This is not true. Yes ASCIIDoc started as a DocBook/XML frontend so as
to use a sane :-) markup language rather than XML (XML is a notation
for consenting computers only), but the current ASCIIDoctor toolchain
deals very well in direct HTML and PDF generation, without needing a
DocBook/XML toolchain. 

> As such, we would have to commit to using the ruby version and either
> committing to fixing the native html output backend or continuing to
> use
> the rest of the docbook toolchain.

Or trial the JVM-based ASCIIdoctor which is what the projects I am
involved with chose to use. Perhaps as an example I can give you http:/
/gpars.website (it's a redirector) all the HTML and PDF is generated
from ASCIIDoc source using ASCIIDoctor driven with a Gradle build
system. This is still very much a work in progress (by Jim Northrop,
not me currently), but I like it.

> We could insist on using the python version, of course. I spent a bit
> of
> time hacking that up to add 'real' support for a table-of-contents in
> the native HTML backend and it looks like getting those changes
> upstreamed would be reasonably straightforward. However, we'd end up
> 'owning' the code, and I'm not sure we want to.

If the Python version is really not being maintained, I would suggest
that unless you want to take over the project and be it's maintainer,
you would be better advised to use a different version.

-- 
Russel.=========Dr
 Russel Winder  t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net41 
Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.ukLondon SW11 
1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part