[cgmo-webcgm] ISSUE: how precise should gOE(text) be? (revised)

[Lofton Henderson <lofton@rockynet.com>]

[...adding Dave to distribution...]

ISSUE:  how precise should gOE(text) be?

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 recommending 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 application of all CGM attributes and text-related Style 
Properties, and derive the minimal containing axis-aligned rectangle.

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

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 the 
perverse values 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 researching the history of gOE(text) for me, 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".

That's a nice perspective, and it's a computation that each *generator* is 
probably aware of.

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

FURTHER DISCUSSION:  #1 gives an accurate (close-fitting) answer in all 
cases, and more or less ignores the metafile's RT parallelogram for odd 
cases (e.g., 'basic' with *lots* of empty space).  #1 is efficient for the 
usual cases (boxed-all and box-cap) -- it can directly derive from the RT 
parallelogram.  #2 would attempt at efficiency in all cases, by deriving 
from , but in some odd cases would not give a close-fitting result.

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

I like Dave's perspective as an informative note that helps give 
perspective on what the right answer is.  (But I'm having trouble working 
it into *normative* text, as typical viewers do not contain generator logic 
(altho' editors do).

### end ###