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

[C Y]

--- root <address@hidden> wrote:
> > 
> > 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

As you can see in the Units file, XYpic enables (c).  Not all the links
are active in that version, but it was 2am and I was tired ;-).

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

Hmm :-).  For the inattentive among us, what is endpapers.pamphlet
again?

> > 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.

Oh, agreed.  I ment how to structure and format the bib file.
 
> > 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'

I forget which one I used for Maximabook.  I'll have to check.  Images
are a problem - I'm afraid the only way I ever found to get reasonable
image quality in pdfs with Maximabook was to use uncompressed pngs,
which eat space and make for large pdf files.  But then space is cheap
nowadays...

> 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.

Yes, I saw PSTRICKS - it looks very interesting (I particularly like
the 3d plotting module) but I don't know how it does with pdf output. 
And I don't think it is capable of the hyperlinked diagram I did with
XYpic.

Maybe the advanced PSTRICKS routines could be converted to using XYpic
as a backend?


> 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.

OK.  But that still leaves us with the problem of how to handle
necessary options for pdf vs. dvi.  TeTeX 3.0 and up seem to insist on
making a pdf if the options to hyperref include pdf specific options,
which is why I had to use the ifthen package for hyperref.

I don't mind doing it "differently" I just need to know how to maintain
the functionality while doing so :-).  Unfortunately I'm not really all
that good with LaTeX yet.

> 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.

In this case, pdf vs. dvi is the main choice.  (margins are mainly
suger for developers doing lots of repeated printing.)  That's one they
can't get out of, although I suspect most users will have little
interest in the dvi format, particularly on Windows where I know of no
good free viewer.

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

OK, but as I mentioned TeTeX 3.0 is going to conditionalize its output
based on options to hyperref, so any pdf specific options (which I
would think we would want) are going to cause problems.  If we want to
define local.sty files and have them used by make to configure the
documents as needed on the fly that works for me, if it can be done.

Cheers,
CY


                
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/