ISSUE: how precise should gOE(text) be?

[Lofton Henderson <lofton@rockynet.com>]

ISSUE:  how precise should we be for getObjectExtent(text)?

Refs:
[1] http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Dec/0005.html
[2] http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Feb/0004.html
[3] http://www.w3.org/Graphics/WebCGM/WG/2009/02/11-webcgm-minutes.html
[4] 
http://www.w3.org/TR/2009/WD-webcgm21-20090130/WebCGM21-DOM.html#getObjectExtent

DISCUSSION:  The current description [4] describes a method that relies 
heavily on the Restricted Text box (parallelogram).  Comments have asked 
for more detail ([1], [2]).  We have agreed [3] to provide such, and also 
to include an informative note about how to do gOE on legacy content that 
uses TEXT instead of RESTRICTED TEXT.  That legacy case is basically like 
the SVG definition:  add up all the glyph boxes (bottom-line to top-line, 
regardless of the vertical extent of the actual glyph within), as they 
exist after all CGM attributes and text-related Style Properties are 
applied, and derive the minimal containing axis-aligned rectangle.

RT with 'boxed-all' is easy (ditto boxed-cap), and yields the same 
calculation as glyph-by-glyph:  it is the RT parallelogram (or an easily 
computed variant in the 'height' direction).  This is *by far* the most 
common actual real-world use case.

But as I have worked on new wording, I have come up with a 
question.  Restricted Text Type (RTT) still allows *all* legal CGM:1999 
values:  basic, boxed-cap, boxed-all, isotropic-cap, isotropic-all, 
justified.  See Figure 20, CGM:1999 section 6.7.3.2.  We *never* see these 
in practice in WebCGM content, but their occurrence (e.g., 'basic') could 
lead to an RT box that is almost unrelated to the actual text extent, in 
perverse cases.  (Whereas 'boxed-all' RT box is a reasonable and highly 
efficient approximation.)

In off-line dialog about researching the history of gOE(text), Dave made 
this comment:

At 02:43 PM 2/4/2009 -0800, David Cruikshank wrote:
>Based on the decision we made for the wording in WebCGM 2.1, I think that 
>the answer to how to implement gOE for text strings is that is is the same 
>calculation a generator would use to create the RT Box for RT Type "boxed-all".

This nicely handles the boxed-all and boxed-cap cases, and lets viewers use 
the efficiencies of not adding up glyph boxes (i.e., just derive from the 
dimensions of the RT parallelogram).  What do we want to do about the odd 
cases (that we never see in real-world practice)?

OPTIONS:
1.) revert to accumulating glyph boxes, after the viewer has laid out the 
text per all attributes and SPs (these cases are never seen in practice, so 
who cares if they are efficient).
2.) try to preserve some efficient use of the parameters of RT and RTT 
(would likely have to be case-by-case on RTT).

RECOMMENDATION:
I think I favor #1 -- make it efficient and accurate for the users of the 
common boxed-cap and boxed-all.  Let users of odd-ball cases (odd RTT 
values), and legacy non-RT metafiles go through the glyph accumulation 
(more expensive) calculation.  (But still much less expensive than 
text-as-path, which we have agreed is NOT the desired calculation.)
### end ###