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

RE: More on getObjectExtent() -- Raster

From: Bezaire, Benoit <bbezaire@ptc.com>
Date: Wed, 3 Dec 2008 12:29:01 -0500
Message-ID: <B0D4682CF6F84041AC7C42AA6E9E81330C6EF8D8@HQ-MAIL3.ptcnet.ptc.com>
To: "WebCGM WG" <public-webcgm-wg@w3.org>
Yes it is okay to break this thread into pieces.
About: You [LH] had to go back to CGM:1999 to find the answer. Somehow I
didn't see that as a problem...
In general, I don't see it as a problem to go back to CGM:1999 to find
some answers; however, unlike most specifications, WebCGM 2.1 does not
offer links into CGM:1999. Other specifications (say XHTML, SVG) will
link to CSS and SMIL etc... It's easy to find answers. With WebCGM,
unless you've dealt with this for 10+ years, it's not that easy. For
example, any newbie would look for 'raster' or 'bitmap', not 'tile
array' or 'cell array'. Providing links to CGM:1999 certainly wouldn't
hurt in my opinion.


From: public-webcgm-wg-request@w3.org
[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Lofton Henderson
Sent: Tuesday, December 02, 2008 6:23 PM
Subject: RE: More on getObjectExtent() -- Raster

Hi Benoit --

Thanks for the comments -- it's an implementor's perspective that I'm

Does it seem okay to break this thread into pieces?  First about raster

>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?)


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
	- what's the extent of a raster?
	- what's the extent of a bezier curve? (we've now clarified that
	- 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
	- "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

	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

	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?


		From: public-webcgm-wg-request@w3.org
[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Weidenbrueck,
		Sent: Sunday, November 30, 2008 12:50 PM
		To: Lofton Henderson; WebCGM WG
		Subject: RE: More on getObjectExtent()
		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
		- transformations (they do have an impact)

		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
		At 09:45 AM 11/19/2008 -0700, Lofton Henderson wrote:

			At 08:32 AM 11/19/2008 -0800, David Cruikshank

				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 <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
				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
http://docs.oasis-open.org/webcgm/v2.1/cs01/WebCGM21-DOM.html#L5095 .)
				(Shall I just add this to fix to the
clarification in DoC #3:
e3  ?)


				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
				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 Wednesday, 3 December 2008 17:30:02 UTC

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