RE: More on getObjectExtent() -- Raster

Actually, I was hoping that someone might look at CGM:1999 and notice one 
small loophole in my claim of "clear enough to implement".

Cell Array looks dead obvious (ignoring the separate question of 
transparency) -- there is a simple well-defined rectangle within which the 
cell array is tightly bounded.

Tile Array has a wrinkle.  Because of possible artifacts introduced by 
tiling, the actual image might not fully occupy the tile array 
rectangle.  Therefore there may be an undefined border around the actual 
image.  See the last 4 parameters in 7.2.16.  To me, it seemed clear that 
the rectangle we want is the rectangle defined by those 4 parameters.  The 
"border" is purely an artifact of the tiling process, i.e., it only exists 
because it might not be possible to put the image exactly into a tiled 
array of an integral number of equally sized tiles.

Anyone disagree?

Then proposal:  add a couple sentences to gOE identifying the rectangle of 
Cell Array and the proper rectangle of Tile Array as being their "locus", 
mostly by reference to CGM:1999 (i.e., be as brief as possible in WebCGM 
gOE() and reference the definitive bits in CGM:1999).

-Lofton.


At 04:22 PM 12/2/2008 -0700, Lofton Henderson wrote:
>Hi Benoit --
>
>Thanks for the comments -- it's an implementor's perspective that I'm missing.
>
>Does it seem okay to break this thread into pieces?  First about raster 
>comments.
>
> From below: "You [LH] had to go back to CGM:1999 to find the 
> answer."  Somehow I didn't see that as a problem.  I actually knew that 
> Cell Array was defined as a subdivision within a box, and thought the 
> same was true of Tile Array/Tile.  But before asserting that 
> authoritatively, I wanted to verify that it was accurate.  Which took me 
> about 5 minutes -- it seemed obvious once I looked it up.
>
>[Reference:  from CGM:1999's TOC:   6.6.5, 7.2.16, 7.6.9, 7.6.28/29]
>
>So I'm curious:  would you have to look at CGM:1999 to decide what to do 
>about other (than raster) Graphical Primitive elements, like Circular Arc 
>Center Close or Circular Arc 3 Point Close?  I'm unsure how far we need to 
>go here -- to me, CACC and CA3PC graphical primitives do not seem any more 
>or less obvious than Cell Array and Tile Array graphical primitives.  (But 
>then again ... I'm not implementing.)
>
>That notwithstanding... Would you (or anyone) like to propose some words 
>about Cell Array and Tile Array for 5.7.6?
>
>More later about the other specific questions (below).
>
>But maybe a more global question:  ought we to put in a big table, or 
>maybe a new normative subsection, with a row about gOE calculation for 
>each of WebCGM's 20+ graphical primitives, as well as rows for controls 
>like clipping and suchlike?  Or will it suffice to just chunk in selected 
>additional paragraphs in the gOE section?
>
>(How much more is implied by the "...etc..." at the end of the 
>list?  I.e., what is the definitive list of things that need to be 
>addressed in WebCGM gOE() text?)
>
>-Lofton.
>
>At 10:58 AM 12/2/2008 -0500, Bezaire, Benoit wrote:
>>[...]
>>If company ABC were to hire a computer science new grad (or even a senior 
>>software developer) to implement parts of WebCGM 2.1, he would read the 
>>getObjectExtent wording and say 'what the'? He would read it again and 
>>still say 'what the'? Then he walk to his manager's office and ask:
>>
>>- what's the extent of a raster?
>>- what's the extent of a bezier curve? (we've now clarified that one)
>>- what's the extent of left to right string of text?
>>- what's the extent of top down string of text?
>>- how does this work with clipping?
>>- etc...
>>
>>Regarding rasters. My point was that 'raster', 'image', 'cell array', 
>>'tile array' is not to be found in the getObjectExtent() wording. You had 
>>to go back to CGM:1999 to find the answer.
>>
>>Regarding text. What I think is meant is that the font family ascent and 
>>descent define the 'length of the side in the text-up direction'. 
>>Correct? Another question that comes to mind immediately after reading 
>>the wording is how to get the extent for non Restricted Text box.
>>Another puzzling thing for me is that we say 'bottomline-to-topline 
>>distance of the font', we don't say anything about the used glyphs.
>>
>>So say the following three strings have the same text attributes:
>>- "abc" (goes above x-height)
>>- "wagon" (goes below baseline)
>>- "were once common" (uses only x-height, no descent, nothing above 
>>x-height or cap height)
>>
>>According to the wording, they would all have the same 'height'. If those 
>>strings were treated as path, they would yield different heights.
>>
>>Benoit.
>>
>>
>>----------
>>From: public-webcgm-wg-request@w3.org 
>>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
>>Sent: Monday, December 01, 2008 5:31 PM
>>To: WebCGM WG
>>Subject: RE: More on getObjectExtent()
>>
>>At 09:49 AM 12/1/2008 -0500, Bezaire, Benoit wrote:
>>>Hi Dieter,
>>>
>>>I think most of them (except rasters) have been addressed.
>>
>>Please clarify what might be missing here.  Per my previous message, I 
>>did a quick read about Cell Array and Tile Array in CGM:1999.  It seems 
>>clear what is the extent (ignoring transparency/visibility controls for 
>>the moment).  But maybe I'm missing something -- after all, I haven't 
>>tried to implement gOE().
>>
>>>However, I do not think the group agreed to treat text as path.
>>
>>Just to be sure I'm understanding -- what exactly does "treat text as 
>>path" mean?  Does it mean the minimal containing box of all the 
>>strokes/areas that are used to actually render the string?
>>
>>The 2nd paragraph of the gOE description in 5.7.6 seems pretty 
>>definitive, though maybe different from "treat text as path".  It also 
>>seems like a lot cheaper computation.  So two questions:
>>
>>1.) does the present 5.7.6 gOE approach have some fundamental problem 
>>that makes it unsuitable?
>>2.) if that present approach is suitable, then:  are there some holes or 
>>defects in the particular details as they are written?
>>
>>Regards,
>>-Lofton.
>>
>>>
>>>----------
>>>From: public-webcgm-wg-request@w3.org 
>>>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Weidenbrueck, Dieter
>>>Sent: Sunday, November 30, 2008 12:50 PM
>>>To: Lofton Henderson; WebCGM WG
>>>Subject: RE: More on getObjectExtent()
>>>
>>>Lofton,
>>>
>>>good start. Do we need to add something about
>>>- raster images
>>>- text (should be treated as paths)
>>>- visibility/transparency (do they have an impact or not)
>>>- transformations (they do have an impact)
>>>
>>>Opinions?
>>>
>>>Regards,
>>>dieter
>>>
>>>
>>>----------
>>>From: public-webcgm-wg-request@w3.org 
>>>[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
>>>Sent: Sonntag, 30. November 2008 17:26
>>>To: WebCGM WG
>>>Subject: Re: More on getObjectExtent()
>>>
>>>Since not everyone is satisfied with the simple fix of "s/abstract 
>>>locus/locus/" in 5.7.6, I'll make a proposal to close the "locus" 
>>>issue:  delete the word "abstract" and link "locus" to a glossary entry.
>>>
>>>Here is a first draft proposal:
>>>
>>>[[[
>>>locus --
>>>The Oxford dictionary defines locus as:  "Curve formed by all points 
>>>satisfying particular equation of relation between coordinates, or by 
>>>point, line, or surface, moving according to mathematically defined 
>>>conditions."  In the WebCGM specification, locus refers to the set of 
>>>points that comprise the path or shape of a Graphical Primitive element, 
>>>or in the appropriate context, the combined shapes or paths collectively 
>>>of all of the Graphical Primitive elements in an Application Structure 
>>>(APS).  I.e., the locus of an APS comprises the combined loci of all of 
>>>the graphical primitives in the APS.  Locus does not include defining 
>>>data that are not part of the shape or path of the graphical primitive, 
>>>such as control points of Bezier primitives, or the center point of a 
>>>Circular Arc Center primitive.
>>>]]]
>>>
>>>Question 1:  Are people okay with the solution of adding a definition to 
>>>the Glossary?
>>>
>>>Question 2:  Suggestions for improvement of the definition?
>>>
>>>-Lofton.
>>>
>>>
>>>
>>>At 09:45 AM 11/19/2008 -0700, Lofton Henderson wrote:
>>>>Dave,
>>>>
>>>>At 08:32 AM 11/19/2008 -0800, David Cruikshank wrote:
>>>>>I would agree with dropping "abstract".  Locus is a perfectly valid 
>>>>>term to define the path of the primitive.
>>>>>
>>>>>Probably ought to capture it somewhere to document the decision.
>>>>
>>>>Just to clarify that last sentence -- you mean that you support the 
>>>>issue processing proposal to roll it into Issue3 in the DoC (see URI below)?
>>>>
>>>>Thanks,
>>>>-Lofton.
>>>>
>>>>
>>>>>On Wed, Nov 19, 2008 at 8:04 AM, Lofton Henderson 
>>>>><<mailto:lofton@rockynet.com>lofton@rockynet.com> wrote:
>>>>>>At 09:26 AM 11/19/2008 -0500, Bezaire, Benoit wrote:
>>>>>>>I think the wording should be revised.
>>>>>>
>>>>>>Fair enough.
>>>>>>
>>>>>>
>>>>>>>Even Google doesn't come up with anything meaning full for "Abstract 
>>>>>>>locus".
>>>>>>
>>>>>>However, it does give lots of hits for a search like "definition of 
>>>>>>mathematical locus".  And we use "locus" repeatedly, in the proper 
>>>>>>sense, in the profile (Ch.6) -- i.e., "locus" is a pretty common term 
>>>>>>in  and has been used in WebCGM, for example, since 1999.  So it is 
>>>>>>my hastily-invented modifier "abstract" that is problematic.
>>>>>>
>>>>>>Actually, I think a good solution would be to drop the word 
>>>>>>"abstract".  The next sentence after its occurrence fully explains 
>>>>>>what "abstract" was meant to convey.  (And we have agreed to clarify 
>>>>>>that sentence.)
>>>>>>
>>>>>>(See the getObjectExtent definition in 5.7.6:
>>>>>><http://docs.oasis-open.org/webcgm/v2.1/cs01/WebCGM21-DOM.html#L5095>http://docs.oasis-open.org/webcgm/v2.1/cs01/WebCGM21-DOM.html#L5095 
>>>>>>.)
>>>>>>
>>>>>>Okay?
>>>>>>
>>>>>>(Shall I just add this to fix to the clarification in DoC #3:
>>>>>><http://www.w3.org/Graphics/WebCGM/WG/2008/WebCGM21-LC-comments.html#Issue3>http://www.w3.org/Graphics/WebCGM/WG/2008/WebCGM21-LC-comments.html#Issue3 
>>>>>>?)
>>>>>>
>>>>>>-Lofton.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>----------
>>>>>>>From: Lofton Henderson 
>>>>>>>[<mailto:lofton@rockynet.com>mailto:lofton@rockynet.com]
>>>>>>>Sent: Tuesday, November 18, 2008 6:52 PM
>>>>>>>
>>>>>>>To: Bezaire, Benoit; WebCGM WG
>>>>>>>Subject: Re: More on getObjectExtent()
>>>>>>>
>>>>>>>At 01:52 PM 11/18/2008 -0500, Bezaire, Benoit wrote:
>>>>>>>>The wording says "[...] The bounding box calculation is based on 
>>>>>>>>the abstract locus of the primitives within the APS."
>>>>>>>>What does 'abstract locus' mean?
>>>>>>>
>>>>>>>The locus is the set of points comprising the drawn primitive (it's 
>>>>>>>a term I dredged up from my memory of some old math courses -- I 
>>>>>>>hope I got it right).  "Abstract locus" means that things like line 
>>>>>>>width are not included, but rather only the point positions as if 
>>>>>>>the item were drawn with an abstract, infinitely fine pen.
>>>>>>>
>>>>>>>>
>>>>>>>>I'd like to know if getObjectExtent() returns a tight bounding box 
>>>>>>>>on a given APS. i.e., given a polybezier, are control points part 
>>>>>>>>of the bounding box calculations or not?
>>>>>>>
>>>>>>>No.  The control points are part of the defining data, but not part 
>>>>>>>of the drawn primitive.
>>>>>>>
>>>>>>>-Lofton.