If for the purpose of translating that file to html you provide
an appropriate axiom.sty (and axiom.4ht) which can be different
from the current existing axiom.sty, then I believe that should
be doable.
Sorry, I've forgotten most of what I once knew about tex4ht. :)
Of course we want only one source file from which to generate all
of the dvi, ps, pdf and html. I presume that the required changes
to 'axiom.sty' can be made compatible with all these formats?
What is axiom.4ht? Can it be present in the source .tex even
if I just run latex to get the standard dvi, ps, and pdf?
If you latex the .pamplet.tex file then (of course) latex does not know
about axiom.4ht and ignores it completely. So nothing will change.
Now, htlatex... that does invoke latex, too, but before the
\documentclass of the file is touched, several tweaks specific to tex4ht
are done. One of that is that whenever you have a \usepackage{blah} it
reads the file blah.sty and later also blah.4ht if that is there. (I
hope, I remember that correctly.)
Normally tex4ht is clever enough so that you simply don't need the .4ht
file. In ALLPROSE, however, I have these colored environments done with
the "framed" package which did not work with tex4ht. Fortunately, it was
quite easy to find an equivalent for the html output. That I have
written into allprose.4ht. See Chapter 26 or the ALLPROSE documentation.
Anyway, forget about the, .4ht until something does not htlatex. Then
post to the list and to Eitan Guari. He tries to be quite responsive in
such matters. I really don't know why the LaTeX people haven't included
tex4ht in normal TeX distributions. Tex4ht is really quite powerful
because it uses the tex machine.
Let's press the html button.
You mean metaphorically speaking ... :)
I the case of the Axiom Wiki this action actually takes place
during the 'Save' button processing. The 'html' link on the
header line would be just that - a link to the html file
previously generated by htlatex.
Oh, if that is done this way, no problem. Of course it is better to
cache the html output.
Then noweave is called to produce .tex.
Then htlatex is called to produce .html.
(you might want to call makeindex/bibtex... in the middle)
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.
Ehm.... the html target in ALLPROSE looks like
html: tex4htlatex tex4htpostproces docdir
$(CP) $(projectname)*.html $(DOCDIR)
$(CP) $(projectname)*.css $(DOCDIR)
-$(CP) $(projectname)*.png $(DOCDIR)
@echo
@echo "$(HTMLVIEWER) $(DOCDIR)/$(projectname).html &"
@echo
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.
By the way, if you look at the toplevel Makefile, you'll realize that I
don't call htlatex. The version of tex4ht that I get with debian sarge
did not meet my needs. Meanwhile I had conversations with Eitan and some
other guy who improved htlatex and friends quite a lot. I don't know,
however, whether this is already released.
I don't see the problem except that tex4ht sometimes needs
a little help if strange commands appear in the LaTeX text.
Yes, as I recall this is were we ran into some trouble. The Axiom
pamphlet files contain a lot of tex neologisms which are acceptable
to latex but the author of tex4ht, Eitan Gurari, considers need
not be accepted by tex4ht.
http://lists.nongnu.org/archive/html/axiom-developer/2005-10/msg00233.ht
ml
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.
And... perhaps we should first forget about mathml. I think the .png
generation is the easier way to go.
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.
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
.pamphlet.ax.tex.
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 .pamphlet.ax.tex file. 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.
Ralf
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer