Re: Can extension build own SGML document? - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: Can extension build own SGML document?
Date
Msg-id CAFNqd5VxiGJQ1kMXerwvSej251HdNQwnxKge_hyui9e6n6JBnA@mail.gmail.com
Whole thread Raw
In response to Re: Can extension build own SGML document?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Can extension build own SGML document?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 14 October 2015 at 13:04, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 9/15/15 10:13 AM, Tom Lane wrote:
Jim Nasby <Jim.Nasby@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?"

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allow ssl_renegotiation_limit in PG 9.5
Next
From: Alvaro Herrera
Date:
Subject: Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files