RE: More on getObjectExtent()

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 19:25:15 UTC