[l2h] greetings

[Franco Bagnoli]

On Wed, 8 Aug 2001, cabney wrote:

> It needs some refactoring though, and I want to know if anyone would mind
> if I took a swing at it.  I'm new to TeX, but a pretty sure hand at Perl.

[snip..]

I have planned since a long time to try to improve the speed of
latex2html. Up to now I was unable to find the time, but who knows...

The bottleneck of l2h is latexing, converting to ps, cropping, etc. so I
think that one could increase performances a lot by caching the
images. And caching increases the more document are processed (at present,
caching only occurs for the subsequent versions of the same document).

My idea is to use l2h as a "server", or with a server part, so that one
can profit of site sharing of caches. In this way it would be possible
also to develop a (quick) mod_latex module for apache, so that one needs
not to convert latex documents to html, only put the source on some
public accessible directory (since it is processed by a modulus, the
source is unavailable to direct download).

The idea of cache is very similar to what happens at present with
images.pl: use the latex fragment as key to access the image part.
Since in the server case one has to face with concurrent access, it may be
necessary to use a database to store the data, the choice of actual
database can be made transparent using the tie mechanism.

Clearly, the cache is more effective the smaller the images, and should
revert to usual caching for html 2.0 and similar modes.

One could also think to develop a dvi-to-html driver to bypass ghostcript
and cropping, much in the way tex4ht works (is it true?):  the dvi says
where to put a given entity, and since the image of the entity is present
in the cache (or is generated) it should be possible to process it using
the ImageMagick or GD module.

Moreover, one could profit of the mod_perl feature of having
a perl interpreter (and l2h functions) always in memory. This would imply
rewriting l2h so to  avoid global writable variables (i.e., an object
oriented approach).

I'm writing these ideas in order to have your opinion, and also to suggest
people thinking to a large rewrite of latex2html to consider leaving the
appropriate "slots" in the code:

1) persistence of code
2) accessing the database of cache
3) processing of latex pieces

> 	* I'm bored.  I've been on vacation too long and I want something
> 	  nifty to work on.  Trying to grok graph theory and reconcile it
> 	  to principles in molbio got me on this visual kick (& Knuth
> 	  is da bomb.)

You're lucky

> That's it, except to say again I think latex2html is a very nice program.

I agree.

-- 
Franco Bagnoli (franchino) <bagnoli@dma.unifi.it>
Dipartimento di Matematica Applicata "G. Sansone" - Universita' di Firenze
Via S. Marta, 3 I-50139 Firenze, Italy. Tel. +39 0554796422, fax: +39 055471787
GPG Key fingerprint = 169D 9EA5 8FD3 7EDA E43A  9830 255F BCEC 0D63 3728