[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Axiom-developer] RE: Another question

From: Page, Bill
Subject: RE: [Axiom-developer] RE: Another question
Date: Tue, 22 Aug 2006 06:19:30 -0400


Thanks for the explanations about .4ht etc.

On Tuesday, August 22, 2006 5:09 AM you wrote:
> ...
> Bill Page wrote: 
> > When generating .html with embedded images for the formula
> > where do the image files go? Subdirectory? Since there will
> > be multiple pamphlet files on the wiki, we must take care
> > where to put the bits and pieces.
> ... 
> So everything is output in the directory where you process the
> file $(projectname).tex. Then I simply copy them to the place I 
> want them to be.

I read somewhere in the tex4ht that the path prefix of the
images directory is configurable. I suppose this is not normally
to significant, but I just did a few experiments using htlatex on

As a pdf file this is about 800 pages.  As html it generates nearly
600 png files and my browsers (both FireFox and Explorer) die while
trying to render it. And the download is pretty horrendous anyway
:( htlatex indicates a large number of errors which I simply skipped
for this test.

So it seems that ""one big file" here is not really such a good idea.

Running mzhtml on this file to generate MathML unfortunately results
in an improperly formatted XML file:

The xml file is about 3 times the size of the pdf file.

Interestingly, running the command

  htlatex bookvol1 "xhtml,jsmath" " -cmozhtf"

to produce a jsMath HTML file results in a file that is slightly
smaller than the pdf file:

Unfortunately the jsMath rendering takes quite a long time - about
2 minutes on my 1 GHz system. It's only about a minute if I set
the option to delay display until after the jsMath processing.
But it does do a pretty nice job ... To bad there doesn't seem
to be any way to get more speed out of JavaScript.

> ... 
> > So it seems that to get reliable HTML this way, we may need
> > to upgrade the standard of LaTeX used in the Axiom pamphlet
> > files.
> Well, maybe we should start with dhmatrix. I somehow agree with
> you and Eitan. Writing TeX should not be considered the best way
> of writing a  .pamphlet file. LaTeX is so much more structured
> that it is easier to convert to other formats. One cannot do all
> the TeX tricks and outputs equivalent HTML. Page numbers is one
> thing that you don't need in html.


> Anyway, would it be a good start to take dhmatrix. We could 
> tex->latex it while we try to get an html out of it.

Good idea except it looks like this one works already! This document
was one of the test files that I originally recommended to Eitan so
perhaps he did tweak tex4ht a little more to help make this work.
(If so, thanks Eitan. :)

The tex file is available here:

> And... perhaps we should first forget about mathml. I think the
> .png generation is the easier way to go.

htlatex generates

and about 70 png files with no errors.


  htlatex dhmatrix.spad "xhtml,jsmath" " -cmozhtf"

produced the following jsMath document (also with no errors):

It takes about 30 seconds to render but I think it looks great.

Finally mzlatex gives:

unfortunately with another xml error message:

XML Parsing Error: mismatched tag. Expected: </msub>.
Line Number 310, Column 17:>D</mi></mrow></msup 

> > I am willing to give this a try. But I am probably going to need
> > some help. :)
> Well, do we have an svn branch for that? I just want to say 
> "svn update" and "htlatex dhmatix" (or better make dhmatrix.html).
> Once we have some experience with compiling dhmatrix, we could cary
> on for the other files. Then you could try to write a python wrapper
> to get it into mathaction.

You should be able to do that now. Take a look for


and just noweave the dhmatrix.spad.tex file.

> Let us also forget for a moment about the \begin{axiom} ... 
> \end{axiom} environments. Just translating them as verbatim
> would be fine.
> Later, I think, one needs a script that runs over the
> .pamphlet.tex file, extracts the content of the environment,
> writes it out to a file/several files axiom.somenumber.input,
> and at the same time modifies the environment \begin{axiom}
> ... \end{axiom} to \begin{axiomoutput}{somenumber} ...
> \end{axiomoutput} and writes a file Then
> run axiom and produce files axiom.somenumber.tex (maybe 
> a script is involve here to split the axiom output into its
> parts -- but that you know already from mathaction, I guess).
> After that call htlatex on the generated file.

Sage has a very nice little latex package for doing exactly
this sort of thing (but more simply). I think we can easily
adapt it for Axiom. If you have the Sage distribution, it is
in the 'examples/latex-embed' directory. If you don't want
do download and install all of Sage, then I can just send it
to you. Also the new graphviz.sty has a similar technique that
could even be used to run Axiom automatically as part of the
LaTeX compile.

> The \begin{axiomoutput}{somenumber} ... \end{axiomoutput}
> environments should simply ignore there content and set the
> content of the file axiom.somenumber.tex.
> Doesn't sound un-doable to me.

Quite doable. Now, the question is: Are Axiom developers and
users really motivated to use this sort of thing??

Bill Page.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]