RE: embedded equation component manifesto (long)

[Paul Topping <PaulT mathtype com>]

Comments below with stuff removed for brevity.

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

Microsoft's Internet Explorer 5.5 now has "rendering behaviors" that deal
with some of the issues we're discussing here. These behavior objects return
a rectangle for layout purposes and a set of 4 border widths (top, left,
bottom, right) that can be used to inform the client app (i.e. the browser)
that it intends to draw so far outside its layout rectangle. It also returns
a value indicating whether the behavior object is drawing on top of other
content or below, whether it is opaque or transparent, and so on. Perhaps
this is what's needed here.

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

Basically, my comment was intended to help avoid a mistake made by Microsoft
in Word and shared by many other word processors. This is caused, IMHO, by
accepting a programmer's solution instead of a typographer's. The
implementer of a line layout algorithm has to deal with the situation of
multiple font sizes and graphic objects in a line that each take a varying
amount of vertical space. Given that, the algorithm must determine the
overall ascent and descent of the line of text. The obvious, but wrong,
solution to this problem is to simply use the max ascent and descent. This
leads to inconsistent line spacing in a paragraph.

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

I think the font info interface is better.

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

Nothing at all that I know of.

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

Not so. It is very common for equations to have natural language phrases in
them. In fact, in high school texts, phrases can substitute for variables
(area = length * width). I would agree, though, that solving this problem
for equations is lower priority than other stuff here. Probably really high
priority for embedded spreadsheets.

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

To give a specific example, Microsoft Word stores each embedded object
within the document using OLE/COM structured storage. Each equation is a
"directory" (storage) containing several "files" (streams) for its own
native format, a metafile, etc. Their implementation of COM storage is such
that it uses an allocation scheme (DOS floppy format, actually) involving
128-byte blocks. So, even though an equation consisting of alpha + beta
might need only a few bytes, its impact on the document is orders of
magnitude greater.

Although I don't expect your programmers to have this particular problem
(they might), I look at it as the result of programmers making decisions
using a mental model where a document contains an average of 2 objects
(spreadsheet tables, pictures) per page, each of which takes 30 kb of
storage, rather than 40 objects per page (equations), each of which takes
200 bytes on average.

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

I won't have time to design the actual interfaces. My intent was to alert
the group to the issues. Personally, I'd love to work on this, but I have a
company to run.

> Best wishes,
> Miguel.
>