draft clarification for getObjectExtent & text

[Lofton Henderson <lofton@rockynet.com>]

All --

Please review and comment...

Per the 4-mar telecon agreement about the principles, here is draft 
language to clarify the contribution of text elements to the object extent 
calculation.

Reference:
http://www.w3.org/Graphics/WebCGM/drafts/current-editor-21/WebCGM21-DOM.html#getObjectExtent

Replace the 3rd paragraph:

[[[
>The contribution of text elements to the object extent is conceptually 
>calculated from the containing parallellogram of the displayed text, 
>defined as follows. The length of the side in the text-up direction is the 
>bottomline-to-topline distance of the font, after computation of the 
>effective font size that reflects all text attributes, the height of the 
>Restricted Text box, the Restricted Text Type, and the Style Properties 
>text-size and text-font. The length of the side in the text-baseline 
>direction is the length of the restricted text box if the entire 
>Restricted Text element is contained within the object, or the sum of the 
>glyph widths if only an Append Text element is within the object.
]]]

with:

===== start replacement text =====
The contribution of text elements to the object extent of a Restricted Text 
element is calculated as follows.  First, an effective font size is derived 
that reflects all applicable CGM text attributes for the text string in 
question, as well as the Style Properties text-size and text-font, plus the 
"effective Restricted Text parallelogram" and the Restricted Text 
Type.  The "effective Restricted Text parallelogram" is defined to be the 
Restricted Text parallelogram as possibly altered by the @@text-size Style 
Property@@.  Then, the text string can be laid out glyph-by-glyph at this 
effective font size according to all applicable CGM attributes and 
applicable Style Properties, as defined in CGM:1999 section 6.7.3.

For the purposes of the object extent (bounding box) calculation, each 
glyph is treated as a separate graphics element.  The calculations assume 
that all glyphs occupy their full glyph cell.  In particular, the 
calculations assume that each glyph extends vertically from the bottom-line 
to the top-line of the font (see Figure 11, CGM:1999 section 6.7.3.2) -- 
i.e., the vertical extent of each glyph includes the full ascent and 
descent values for the font, regardless of whether the particular glyph 
actually has ascenders and/or descenders.

The object extent of the text string is he minimal axis-aligned bounding 
rectangle that contains all the glyph cells.

In practice, this calculation can usually be simplified considerably.  By 
far the most commonly occurring WebCGM-compliant use cases involve fonts 
with left-to-right text progression and Restricted Text Type values 
'box-cap' or 'box-all'.  For the 'boxed-all' case, the sum of the glyph 
boxes is simply the Restricted Text parallelogram, and the object extent is 
simply the minimal axis-aligned rectangle that contains said 
parallelogram.  'Boxed-cap' is equally straightforward, involving a simple 
arithmetic adjustment to the Restricted Text parallelogram.

Note:  Although WebCGM requires the use of RESTRICTED TEXT and prohibits 
use of TEXT, viewers may encounter legacy CGM content that uses TEXT.  It 
is recommended that DOM implementations of getObjectExtent should be able 
to correctly handle such metafiles, according to the calculations specified 
here.

Note 2:  An informative alternative perspective about the text contribution 
to the object extent might be helpful:  the sum of the glyph boxes is 
equivalent to the Restricted Text parallelogram that would result if a 
WebCGM generator were writing the text string with 'boxed-all' Restricted 
Text Type.
===== end replacement text =====

Regards,
-Lofton.