[l2h] listings and figures

[Manuel Carro]

    Thanks, Ross, for your very detailed message.  Next come some of
my discoveries:

>> Can you determine exactly why the combination of calls:
>> 
>>   \usepackage[usenames,dvips]{color}
>>   \usepackage{colordvi}
>> 
>> caused a problem, and in which order ?

    After fiddling around with images.tex, the situation is the
following: this (fake) images.tex gives a LaTeX error

\documentclass{article}

\usepackage{graphicx}
\usepackage{pst-node}
\usepackage{color}
\usepackage{colordvi}

\begin{document}
foo bar baz
\end{document}

_but_ after removing \usepackage{color}, it compiles with no problem;
this could be an expected result; the interesting part is that if one
loads the packages in this order:

\usepackage{pst-node}
\usepackage{graphicx}
\usepackage{color}
\usepackage{colordvi}

then it does not give a single warning.  The original LaTeX document
has the first order inthe message, but it does not load color.


>> Doesn't  colordvi  require  color  with the dvips  driver anyway?

    I looked at it; it seems to use \special commands to generate
directly PostScript code.

>> It looks like the above line of coding could be usefully extended
>> to become:  
>> 
>>     $preamble .= $LOAD_LATEX_COLOR."\n"
>>         unless ($preamble =~ /[,\{]color(dvi)?[,\}]/);

    It definitely was: this allowed the figures to be generated.  I
also had to define 

$LATEX_COLOR = " ";

in l2hconf.pm in order to force the script not to generate the
\pagecolor command, which depends on \usepackage{color}.  With these
two things, the figures were generated --- a sort of frame appeared in
the down-left corner of mathematical formulas, but I believe this has
already been discussed; I'll dig into the mailing list archives.


>> >     s/((\%|$comment_mark\d*)|.)(\r*\n[ \t]*){2,}[ \t]*/$1\n\\par \n/og;
>> > 
>> > in the subroutine substitute_pars to
>> > 
>> >     s/((\%|$comment_mark\d*)|.)(\r*\n[ \t]*){2,}[ \t]*/$1\n\n/og;
>> 
>> This is the only way LaTeX2HTML recognises paragraph separations
>> in running text, so it is not a good idea to change it in this way,
>> as you discovered ....

    :-)


>> Try adding 'listings' to the following regular-expression;
>> currently:
>> 
>>  $verbatim_env_rx = "\\s*(\\w*[Vv]erbatim|rawhtml|imagesonly|tex2html_code)[*]?";
>> 
>> revise to read:
>> 
>> $verbatim_env_rx = "\\s*(\\w*[Vv]erbatim|rawhtml|imagesonly|tex2html_code|listings)[*]?";

    Hum, this one didn't achieve the expected result (if anyone wants
to try, the name of the environment is lstlistings).  The way this
environment is used is as follows:

\begin{lstlisting}{local-arguments}
    code
    code
    code
    code
\end{lstlisting}

    Most times the "local-arguments" part is empty, so it becomes

\begin{lstlisting}{}
    code
    code
    code
    code
\end{lstlisting}

    Does the presence of argument to the environment has to be taken
into account when defining the env. as not needing translations?  I
tried adding lstlisting to the variable $image_env_rx --- again, to no
avail: \par still showed up in the final images.

    Cheers,

        MCL

__________________________________________________________________
The last beauty that was written in C was Schubert's 9th symphony.