RE: embedded equation component manifesto (long)

[Paul Topping <PaulT mathtype com>]

Comments below.

----------------------------------------------------------------
Paul Topping                          http://www.mathtype.com
Design Science, Inc.                  email: pault@mathtype.com
                                      phone: 562-433-0685
----------------------------------------------------------------

>         Of course, you want the word processor to be able to 
> talk to you and
>         this will be achieved only if it implements the 
> corresponding interface.
>         My feeling is that you should define a set of 
> interfaces, implement them 
>         in your product and wait for a good wordprocessor to 
> implement the 
>         corresponding ones. In the meantime, ppl will be able 
> to use your 
>         component in a non-perfect way :(

This hits the nail on the head. Who in their right mind goes to the trouble
of creating a component that supports an interface that is required for it
to be at all useful, and then waits for some word processor to come along
that supports the desired interfaces? It is my hope that the movers and
shakers in the Gnome project will see the need and generality in the kinds
of things I've been talking about and make these interfaces standard.

> My conclusion on this is that you should wait for:
>         - abiword to be bonobized (I heard it was high on 
> their to-do list)
>         and talk with the abiword developers in having them 
> implement a nice
>         set of interfaces.
> 
>         - open office code to be released and talk with the 
> developers in 
>         having then implement those same interfaces. 
> 
> However, it might be a good idea to try to work on a set of 
> needed interfaces 
> first since it might speed things up.

Who are the people that I should talk to?

> > 3. "Auto" Line Spacing
> > 
> > This item doesn't really have anything to do with the 
> interfaces, but has
> > been a problem with several word processors. Word 
> processors often try to do
> > some kind of automatic line spacing where, if something "unusual" is
> > embedded in a line (an equation object or a stretch of text 
> in a different
> > font), they will change from the normal line spacing to 
> allow extra space
> > between lines. This sounds ok, but in practice they are 
> ultra-conservative
> > in performing this adjustment. With inline equations, the 
> preferred behavior
> > is for the word processor to detect that a too-tall 
> equation overlaps the
> > text in an adjacent line and let the user decide either to 
> reformat the
> > equation to be less tall (by changing a fraction from one 
> with a horizontal
> > bar to a diagonal one, for instance) or to make it into a 
> display equation.
> > No way does the user want the line spacing changed in a 
> paragraph for a
> > single line --- this is just bad formatting. This is a big 
> problem in MS
> > Word.
> 
> I am not too sure of the UI design for this feature.
> Under what form of user interraction would you expect this to be 
> implemented ?

I'm not sure I understand your comment. My statement was to make sure the
designers of word processors and the like avoid what is perhaps one  of the
most bothersome of MS Word's deficiencies in typography.

> > 5. Cross-Page and Column Embedded Objects
> > 
> > It is quite common to have a block containing several 
> equations stacked
> > vertically. It is desirable to handle this as a single 
> object so that
> > equation-specific alignments (e.g. by equal signs) can be 
> maintained. It is
> > often desirable to handle page and column breaks within the object.
> > 
> > Very long equations are often broken into a stack of 
> expressions, but in a
> > math-specific way where a plus or minus sign at the 
> line-break point will be
> > duplicated at the right end of the upper line and the left 
> end of the lower
> > line.
> > 
> > Both of these require quite complicated size negotiation between the
> > container and the embedded equation object.
> 
> Could you provide a sample scenario for such a negociation ?

Perhaps an easier example to understand is that of an embedded spreadsheet
that should be broken across one or more page breaks. I don't think the
requirements for equations are much different.

> > 8. Many Equations per Document
> > 
> > Due to the nature of math, it is common for a document to have many
> > equations per document. When programmers think of embedded 
> objects in a
> > document, I think the example that comes to their minds is 
> that of embedding
> > a spreadsheet or two. This mindset causes several potential 
> problems:
> > 
> > a. Performance. If all the objects on a page are "active" 
> in some way and
> > this is not expected by the implementors of the object 
> system and/or the
> > word processor, this may cause severe memory and speed issues.
> 
> I am not too worried about speed. Memory might be an issue 
> but my answer
> would be: "go buy some RAM". Raph would agree here ;-) And 
> no, I am not 
> working for a RAM chip firm :)

As with several of my items, I am motivated by things that are problems for
MS Word. A 10-page technical document containing 200 individual equations is
typical. Such an MS Word document has a disk footprint of a megabyte or so.
Also, it caches a graphic metafile for all equations that were displayed at
least once in a session and only deletes them when Word is quit. If you shut
the computer down and let the shutdown event make Word quit, the files don't
get deleted and, therefore, they accumulate over time. Whereas I don't
expect a Gnome word processor to have exactly these problems, I don't think
it is hard to believe that a programmer that is imagining a typical document
with one or two embedded spreadsheets is necessarily going to make
implementation decisions that will work for documents with hundreds and
perhaps thousands of equation objects.

> > b. Document-wide preferences for the embedded object. 
> Because there can be
> > so many equations in a document, it is necessary that there 
> be some sort of
> > document-wide context for preferences. It would be quite 
> tedious if the user
> > had to specify which fonts and point sizes are to be used 
> for each and every
> > equation individually.
> > 
> > The solution that our Equation Editor uses is to make these 
> choices global.
> > This helps but creates a problem when the user wants one 
> set of font & size
> > choices for one set of documents (say for submission to a particular
> > journal) and another for for documents for use within the company or
> > university. MathType's solution to this is to allow the 
> user to associate a
> > preference file with a document or a document template. 
> This helps but it is
> > a problem if the user sends the document to a colleague but 
> doesn't include
> > the preference file.
> > 
> > The solution that is needed here is to allow each embedded 
> object editor to
> > store a "bag" of preferences in the document and to have interfaces
> > available to access them. The word processor simply carries 
> this around as
> > baggage data, perhaps in XML form.
> 
> This is an interesting issue. 
> I guess we could ask containers to support an enhanced 
> version of the PropertyBag
> interface to support hierarchical property definition.
> ex: 
>         Document
>                 Image
>                         adjust-size-auto: yes
>                         adjust-colormap:  yes
> 
>                 Equation
>                         foo: bar
> 
>                 Graph
>                         default-graph-type: bleh.
> 
> Then, the UI to set those would be pretty simple: you make the main
> document generate a list of the applications which are available on 
> the system and which provide a DefaultProperty interface and you ask
> them to give you a Bonobo::Control to set the settings.
> (pretty much similar to the Future GNOME control-center.) 

Sounds good.

> BTW:    unless I missed this from your mails, your company is 
> obviously not 
>         planning to release any GPL code ? You are just 
> planning to provide
>         good (paying) equation support in free word-processors ? 

Well, we really don't have plans either way. What you suggest is one
possibility. Although we are a for-profit company, I personally get turned
on by technology done well. The latter is closer to my motivation in
presenting this material. As I hinted earlier in this reply, I wouldn't do
anything for Gnome, for profit or for free, unless I felt that the people
creating the embedded object infrastructure understood the issues well
enough. 

> Mathieu
> 
> -- 
> Mathieu Lacage <mathieu@eazel.com>
>