Luke's current logic implements the following new character-level property
values:
text-position semantics
------------- ---------
normal (what we usually do, the default)
superscript (make it smaller and move it up high)
subscript (make it smaller and move it down lower)
None of these currently change the line height calculation, because of the
way the shrinking and moving interact.
This is the more common notion of "sub/sup", but some older word processors
also had a notion of "sub/super-script by" which *just* shifts the baseline,
and does *not* affect the font size. (I believe this corresponds to the RTF
/up and /dn codes.)
In the future, for the sake of completeness we may also want to add these
orthogonal "shifting" semantics to the text-position property. These would
be expressed by a signed dimensioned value:
text-position semantics
------------- ---------
+3pt move the baseline up three points
-.25in move the baseline down half an inch
By definition, these *are* likely to affect the calculated line-height,
because by themselves they don't ever shrink the font size.
Moreover, in the same way that strikethrough and underline share the same
property, both semantics could be expressed at once:
text-position semantics
------------- ---------
superscript +3pt shrink and move up, then shift up an additional 3pts
subscript -.25in shrink and move down, then move down even farther
Adding this extra logic to the formatter should be pretty straightforward,
and it might be worth doing now so that we can reliably import / export RTF
and Word documents which use either or both variants.
However, it's not clear how much additional GUI work to do for this now. I
personally am not in the mood to completely replace the font dialogs before
1.0, but when we do, Luke's existing semantics would go as additional
checkboxes on the first tab, and these additional semantics would go into a
combo/spinner pair on a later tab.
Paul