Re: embedded equation component manifesto (long)

[Mathieu Lacage <mathieu eazel com>]

Paul Topping <PaulT@mathtype.com> writes:

Here are random comments on your feature description:

        unless I am uttelry mistaken, all the "features" you have been 
        describing can be added to the bonobo framework pretty much easily.

        Take the nautilus example:
                "Nautilus views" are what allows you to display a directory
                content in specific ways. We have an icon view, a list view, 
                a music view and many more (we hope) in the future.
        
                Nautilus views are nothing but bonobo embedables/controls
                which happen to also support a NautilusView interface.
                The idea is that nautilus can use "simple" bonobo components
                to display views but it also checks wheter its views support
                the NautilusView interface. If they support it, it allows
                nautilus to provide better integration between the view
                and the main window. You can add any number of those interfaces.
        
                An example of such an interface in nautilus is the "zoom" 
                interface which allows the main window to control the view 
                zoom level. If the view supports it, we use it. Otherwise, 
                too bad for the user.

                The above functionality is achieved through the use of the
                base bonobo interface named Bonobo::Unknown::query_interface
                (equivalent to OLE's Unknown::QueryInterface.)

        How is the above example related to your problem ?
        I believe that to solve the baseline problem (for example), you could
        define an interface inheriting the Bonobo::Unknown interface which 
        provides all the necessary hooks for discussion between the container
        and the embeddable.

        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 :(



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.

> 
> Finally, the list:
> 
> 1. Baseline Alignment
> 
> Many equations must flow with the text in which they occur. A simple
> expression like the square root of ax + b, where the root is expressed using
> the usual radical sign, requires the formatting capability of an equation
> editor (i.e. it can't just be typed in the word processor), but it is too
> small to place in its own paragraph. In the lingo, the two kinds of equation
> are "inline" and "display".
> 
> Inline equations have a natural baseline, the baseline of "ax + b" in the
> above example. If the embedded object's boundary is a rectangle, the
> location of the baseline can be expressed as a distance from the bottom edge
> to the baseline. This information should be passed to the container along
> with the bounding rectangle (and the side bearings, see below.). See
> http://www.mathtype.com/support/tech/misc/baseline.gif for a pretty picture.
> 
> The container must position the embedded object vertically to align the
> baseline of the equation with that of the surrounding text.
> 
> Although baseline alignment is normally thought of in the context of inline
> equations, it actually applies to display equations as well as an equation
> number is usually placed at the right margin on the equation's baseline.


see above

> 
> 2. Side Bearings
> 
> In general, an inline equation (or an inline anything, for that matter)
> should have a similar relationship with the surrounding text as does an
> individual character glyph. A character glyph has a baseline, an origin on
> that baseline, an advance width, and a rectangle surrounding the glyph image
> (non-left-to-right writing systems are ignored here). See
> http://www.mathtype.com/support/tech/misc/glyph.gif for another pretty
> picture.
> 
> Although an inline equation may contain many glyphs, for formatting
> consideration, it can be treated as a single glyph. In particular, its side
> bearings must be considered during line layout. To give an example of the
> kind of problem that can occur if side bearings are ignored, imagine an
> inline equation that ends on the right with an italic "f" (like the one in
> the image linked in the preceding paragraph), followed by a comma in the
> document. This is a very common case in technical docs. If line layout
> ignores side bearings and just uses the equation's image rectangle, there
> will be extra space between the "f" and the comma.
> 
> MS Word does not respect side bearings. Those users with any typographic
> sophistication at all learn to ignore these glitches. It is my hope that a
> Gnome word processor (and any other for that matter) could do better.

see above too.

> 
> 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 ?

> 
> 4. Ambient Font, Size, and Style
> 
> Although equations use math fonts that may not be used elsewhere in the
> containing document, they also contain characters whose font and size must
> track that of the document. If the document's body text is in 10-point
> Times, the equation's variables will be also. Subscript and superscript
> sizes will be specified as percentages of the body text size. Functions,
> like "sin" and "cos" will be in Times plain, whereas variables, like "x" and
> "y", should be in 10-point Times italic.
> 
> So, it is important that the embedded object have access to the "ambient"
> style information. This can be done by having the container pass this
> information into the embedded object but a better way is to pass it a
> pointer to a "embedded document object site" interface that allows the
> embedded object access to all kinds of document information.

idem: see above (beg of mail)

> 
> 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 ?

> 
> 6. Spell-checking, Search & Replace, Global Font and Size Changes
> 
> Because equation objects are a special kind of text, users expect them to
> participate in document editing operations such as spell-checking, search &
> replace, and font and size changes. For example, if someone selects a
> paragraph in a word processor and changes its font from Times to Helvetica,
> the equation would most likely change its "primary font" accordingly. Its
> functions (e.g. sin, cos) would change from Times, plain to Helvetica, plain
> and its variables would change from Times, italic to Helvetica, italic.
> Greek letters, mathematical operators would remain unchanged.

I do not really like the idea of having users be able to change the font in
mathematic text. However, I see your point. Same solution as above.

> 
> 7. Cross-Equation Alignment
> 
> Although most alignments are intra-equation (except for baseline alignment,
> of course), it is often desirable to align things between equations. For
> example, it is quite common to have two display equations with an
> intervening paragraph or two. Professional quality typesetters want such
> equations to align at their equal signs (or other relational operator). This
> is particular example of what I describe in general in the next section.
> 
> 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 :)

> 
> 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.) 


> 
> 9. Accessibility Issues
> 
> Because of equation object's dual nature as both text and graphics, dealing
> with accessibility by the visually impaired can be problematic. Some such
> users choose a user interface color scheme that allows them to type white
> text on a black background. This is allowed by modern word processors.
> However, when we print such a document, the word processor must be smart
> enough to print the text using black, not white. This is also supported by
> modern word processors. However, if the embedded object is treated solely as
> a picture, this can be hard to pull of for reasons I hope are obvious.
> 
> I believe the solution to this problem is to allow the equation "picture" (a
> vector graphic, not a bitmap) to draw and display text in a virtual "current
> text" color. In the "white text" scenario, the current text color is white
> when the equation is rendered to the screen but black when printed. This
> virtual color idea can also be described as late binding in graphics
> metafiles. Such a facility may have many other uses.
> 
> 10. Generating HTML/XML
> 
> In today's web-centric world, it is likely that many word processing
> documents will eventual be targeted for delivery as a web page. I believe
> that Gnome's philosophy is that the word processor's native document format
> be XML and, therefore, it might be directly displayable in a web browser
> with an appropriate style sheet. However, MathML and other specialized
> XML-based languages that might be the archival format used by embedded
> object are not currently understood by browsers. Current CSS and XSL styles
> are not powerful enough to format math, so this will have to be handled by
> various browser plug-in mechanisms. (Yes, I know that Mozilla handles MathML
> directly but it doesn't handle ChemML and name_your_favorite_ML, so the
> browser plug-in facilities are still required.)
> 
> It is important that the embedded object be able to support interfaces that
> allow it to participate in the HTML/XML generation process, both for
> archiving the container document and for conversion to web document form.

This is supported by the current set of bonobo interfaces: 
Bonobo::PersistStream::save
The  "in ContentType type" parameter can be used to ask the component 
to save its data in a specific mime format. You just need to ask it to 
save to xml :)
I think it is used in evolution right now for the HTML mail displayer.


my 2 cents. 

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 ? 

Mathieu

-- 
Mathieu Lacage <mathieu@eazel.com>