Re: Can extension build own SGML document?

On 14 October 2015 at 13:04, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 9/15/15 10:13 AM, Tom Lane wrote:
>
>> Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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(at)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?"