Re: [Axiom-developer] Re: Axiom Book

[root]

Actually the booklet program can join multiple pamphlet files. 
It allows you to make chunks with a protocol and a URI:
<<pamphlet://foo/bar/baz.pamphlet>>

I didn't use it because I wanted the book to be pure latex, at least
until I was ready to do further integration work into the system
which won't be for a while yet.

> I have looked at this.  I think what will have to be done is update the
> commands which are loading the graphics files to use includegraphics
> instead of the current oddness.  For example:
> 
> \begin{figure}[htbp]
> \begin{picture}(324,168)%(-54,0)
> \special{psfile=ps/h-matsource.ps}
> \end{picture}
> \caption{Source code for {\tt Matrix}.}
> \end{figure}

The "current wierdness", as you say, is my attempt at graphics in latex
which I've never tried before. The key annoyance is that I've been
unable to get two images on the same page. 

> This special command doesn't seem to be well suited to pdf and ps joint
> usage. If I strip the special stuff out, I can include some of the
> graphics. Hyperref works fine, and produces a hyperlinked pdf.  The
> Bibliography upsets it for some reason - I think we need to modernize
> something there - but other than that I get chapter organization and
> everything.  I had to remove the setcounter{chapter} entries, however,
> to get reasonable behavior in that department. 

I'll look at what you did and try to copy it. 
 
> I have uploaded a hacked up version of book.pamphlet and the pdf
> created here:
> 
> http://garnetlisp.sf.net/axiom/book.pamphlet
> http://garnetlisp.sf.net/axiom/book.pdf

I've downloaded both. The pdf looks good and the graphics are
embedded properly. If I can fully understand what you (and BF and
David) have been trying to tell me about pdfs I might start 
autogenerating them in the doc directory.
> 
> > Right now, the graphics are in eps format (but with no bounding 
> > boxes in some cases. It blocks me to convert the graphics to pdf.
> > However I'm for from a postscript specialist). From an engineering
> > point of view, the best solution would be to have the reference 
> > graphic in one format that can be translated in needed formats by 
> > the Makefile.
> 
> In order to generate reasonable pdfs from the old ps images (the
> bounding box problem) I used eps2eps to clean up the images, and then
> epstopdf to make pdf images.  There were several images where eps2eps
> failed with a ghostscript error - those might have to be remade since
> if eps2eps fails it's usually difficult to do anything reasonable with
> them, in my experience.  Perhaps these are also the ones commented out?

I ran into the bounding box problem also. I did add bounding boxes to
most of the images I used but it was tedious.

> If a couple script files are written to automate the conversions, it
> shouldn't be hard to reference the eps files for everything, given no
> ghostscript errors.
>  
> > Regarding the 1.0 status, the lacking points are:
> > 
> >  1. Axiom book in PDF with graphics; 
> > 
> >     [done for pdf. Nobody is working on the graphics]
> 
> If we can use straight includegraphics that will solve 90% of the
> graphics problems.  Conversion should be doable except for the ones
> throwing postscript errors, which will have to be redone.

I'll have a look at where I was on the graphics chapter and see if
your technique will break the logjam holding things up.
 
> >  2. Define if the current found bugs are release critical or not. If
> >     yes, fix them. If not, document them (and reduce the priority in
> >     the 1-3 range);
> 
> Is the lack of a replacement for the NAG numerical libraries a release
> stopper?  (I seem to remember some mention of the GNU scientific
> libraries being possible replacements, but I don't know much more about
> it.)

I've also been working on this. I have imported the BLAS routines, 
converted them to pamphlet files, automated the build, and am now
looking at the machinery necessary to add them to the GCL lisp image
automatically. This is the first of multiple layers of numeric code
but the first layer is always the hardest because I have to break
new ground (at least for me).

Tim