Methinks I missed a memo somewhere along the way. I don't recall any discussion about rigor.
>> And rigor, I suppose? pdf format is not frozen, pdf viewers are not >> bug-free. Remember an RMLL conference in Metz where the pdf file of a >> colleague didn't display some text of the file. dvi format is very >> simple and frozen, dvi viewers exist and can be supposed bug-free for >> these reason. Same old recurrent debate of "new" vs "old", >You misunderstood my question about dvipdfm. > >I don't like .dvi and .pdf. These are binary formats. Source counts. The sources are available and the binaries are built from the sources for the books, just like the binaries for Axiom are built from the sources in the books. Latex macros I've written (like the chunk environment) live in the axiom.sty file. All of the latex sources are in the books directory. These books also contain all of the algebra, C code, and the bulk of the interpreter and compiler code. Eventually the whole src and other directories will disappear into literate book form. PDF is widely used, available on all platforms, and is a published format that anyone can implement so it seems reasonably stable despite buggy viewers. I don't have an opinion about liking it. >It probably doesn't depend on dvipdfm whether one can do > > latex book.tex > >and > > pdflatex book.tex > >to optain .dvi and .pdf at the same time. Historically Axiom was going to support a dvi viewer as part of the new front end. That effort died but the discussion is still in the mailing list. See, for instance, the exchange between Michel Lavaud and David Mentre on 5 May 2003. It is trivial to ship .dvi files. They are created during the build and erased as a final cleanup. All we need to do is keep them around. >I had an effort (still unfinished in my 'fricas-book' branch) to revive >the AXIOM book. > >http://www.hemmecke.de/fricas/book.pdf > >My .sty file > >https://github.com/hemmecke/fricas/blob/fricas-book/src/doc/fricas.sty > >doesn't use dvipdfm, although (because of eps figures) the translation >also goes .tex -> .dvi -> .pdf and not straight to .pdf. > >I am simply not sure whether Tim needs dvipdfm at all and wanted to give >him a hint to try without it. I'm not sure I need it either and I appreciate the suggestion. For the short term I patched the problem by supplying the missing dvipdfm.def file. I can't change to dvipdfmx because it isn't backward compatible. Time will change that decision but the patch will work for now. Only the books use dvipdfm. It is not used in the src/input files, for instance. I used it because I am embedding or planning to embed URLs, eps images, pstricks diagrams, inline animation and inline video, all of which I have in local repos. There are certainly other ways to do this. It just hasn't been an issue until now. If anyone is feeling ambitious and cares enough it is easy to experiment. All of the dvipdfm files are books/bookvol*pamphlet. The Makefile that controls the latex/dvi/pdf is books/Makefile. So the problem is really well contained. Make a change, test it, and post a diff -Naur patch to the mailing list. Tim _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org https://lists.nongnu.org/mailman/listinfo/axiom-developer
