2nd preliminary RE: More on getObjectExtent()

Hi Benoit,

One more preliminary clarification.

You wrote "...how to get the extent for non Restricted Text box."  Unless 
I'm misunderstanding what you said, this is answered by the constraint that 
only RESTRICTED TEXT is allowed in WebCGM.  The regular CGM:1999 TEXT 
primitive is not.

So if I have understood correctly, can we also declare this a non-issue 
when I break out the real issues?

Regards,
-Lofton.

At 12:24 PM 2/4/2009 -0700, Lofton Henderson wrote:

>Hi Benoit,
>
>I'm working on breaking out and dealing with gOE() issues about text 
>(probably in the TC for the more complex questions).
>
>Since you raised these questions originally here in the WG, I'd like to 
>check on one preliminary understanding before proceeding...
>
>Ref:  http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Dec/0005.html
>
>I would like to dispose of one overriding question, however.  At the end 
>of that reference you say:  "According to the wording, they would all have 
>the same 'height'. If those strings were treated as path, they would yield 
>different heights."
>
>I know that we have previously resolved (we have some history in the TC, 
>and will be researching it) that we want to *avoid* the complexity of 
>treating text as path.  Therefore our rules about bottomline-to-topline, 
>etc.  Although the specifications are a little different between WebCGM 
>and SVG, the latter is similar to WebCGM in that it avoids the expense of 
>text-as-path calculations in figuring the bounding box [1] (see "For text 
>content elements...").
>
>Can we agree that it is a non-issue, i.e., already resolved, that the 
>WebCGM specification of gOE() for text elements will NOT treat text as 
>path for the gOE calculation?  (Then we can sort out exactly how it does that.)
>
>[1] http://www.w3.org/TR/SVGMobile12/single-page.html#coords-BoundingBox
>[[
>>For text content elements, for the purposes of the bounding box
>>calculation, each glyph must be treated as a separate graphics element.
>>The calculations must assume that all glyphs occupy the full glyph cell.
>>For example, for horizontal text, the calculations must assume that each
>>glyph extends vertically to the full ascent and descent values for the
>>font. An exception to this is the 'textArea', which uses that element's
>>geometry for the bounding box calculation.
>]]
>
>Regards,
>-Lofton.
>
>
>
>

Received on Wednesday, 4 February 2009 21:24:08 UTC