[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [cgmo-webcgm] ISSUE: how precise should gOE(text) be? (revised)
[...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 ###
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]