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