At 5:03 PM +1000 18/9/98, Dr. Marcus E. Hennecke wrote:
>On Sep 17, 1998 17:02, Bruce R Miller [[EMAIL PROTECTED]] wrote:
>> On Sep 17, 9:19am, Dr. Marcus E. Hennecke wrote:
>> > Take a look at l2h-ng. If called with -strict it does indeed read a
>DTD
>> > to output conforming HTML. It is based on an older version of l2h,
>> > though and probably contains quite a few bugs.
>
>> Is it using the DTD to validate the HTML, or using it to choose (or
>tune) which
>> HTML to generate?
>
>The former. There are basically subroutines that are called to insert
>HTML code. They in turn check if the code is valid according to the
>DTD.
>
>> An XML version will be more extreme because it is totally
>> up to the DTD (or the mapping between latex commands & DTD elements)
>what is
>> being generated.
>
>Yes indeed. The solution must be something that is concept based. E.g.,
>the LaTeX parsing engine first determines what is wanted (e.g.,
>chapter, bold face, verbatim, etc.) and then the rendering engine must
>decide what code to generate. IMHO, it is important to separate the two
>much more than they are now (at the moment there is almost no
>distinction).
It will be extremely hard to *drive* the translation from a DTD,
whereas validation ``on the fly'' is quite feasible,
as Marcus implemented for L2H-NG.
Adapting to a new DTD means rewriting the macros for environments
and commands that are to be handled by the ELEMENTs in the new DTD.
Do this in a file called mydtd.pl on the $LATEX2HTMLVERSIONS path.
and load it via:
latex2html -html_version 4.0,mydtd .....
Since it loads *after* latex2html itself, and the html4_0.pl file,
then its code will override subroutines that are already defined for HTML.
Thus if you want the information for a theorem-like environment
to be presented in a different way to what LaTeX2HTML currently gives,
then write your Perl implementation to catch that type of environment.
Everything else will be handled as normal, for HTML.
Thus making new DTDs that don't differ too much from HTML should be
rather straight-forward.
However turning-off *lots* of HTML features is much harder;
you'll have to write more Perl code to override the existing subroutines.
On the other hand, since environments are now captured as whole *chunks*,
before any processing of the contained commands and sub-environments
is performed, then your macro for an environment can choose to translate
its contents in whatever way you like.
i.e. you don't have to call &translate_commands
or &translate_environments until after doing whatever other processing
you want to do, if at all.
Warning: Don't leave any unexpanded macro-names, with the leading '\',
since any call to &translate_commands from a surrounding environment
will force them to expand later. In particular, the mandatory call
for the whole document will do this.
Hope this helps,
Ross Moore
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ross Moore email: [EMAIL PROTECTED]
Mathematics Department phone: +612 9850 8955
Macquarie University fax: +612 9850 8114
Sydney, NSW 2109 office: E7A-419
Australia WWW: http://www-math.mpce.mq.edu.au/~ross/
***************************
for the best in (La)TeX-nical typesetting and Web page production
join the TeX Users Group (TUG) --- browse at http://www.tug.org
<[EMAIL PROTECTED]>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
