Le 22 avr. 09 à 23:11, Jean-Marc Lasgouttes a écrit :
Maybe, maybe not. I began to look at the "special" formats and I am
wondering
from where to start.
My goal is to implement the new tag OutputFormat in layout files, that
would complement OutputType. However I'd like to do it right.
When OutputType is defined, it would imply a default output format
(latex, docbook, literate)
Then one would be able to override it: OutputFormat "sweave" comes to
mind to support R. I could just do like everybody did, add my own
special code to handle my little problem and be done with it, but it
does not look right.
Similarly, the j*.layout classes could declare OutputFormat "platex",
but then there is the issue of the hardocded japanese encoding. The
code in BufferParams is so ugly that I cannot guess what it is
supposed to do (for example, are there cases where we require
"japanese" but the encoding package is not Encoding::japanese
?). "platex" seems to be a subformat like "pdflatex" is, but is there
a pdfplatex, or does it only export to dvi?
And there is of course the "xetex" case, which is yet another latex
variation. I tend to think that if should be considered qs equivalent
to pdflatex, but things are not as simple.
Actually, the goal I had when looking at this code was to allow _any_
preprocessing of code to take place. If define OutputType "foo",
declare a foo->latex converter and, voilà!, the code will be exported
as normal latex (because of OutputType Latex). From there, the
converter machinery should be able to do its stuff.
Of course, this will mean some changes: for example LITERATE should
eventually not be an OutputType (which mean that we could have
docbook-based literate programming), but maybe a converter flag,
for example.
The global conclusion is that I do not know where I am heading.
However, it seems to me that, if we could define what are the
principles of our formats, it should be possible to cleanup the
code by small steps until it looks good.
JMarc
