[texhax] lwarp package — Native LaTeX to HTML conversion

[Brian Dunn]

On Sunday, March 20, 2016, Deyan Ginev wrote:
> Looking at the implementation
> details, it seems that much of the inevitable customization is again
> present - in order to resolve the "impedance mismatch" between the
> printed page and the hypertext webpage, various high level constructs
> need to be mapped correctly over to the HTML

CSS3 brings extra capability in some areas.

The question of where to intercept the code is an interesting one.  It would 
be desirable to use as much of the existing code as possible in the core and 
commonly-used packages, patching only at a low level where necessary, but so 
much of what LaTeX does is irrelevant to HTML output, and so many packages 
patch each other, that the result can be a mess.  For this reason, many 
packages are "emulated" at the user-interface level.  As time went on, I found 
reason to more closely match lower-level data structures in order to re-use 
some existing code.  Floats are an example; using the existing data structure 
allows the cleveref package to work as-is, even though the high-level float 
code is emulated.  Using \CaptionSeparator from babel is another example.


> the amount of work that it took to get to the current stage

I describe it in the manual  as a large number of small technical challenges.  
The first version was LaTeX to Asciidoc, allowing Asciidoc to handle many of 
the low-level details.  Asciidoc is one of the most complete markup languages, 
but of course still had limitations in what could be done.

> the estimated difficulty for adding support for new packages.

Text-related packages may very well work as-is or with minor patches.  In 
fact, I have not yet made bibliography citations into hyperlinks, for example, 
but they do appear in the text as-is.  Anything with graphics can be embedded 
inside a "lateximage", which will appear as an SVG image in the HTML result.  
See the math environments as an example.  (Described in more detail a few 
paragraphs below.)

The real work goes into adapting necessary features, but which in LaTeX 
include a lot of underlying code which has to be re-interpreted for HTML.  
Floats are a big example, but so is something like algorithmic.  \hfill and 
friends are not easily translated, so some patching with CSS was required.

By the way, digging through all the old code makes me appreciate modern 
packages such as xparse, etoolbox, xifthen, xstring, everyhook, calc, 
arrayjobx, zref, environ, printlen, etc.  Thanks to all these authors!


> I see that there is a Tikz -> SVG support already
> operational. Is that building on the tex4ht driver for SVG directly?

The environment is embedded inside a "lateximage".  The way it works is LaTeX 
draws the image on a page by itself, and also writes external instructions to 
grab that single page, tight crop, convert to SVG, and rename.  Meanwhile, 
LaTeX places a reference to that name in the HTML output.

The same procedure is used for math, which has the unfortunate side-effect of 
littering the project with images, and there is not yet any mechanism for 
reuse.  Copy/paste yields the LaTeX expression for each math object, inline 
with the regular text.

There are some counterarguments for the ideas of using 300dpi PNG or GIF 
instead of SVG, or MathML with the use of some post-processing.


-- 
Brian Dunn
BD Tech Concepts LLC
http://www.BDTechConcepts.com
bd at BDTechConcepts.com

http://www.linkedin.com/in/bdtechconcepts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texhax/attachments/20160321/85d068bb/attachment-0001.html>