W3C home > Mailing lists > Public > public-webcgm-wg@w3.org > December 2008

Re: More on getObjectExtent()

From: Lofton Henderson <lofton@rockynet.com>
Date: Mon, 01 Dec 2008 15:14:01 -0700
Message-Id: <>
To: "WebCGM WG" <public-webcgm-wg@w3.org>
Getting back to email connection...

At 02:36 PM 11/30/2008 -0800, David Cruikshank wrote:
>As far as information for a glossary entry, I think what Lofton has 
>suggested is good.
>The answers to Dieter's questions should not be in the glossary, but 
>should be in the discussion in 5.7.6, where it describes getObjectExtent.

I agree.

>-raster images:  To me this is implied as the extent of the raster 
>image...is more clarification needed?

I'm not sure what more is needed.  I took a quick look at both the Cell 
Array and Tile Array text in CGM:1999, and it strikes me as clear enough to 
implement.  If someone thinks it not clear enough to implement, please 
specify in some detail what more we need, with reference to the CGM:1999 text.

>-text: already covered in 5.7.6

I agree.  There is a whole paragraph describing it, which we drafted and 
approved some time ago.  It seems clear to me.

>-visibility/transparency: already addressed in 5.7.6, but possibly not the 
>right answer - "not affected by ... APS attributes or style properties"

Don't forget that we have already resolved to clarify that 
statement:  extent is affected by text-related SP, but is NOT affected by 
non-text SP or ApsAttr.  Therefore we have (in CS) approved that it is not 
affected by 'visibility'.  It would seem consistent that transparency -- 
whether alpha transparency or transparent cell color -- should have no 

>Maybe visibility should affect the result?  Didn't we discuss this already?

I think we did, and as I recall the conclusion was "no".

If someone wants to change that conclusion ... let's raise it as a new 
issue (it goes beyond clarification).

>transformations: already covered in 5.7.6



>On Sun, Nov 30, 2008 at 9:50 AM, Weidenbrueck, Dieter 
><<mailto:dweidenbrueck@ptc.com>dweidenbrueck@ptc.com> wrote:
>>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)
>>[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?
>>At 09:45 AM 11/19/2008 -0700, Lofton Henderson wrote:
>>>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)?
>>>>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 
>>>>>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:
>>>>>(Shall I just add this to fix to the clarification in DoC #3:
>>>>>>From: Lofton Henderson 
>>>>>>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.
Received on Monday, 1 December 2008 22:15:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:23:41 UTC