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

[Lofton Henderson <lofton@rockynet.com>]

Forwarding a comment of Dave's...

>Date: Sat, 7 Mar 2009 12:15:18 -0800
>Subject: Re: [cgmo-webcgm] draft clarification for getObjectExtent & text
>From: David Cruikshank <dvdcruikshank@gmail.com>
>To: Lofton Henderson <lofton@rockynet.com>
>
>Thanks Lofton,
>
>The 3rd para in the new text seems to adequately handle the two test cases 
>in the attached CGM.
>
>Dave
>
>
>On Sat, Mar 7, 2009 at 11:51 AM, Lofton Henderson 
><<mailto:lofton@rockynet.com>lofton@rockynet.com> wrote:
>>Dave --
>>
>>Meant to copy you.  I wanted to expose this to the bigger audience of the 
>>TC before putting it in the current-editor draft for WG approval.
>>
>>Any comments?
>>
>>-Lofton.
>>
>>>Date: Sat, 07 Mar 2009 12:38:17 -0700
>>>To: 
>>><mailto:cgmo-webcgm@lists.oasis-open.org>cgmo-webcgm@lists.oasis-open.org
>>>From: Lofton Henderson <<mailto:lofton@rockynet.com>lofton@rockynet.com>
>>>Subject: [cgmo-webcgm] draft clarification for getObjectExtent & text
>>>
>>>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>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>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>Content-Type: application/octet-stream; name="Text_On_Path_cases.cgm"
>Content-Disposition: attachment; filename="Text_On_Path_cases.cgm"
>X-Attachment-Id: f_fs0qipch0

Text_On_Path_cases.cgm