RE: [Docutils-develop] Re: pdf writer

[Tony J I. (Tibs) <to...@ls...>]

David Goodger wrote:
> No, writers should support all elements defined in
> docutils.nodes.

That is clearly the desirable aim, and certainly should be true
initially.

> Engelbert Gruber wrote:
> Writers should but might not do always, as new elements are added
> not all writers will support immediatly and we should have a way
> to get documents out anyway.

Skipping the issue of whether (how) all writers should be updated if
docutils.nodes grows new nodes (an occurrence we expect to be rare once
docutils is fully out in the world), there is a related issue, which may
be more profitable to pursue (i.e., if we solve it, then Engelbert
Gruber's concerns should also be solved).

Let us imagine that we have a product-specific tool (for instance, to
pick a random example(!) pysource, or perhaps a Wiki tool), which
generates a DPS tree, and wishes to use a Writer to output the results.

The tree-construction part of the tool has two basic choices:

1. work entirely with the existing DPS nodes, to render what
   it wants to do (hint: I think this is the right approach)

2. possibly create new node types specific to its application
   area (which I believe David has advocated for pysource, at
   least, in the past).

*If* (2) is the "proper" approach, then we automatically have the issues
that Engelbert Gruber is concerned about - what does a Writer do when it
encounters nodes it does no recognise?

It seems to me that the counter-argument that anyone who invents such
nodes must amend any Writers they "care about" is not a sufficient
answer - I have two "obvious" counter-examples:

i.  the author of the Reader phase may not have the time or
    ability (or permission, even) to alter the Writer.

ii. given how simple it is to write XML out from docutils (in
    fact, the capability is already provided), and also, to
    read it back in (not provided, but trivial to do), there
    is no particular need for Reader and Writer to be in the
    same tool. I can already think of applications for this
    (I've been handling transfer formats too long, I guess...)

On the other hand, since all of David's current nodes "declare" (by
inheritance) what sort of entity they are, it should be possible (note
my hands waving vaguely in the air) to make sensible "fall back" code
for any future nodes, whether they are added "officially" or not. This
is a bit of a pain for me, because it makes my case against option (2)
above less strong, but I believe it helps Engelbert Gruber's case.

(Briefly, my reason for liking option (1) is that with the single
addition of a new "style" attribute to all nodes, I can get 80% of what
I want, and with a new node called "group", I get 100% - where "group"
translates, in HTML, to <DIV> or <SPAN> as appropriate, and "style"
translates, in HTML, to "class" - and if those become standard Writer
components, then I don't need any amendment in Writers to be able to
output what pysource produces.)

Tibs

--
Tony J Ibbs (Tibs)      http://www.tibsnjoan.co.uk/
"How fleeting are all human passions compared with the massive
continuity of ducks." - Dorothy L. Sayers, "Gaudy Night"
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)