A week or so ago, there was a debate about some design issues in l2h, such as
what the evaluation model should be, how accessible the internals should be,
and so on. I'd like to provoke a bit more discussion about where l2h should go
and how it'll get there... so...
There seem to be 3 `kinds' of users (we can be diff types at diff times)
1) Wants to process clean, properly structured LaTeX and expects clean,
properly structured HTML out.
2) Wants to process _any_ TeX/LaTeX, even incorrect TeX, and get some kind of
HTML out.
3) Wants to construct customized, structured documents that process
appropriately in both LaTeX & l2h -- expecting to have to do some coding.
And these different expectations put different, contradictory, demands on L2h.
Can they even be covered in the same program? It'd be nice...
Ross seems to be strongly in camp 1, and it doesn't seem debatable that that
is a primary reason for L2H -- is it?
Ross makes an admirable effort to accommodate (2) as time permits. I suspect
he does it grudgingly (:>) and I mostly agree, although I have been in the
position of having to process `legacy' tex without wanting to change the TeX
source. I can't see why people should expect l2h to process incorrect TeX,
though. In any case, to pull off (2), the evaluator has to emulate TeX's
(peculiar) evaluation a bit better than it currently does.
Question: is it worth it?
In my current project, I have a need for (3); it sounds like Fred Drake is in a
similar position (?). This use of l2h may seem esoteric, and not require much
support from the developers. But, isn't a move towards XML going to require
much more flexibility in document structure? Structured, yes, just not
rigidly predetermined structure. Or do the developers anticipate targetting a
single XML DTD? The catch with this application of l2h is to develop pairs of
*.sty and *.perl files to get the appropriate (but different) behaviors
in both LaTeX and l2h. I dont think that the evaluation model is _that_
critical for this application, but the `api' and internals of l2h are.
Currently, l2h is pretty brittle, simple changes have unintended consequences,
and information is spread out in various places. New versions of l2h-- for
which I'm grateful-- generally breaks a lot of things.
I dont really begrudge anyone this; of course I realize that l2h didn't come
with an official API and a guarantee that nothing would change. But mightn't
we evolve l2h in such a direction that it could be more easily extended and
customized?
Any thoughts appreciated.
--
--
[EMAIL PROTECTED]
http://math.nist.gov/~BMiller/
