Re: [cgmo-webcgm] draft clarification for getObjectExtent & text

[Lofton Henderson <lofton@rockynet.com>]

Actually I have one comment.  Dave's perspective comparing to generator 
behavior (Note 2) helped me to lay out some precise language.  But having 
done that now, I'm wondering if briefer is better, and reduces any risk of 
generating confusion?  I.e., should we drop Note 2?

-Lofton.


At 12:38 PM 3/7/2009 -0700, Lofton Henderson wrote:
>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.
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>