Re: [Aimmath-developers] AIM and Maple 9 not good news

[Greg G. <gr...@ma...>]

On Thu, 24 Jul 2003, Jon Breitenbucher wrote:
> Interesting. Here is what I get
> 
> > > interface(verboseproc=2);
> > > eval(`latex/latex/function`);
> > proc(e)
> > local `(`, `)`, `,`, texlist, `{`, `}`, ` \\left( `, ` \\right) `;
> > ...
> >         texlist := texlist, LaTeX:-CheckLineBreak();
> > ...
> >         LaTeX:-CheckLineBreak()
> > end proc
> 
> What is the LaTeX:-CheckLineBreak? This looks like a module reference 
> and is missing from LaTeX.mpl

Hi Jon,

Looks like you found the problem. Those commands are new. There must be
a new module called LaTeX in Maple 9. This seems to be the usual way they
proceed, e.g. there has long been a linalg package, but LinearAlgebra is 
their module package - it re-implements and extends the older package.

So what does

> ?LaTeX

tell you? I hope that it will at least tell you that LaTeX is a new
command in Maple 9 that returns a string. Then, at least, one could
possibly omit the LaTeX.mpl package completely ... though possibly
doing that will still run into problems with tth (Neil's `LaTeX/trim`
command deleted extra whitespace that upset tth).

> ...
> I'm guessing that this is the culprit. Is this a redefinition of 
> latex/latex/function to return a string?

No, the small changes that Neil made to the Maple latex/... functions
were to improve the output so tth would work with it. To get a string,
Neil uses the `latex/print` command in the body of AIM's LaTeX command.

> Maybe not. I tried commenting out all of the things you indicated and I 
> still get Maple to LaTeX errors even for things like u+s+w+z.

I'm sure whatever Maple 9 now has defined in the LaTeX module (I'm 
convinced it exists) is messing things up.
 
> Another question. Do you have any idea why my answers are being parsed 
> in reverse? -exp(1) seems to get parsed as (1)pxe- and AIM says pxe is 
> a forbidden name.

The reversal is mysterious. The forbidden name bit makes sense though,
since AIM rejects any undefined names longer than 1 character.
  
> Also, I noticed when viewing the source that AIM produces <script 
> language="javascript">. This is not valid HTML 4.0.1. It should be 
> <script type="text/javascript">. 

I guess all the current browsers still support it ... hence why we
haven't had any problems with it. However, there is a chance that
some browsers follow the letter of HTML 4.0.1 more closely, and so
will be broken. 

> Also the <font> attribute is depricated and AIM should be using
> CSS style attributes. 

You are right ... we should use CSS style attributes eventually,
but I suspect that <font> will be a supported tag by browsers for
a long while yet, since so many webpages use it. I would say, this
is not a high priority change, but we should eventually make the
change to using CSS. Changing to XML/MathML may make this imperative.
(I'm not exactly sure what's supported in XML by say mozilla).

> Are these concerns for the developer list?

Yes, eventually. I don't know whether the first one might be urgent
... if a browser like opera, konqueror or safari doesn't parse
language=javascript, I would class it as reasonably urgent. If on the
other hand changing to use type="text/javascript" breaks Internet
Explorer, then I would say we should leave as is, at least for now.

  Regards,
  Greg