On 14 October 2015 at 13:04, Jim Nasby <jim.na...@bluetreble.com> wrote:
> On 9/15/15 10:13 AM, Tom Lane wrote: > >> Jim Nasby <jim.na...@bluetreble.com> writes: >> >>> On 9/15/15 8:43 AM, Tom Lane wrote: >>> >>>> AFAICT from a quick look at its documentation, asciidoc can produce >>>> either html or docbook output; so as soon as you want something other >>>> than html output (in particular, PDF), you're back to relying on the >>>> exact same creaky docbook toolchain we use now. Only with one extra >>>> dependency in front of it. >>>> >>> >> a2x (http://www.methods.co.nz/asciidoc/a2x.1.html) states that it can >>> generate "PDF, EPUB, DVI, PS, LaTeX, XHTML (single page or chunked), man >>> page, HTML Help or plain text formats using asciidoc(1) and other >>> applications (see REQUISITES section). SOURCE_FILE can also be a DocBook >>> file with an .xml extension." >>> >> >> AFAICS, for all cases other than HTML output, the "other applications" >> are basically the docbook toolchain. >> > > I just started looking at , which seems to be the newer way to handle > asciidoc. Aside from being a lot faster than a2x/asciidoc, it can produce > docbook natively. However... > > What I expect would be a lot more effort is actually converting all the >>> SGML to asciidoc. A quick google search doesn't turn up anything >>> promising. >>> >> >> Yeah, the cost of conversion means we're not likely to want to experiment >> to see what's better :-(. >> > > If the only concern is handling docbook format (which is what our SGML > docs produce? Then https://github.com/asciidoctor/asciidoctor-fopub might > be an option. It's intended for use with asciidoctor, but the README does > state: > > "Using the asciidoctor-fopub project, you can convert any DocBook file > into a nicely formatted PDF with nothing more than a Java runtime (JVM) and > development kit (JDK). All the open source software required to perform the > conversion is automatically fetched from the internet the first time you > run it." > > So maybe it would allow removing some of more problematic parts of the > toolchain? > > Also, if our SGML does produce docbook as an intermediate it might be > possible to convert that to asciidoc via > https://github.com/oreillymedia/docbook2asciidoc. There's a misconception there... Our SGML *is* DocBook. Natively, no translation needed. DocBook is a document type, and our documentation is already written using that document type (DOCTYPE). Easily seen thus: postgres@cbbrowne ~/p/d/s/sgml> grep DOCTYPE postgres.sgml master!? <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.2//EN" [ No "intermediate"; we're directly already using DocBook version 4.2. We'd presumably lose something by a DocBook ---> asciidoc ---> DocBook transition. The trouble that we have is that what we have isn't a "DocBook file", but rather a fairly large set of files representing a DocBook document. I'm not sure what improvement we'd get out of using asciidoctor-fopub. There would be some merit to some remapping to transform "creaky old DocBook 4.2" (what we're using) to a newer version, perhaps biased towards XML, and have our toolset merge the bits into a big XML (in DocBook 5, presumably) file for processing using more modern DocBook tools. I could probably build some DSSSL as helper (my HTML-to-DocBook DSSSL was highly incomplete, and nonetheless surprisingly widely referenced for years...), but we'd best be clear on what we think we're getting as improvement. Switching to a less expressive format is unlikely to be a win, however creaky the current DocBook/DSSSL tools are. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
