[Doc-SIG] Producing output

[David Goodger]

Tony J Ibbs (Tibs) wrote:
> I'm not up-to-date enough with the TeX world to know if there are
> XML to TeX translators. Does ReportLabs PDF engine take XML as
> input?

Of course, such a translator would need style sheets in order to
understand the DPS XML output. (Forgive me if this is obvious; I
think it isn't obvious to many people). XML is not a single data
structure, it is a syntax for describing data structures. XML is
like the Latin alphabet; necessary to understand written English,
French, Spanish, Python, etc., but not sufficient.

[Paul Moore]
> > Maybe the answer in both cases is "you can't - we haven't got
> > that far yet".
> 
> Indeed, that is the case.
> 
> > Which is fine, but I'd say that getting some form of output
> > formatter is a priority, so that you can start getting
> > feedback from the unwashed masses like me, who are only
> > looking for something they can use...
> 
> Oh, we know, and we also want to be able to use the stuff! But time
> is only linear...

Any and all help is appreciated!

> At the moment, David is concentrating (I believe) on getting all of
> the DPS/reST engines working, to do what is in the specs.

Correct.

> At the rate he's going, I don't know how much longer that will take
> him.

Is that an expression of confidence or of despair? ;->

Seriously, though, the parser code is almost finished (95%). The
parser/DPS interface is also almost finished, at least until there's
another parser besides reStructuredText (at which time its needs
will be accommodated). Tibs is working on Python docstring mode
code, from docstring extraction to final output, but I haven't
examined it properly yet. It should prove a good source of code and
inspiration.

> In many ways, the HTML output phase is the least important - the
> derivation of a DPS node tree for Python, and the production of *an*
> example of an output formatter, is more important (than the specific
> format).

Indeed, that's the motivation for the entire DPS project. Each component is
independent of the others, as much as possible. Once the interface between
components is established, the addition of input or output formats, styles,
or modes, becomes easy.

> Personally (check with David for a more informed opinion!) I'd say
> that it would not hurt to have an alternative effort looking at
> producing LaTeX or PDF output from a DPS document

Definitely. The more the merrier, and the better the end product will
be. Each output format has its own requirements from its input, and
without multiple implementations we can't generalize.

> I have some ideas on the *form* that an output parser should take
> ... [but] I haven't had feedback from David about what he thinks of
> this,

Yes, apologies. The parser itch is close to being completely scratched
(code anyway), after which I'll turn my attention to other itches.
I'll scratch the parser internal docs itch gradually, especially
once the code has proven itself mature.

> or how he sees different formatters integrating into DPS in
> detail (I suspect he hasn't *got* detailed ideas yet).

Your suspicions are once again well founded. We'll take what you've
written, and I'll work on another output format myself, and we'll
determine the API through what works in practice.

-- 
David Goodger    goodger@users.sourceforge.net    Open-source projects:
 - Python Docstring Processing System: http://docstring.sourceforge.net
 - reStructuredText: http://structuredtext.sourceforge.net
 - The Go Tools Project: http://gotools.sourceforge.net