axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Re: article "standard" header/footer


From: root
Subject: Re: [Axiom-developer] Re: article "standard" header/footer
Date: Tue, 29 Nov 2005 19:48:11 -0500

> 
> For what it's worth, I would estimate I'll eventually ask to have the
> following available, since they are very standard and too big to reall
> :
> 
> 1) hyperref (which I see you've already decided to include)

agreed. this is important because 
(a) the code isn't linear,
(b) we eventually want it all available in a browser frontend and
(c) a way to use this in graphs would give us a good "map" ability

it would be cool to take the src/doc/endpapers.pamphlet and make it
display well on MathAction with hyperref links to the algebra.



> 2) bibtex (I'm working on an example based on the units work, but I
> will need to do some thinking before I have a good example ready)

as i've mentioned before the thought is to use src/doc/axiom-bib.pamphlet
as the basis for an annotated bibliography. i think it is important that
we centralize this and use a common mechanism rather than spread the
bibtex across hundreds of individual files. and the annotations will
be valuable in the long run anyway.

i'm convinced that i need to remove \begin{thebibliography} from
all of the files and use the bibtex mechanism. it's on the todo list.
(of course, i have to re-re-remember how to do bibtex :-) )




> 3) XYpic - I think this is gong to prove very very useful once I figure
> out how to use it properly - it seems like it might potentially allow
> inclusion of graphs directly into pamphlet files and not as graphical
> files, among other features - I think it will also allow hyperlinking
> nodes of graphs to code, although I'm still trying to come up with a
> scheme for layout of such a graph which looks reasonable. 
> Unfortunately it is GPL so we can't include it in axiom.sty, but tetex
> at least includes it by default so I'm guessing it wouldn't be too much
> trouble.  Maybe we could contact the authors and ask if it becomes an
> issue.

we certainly need two kinds of environments, 

one for pictures. i've tried several and they "sort of" work but the
pictures float all over the place and i've never succeeded in getting
two pictures separated by text on the same page. this is still an
outstanding problem with the book.pamphlet file. gotta solve it someday.
the book.pamphlet uses 'GRAPHICX'

one for diagrams. i use a package called PSTRICKS in the
src/doc/endpaper.pamphlet that did the job reasonably well but 
i'm open to other suggestions. we could test competing packages
against rewritten versions of the endpaper pamphlet.




> ifthen and fontenc I'm willing to pass up, but I would like to know how
> we will handle:
> 
> a)  different options to hyperref based on pdf or dvi creation
> b)  line breaking of equations
> c)  specifying different sizes, fonts, etc for text.  This is probably
> just my ignorance of LaTeX

i'm DEEPLY opposed to conditional branching in tex documents. even
if there is one good use i assure you some bright spot down the line
will figure out a way to conditionally build algebra documents
based on half-a-thousand switches. and if something gets skipped
it is hard to recognize that something that "should" be there isn't.

fundamentally the goal of a literate document is to communicate 
with people, most of whom are reading the document because they
want to learn and understand the material. making a document that
has conditions they need to choose up front means that they know
what they want.

i'd rather put all the conditionalization into the build process
before latex runs and keep the documents non-branching.

t




reply via email to

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