RE: equation editors and TeX (long) (was "Equation Editor")

[Paul Topping <PaulT mathtype com>]

Martin,

Responses below.

Paul

> -----Original Message-----
> From: Martin Sevior [mailto:msevior@mccubbin.ph.unimelb.edu.au]
> Sent: Monday, September 04, 2000 5:58 AM
> To: Paul Topping
> Cc: 'gnome-components-list@gnome.org'; 'Sri Ramkrishna'
> Subject: Re: equation editors and TeX (long) (was "Equation Editor")
> 
> 
> 
> Hi Paul,
> 	Thanks for your thoughtful email. I have spent quite a 
> bit of time
> thinking about what I would like an equation editor to do too.
> 
> Here are my thoughts.
> 
> The editing component should be modeless and stay up and 
> available until
> the user wishes to close it. The most recent equation is 
> displayed in the
> editor and can be inserted at any point in the document with a single
> mouse click.

If by "modeless", you mean its toolbar, etc. stays up until the user
dismisses it, even if the user is not actually entering an equation, then I
agree. That said, I still think that equation editing has to be a mode for
many of the same reasons TeX has a mode. While editing an equation, the user
needs to have an extensive set of keyboard shortcuts available that probably
overlap with that of the word processor. The word processor's font selection
model (choose a font/style, type, choose another font/style, type some more)
must be different from that of an equation editor's (font/style for
variables and text fragments is set up ahead of time, interrupted by the
occasional math symbol, the entry of which doesn't change the current
font/style). The space bar should probably be disabled as spacing should be
automatic. Math typesetting uses about 6 different space widths, non of
which is equal to the standard inter-word space. And so on.

> The document and the contect of the equation should be visible at all
> times.

Agreed. Although it probably has nothing to do with your point, I'd like to
mention that "in-place editing" as in Word is cool in that the illusion is
maintained that the user is still editing in the document. However, it is
less that ideal for math as the document editing is usually performed at a
viewing scale of close to 100%. This results in text that is too small for
many equation features to be seen with current display devices. Unlike
Equation Editor's default of in-place editing, MathType defaults to editing
in a separate window at a scale of 200%.

> You should be able to to select type of equation components 
> using arrow
> keys and "enter". The current equation component is highlighted with a
> light colour and can be shifted around the selection 
> rectangle with the
> arrow keys. Like Abiword's "Insert Symbol". 

I believe there are too many math symbols to affectively select them by
arrow keys and enter alone. MathType uses a customizable toolbar that the
user can arrow around in as well as assign keystrokes to their favorite
symbols and templates. I haven't seen Abiword's interface, so I apologize if
I have it wrong.

> The equation components should be selectable using latex 
> keystrokes ala
> Lyx. We should also allow the user to easily change and view what each
> keystroke invokes and does. 

Agreed. We've considered adding a keyword style interface to MathType in
order to appeal to the TeX afficionados. MathType does have a powerful
keystroke assignment system where commands can be invoked using one or two
keystrokes. For example, a built-in keystroke shortcut uses Ctrl-G, followed
by a letter keystroke to enter a Greek letter - Ctrl-G, a for alpha.

> We should have an easily accessible help available from within the
> component with help limited to just the equation editor.
> 
> At this stage I'm not sure whether the equation should be entered
> immediately into the document or first just previewed in the equation
> editor for insertion later. Having the equation in the editor 
> means that
> the user doesn't have to change their attention from the 
> component where
> they're selecting stuff to the document where the equation is 
> appearing.
> I guess we should do both.

See comments above on viewing scale considerations.

> Finally the document should be able to be exported to Latex so that
> people who prefer that environment or for whom MathML is not 
> sufficent can
> do their stuff. (Me)

Sure, but do you really want to design a system with the assumption that it
won't be the best tool for the job ;-).

> I've thought about your enhanced XML and I don't agree. If 
> MathML is not
> sufficiently rich it should be expanded by a standards 
> committee so that
> everyone can easily exchange documents. We in Abi already 
> have export to
> Latex so this is an easy decision. 

So, what you are saying is that Gnome/Abiword's word processor and equation
editor will be good for making very basic technical documents, but for
"real" technical work, users should export to LaTeX. That really makes me
sad. If you have set your sights this low, you can definitely count me out.
Say it ain't so.

> Anyway that's what I want from an entry point of view. I 
> think it is all
> doable. From a display point of view there is lots of code to 
> borrow. The
> MathML project in Mozzilla appears to making good progress in 
> implementing
> Latex quality symbol positioning. When I get the chance I'll look into
> that.

What I've seen of the MathML project in Mozilla looks really pretty good.
However, I must insist that you really think hard about this. Users that
have to create real technical documents will be forced to wait for years for
stuff to get added to MathML, symbols added to Unicode, and implementers to
catch up to both. MathML is an exchange format!!! An equation editor should
be able to both import it and export it, via cut-and-paste, drag-and-drop,
and programmatically.

> I haven't had the chance to look at the StarOffice equation editor. It
> will probabally be easiest to just develop that since it will be
> bonobo-ized by Sun for us.
> 
> Cheers!
> 
> Martin
> 
> 
> 
> _______________________________________________
> gnome-components-list mailing list
> gnome-components-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-components-list
>