Ralf, 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 http://wiki.axiom-developer.org/images/book--main--1/bookvol1.tex 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: http://wiki.axiom-developer.org/images/book--main--1/bookvol1m.xml 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: http://wiki.axiom-developer.org/images/book--main--1/bookvol1.html 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. Agreed. > > 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: http://wiki.axiom-developer.org/axiom--test--1/src/algebra/DhmatrixSpad > > And... perhaps we should first forget about mathml. I think the > .png generation is the easier way to go. htlatex generates http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/dhmatr ix2.spad.html and about 70 png files with no errors. Running htlatex dhmatrix.spad "xhtml,jsmath" " -cmozhtf" produced the following jsMath document (also with no errors): http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/dhmatr ix.spad.html It takes about 30 seconds to render but I think it looks great. Finally mzlatex gives: http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/dhmatr ix3.spad.xml 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 src/algebra/dhmatrix.spad.pamphlet 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 .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. 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?? Regards, Bill Page. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
