Re: [Axiom-developer] Axiom, Ubuntu and texlive

[daly]

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