Re: embedded equation component manifesto (long)

[Miguel de Icaza <miguel helixcode com>]

Hello Paul,

   Your message is very interesting.  I am vgery thankful for the
detailed explanation of fine problems involved into rendering properly
embedded equations.

   Your post establishes a good foundation for actually discussing
interfaces and extensions to Bonobo, which is something we should
discuss now.   

> 1. Baseline Alignment

Agreed.

> 2. Side Bearings

Agreed as well.  Although this gets tricky to implement with
traditional rectangle-based embedding of components.  

I am convinced that an equation editor would have to use the
canvas-based approach so the proper typographical rendering can be
done.  Otherwise we will be limited by the rectangle rendering
scheme.  Or we support an extra embedding method in Bonobo that would
share a Pixmap/Window acreoss processes. 

> 3. "Auto" Line Spacing

If I do understand this correctly, the problem is that the bounding
box might contain more space above and below that does not let the
word processor make the right decision about how much space is being
used by the embedded component.

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

We do have such interface (the Bonobo::ClientSite), but we are not
exposing any of this information currently.  Maybe we could have a
PropertyBag attached to the ClientSite and standarize on the
properties that would be available there.

This would give access to the document state, but I am not sure this
would be the proper way of accessing the font at the point of the
insertion of the equation.

For instance, if I select a piece of text and inside this piece of
text there is an equation, I want the equation fonts to change
accordingly, and it seems like this is a property that should be set
manually.  Either by QIing for a font information interface.  In such
case, we might as well always use this instead of having a PropetyBag
on the ClientSite.

> Both of these require quite complicated size negotiation between the
> container and the embedded equation object.

I agree.  We have not done a lot of work in this area at all.  For
instance, components currently do not have any sort of interfaces that
would support page breaking.  This issue was initially raised by Owen
Taylor, and I have not worked on this, nor given any thought on how to
solve this problem.

This problem was originally raised regarding the embedding of objects
that are bigger than 32k pixels. 

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

Agreed.	 Is anything like this specified in the Microsoft world?

Although it is something we should support, I think that for the
specific case of an equation editor it might be wierd to support the
fetch-word-for-spelling-purposes interface defined.  The contents are
barely words that need to be spelled, or will be more noise than
anything else.

> 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 could not understand what would cause the performance problem.
Could you elaborate?

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

Yes, it makes sense.

So what set of interfaces would you suggest we have?  I would love to
hear your input.  If this is still an open topic, we could cook some
interfaces based in your input.

Best wishes,
Miguel.