Display options and turning the system inside out.

Looking at GtkMathView is helpful.  I think that for
one direction (output), Maxima could produce MathML and have
it rendered by GtkMathView. I am not convinced that MathML
or its rendering by GtkMathView is sufficiently general to
do everything Maxima might produce, but I have no
counterexamples. The alternative that Jay suggests,
that GtkMathView could learn about Maxima, is tempting.
But this does not address
the extension possibility that one might want to SELECT
from the display and get the underlying Maxima code.  It also
seems that GtkMathView along with some other
proposals including TeXmacs, Emaxima
depends on linux, at least for the moment.
It would also be nice to be using a solid version of
whatever program is proposed...

There is a deeper problem, potentially.  That is, one
might introduce to Maxima a new form, say from a particular
application.  This can be done by syntax extension, and the
maxima display program understands this and does a suitable
display.
   I am not sure how flexible the MathML renderer will be
in such a situation, or if we want to put that too in
GtkMathView.  It might be OK, but I'm not sure. Or would it
be simpler to put GtkMathView into Lisp (or call it from
Lisp as a renderer).



The advantages of the "in house" Maxima display program
continue to be:
   a rather deep understanding of the relationship between
the display and the math, re-rendering subexpressions to
different forms as specified by space constraints and flags
(e.g.  exp(x) or e^x?  1/exp(x) or  exp(-x)    etc).

Also the possibility of retaining its format "map" so that
a selection can be made of a subexpression by pointing to
its image.

The main disadvantage seems to be that there is no uniform way of
printing a particular glyph on a particular spot on the user's
display.
(Other disadvantage: someone has to fix up the program in
Maxima to reference font information, and probably other things.)


Jay Belanger wrote:

> C Y <smustudent1@yahoo.com> writes:
> 
> ...
> 
>>The problem of displaying Mathematical markup on multiple platforms has
>>never been fully addressed by any free library I am aware of.  The
>>closest one, which I beleve is the one most worth expanding and/or
>>basing our own solution on, is GtkMathView.  I have had communications
>>with the author indicating the code is not deeply tied to the GTK
>>toolkit, and just within the past few days someone has gotten it to
>>compile on Windows, so at least in theory it should be portable. 
>>Everyone I have heard discuss the code, even the founder of Gnome who
>>is usually highly critical of C++ code, says it is very well done.  Its
>>display, while perhaps not of the quality of TeX, is certainly high. 
>>It also has the ability to export to postscript.  Currently it is
>>mathml based, but if we were to add the ability to understand maxima's
>>representation of mathematics, the possibilities would begin to open
>>up.
>>
> 
> Using GtkMathView sounds like a good idea.  
> Was getting it to compile on Windows a tricky affair, do you know?
> 
> Also, instead of getting GtkMathView to understand Maxima's output,
> wouldn't it make more sense to give Maxima the ability to output in
> MathML? GtkMathView would then be able to deal with the Maxima output,
> and since MathML has aspirations of becoming the lingua franca of
> computer math applications, I would expect this would become useful in
> other areas besides display.
> 
> On a slightly different note, MuPAD has an output filter capability;
> the command
> Pref::output(fn)
> will result in all subsequent output being replaced by fn(output).
> I would think that something like this in Maxima would make it easier
> for different frontends to get the output in a useful form.
> 
> Jay
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima



Re: turning the system inside out...

what I mean by this is having every version of maxima start
as the maxima top-level read-eval-print loop  and hanging fancy display
off this.  That is,
read-eval-print    becomes  read-eval-fancydisplay loop.

What we have been discussing is

entirely-new-read
   send message to maxima
   receive message from maxima
entirely-new-display

loop.

This works, but it puts the control in the front end.

In fact there are many front ends possible, including one that looks
like this (emaxima). I gather it works like this:

Construct a whole document which occasionally includes math,
implemented by
creating a "cell" which includes a maxima-eval-maybe-typeset command.

Send the cell to maxima to evaluate.

So the model here is one of primacy of a document.
The model in Texmacs is, I think, similar, though there is this
  underlying  "almost Latex" encoding.
The model in Xmaxima  (Schelter's Tcl) is primacy of extended html
  (in one window) and a typewriter script (in the other).

Part of the decision as to what to do is a decision
between models.
My favorite model is script-in-ascii-window  (maxima.el mode),
but then I don't make much use of 3-d plots.

RJF




>