[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Descriptive section about geometric transform
All -- For the several people who are drafting bits that relate to or depend on geometric transform... Stuart's message got me thinking that I should clarify something that we have said a few times but not actually written down. At 10:54 AM 2/29/2008 -0800, Galt, Stuart A wrote: >[...] >Yes, I agree and I think I heard in the telecon that we would want to >use >the transformed coordinates. I think that they would be similar to the >the actual value for style properties? I assume that "actual values" refers to this: http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-DOM.html#webcgm_5_4_1_4 We should be careful about comparing transform-related stuff to the "normal" inheritance concepts of Style Properties -- definitely should not do it in draft text, lest it confuse the distinction between transform and the other Style Properties. We have labelled geometric transform as a Style Property because it causes transient visual changes. But it does not share the SP inheritance model at all, as we have agreed. We have also agree (but maybe not documented) that we are going to write a new subsection of 5.4 describing the accumulation/composition of transforms in the object tree, and will be sure to indicate applicability of 5.4.1 - 5.4.3 is "...except geometric transform (see 5.4.4)." People who are drafting transform-related text should assume that there will be something like a new section 5.4.4 about geometric transform, that will explain the model of composition of transforms in some detail. Unless someone else wants to take it, I guess I'll volunteer for a first cut. -Lofton. > > > > -----Original Message----- > > From: Bezaire, Benoit [mailto:bbezaire@ptc.com] > > Sent: Tuesday, February 26, 2008 5:30 AM > > To: cgmo-webcgm@lists.oasis-open.org > > Subject: RE: [cgmo-webcgm] getAppStructureExtent() was > > getObjectExtent() > > > > If the main use case is to be able to align objects, then it > > would seem like getAppStructureExtent() needs to take into > > account the current transform. Would you agree? > > > > I think the same would be true for the zoom example; although > > we haven't seen any zoom API proposal from the group so far. > > > > The fact that it is two corners troubles me... it makes the > > script writer's job more difficult. But CGM's can be Y up and > > Y down, right? So x, y, width and height wouldn't be better I > > think :-( > > > > Ben > > > > -----Original Message----- > > From: Galt, Stuart A [mailto:stuart.a.galt@boeing.com] > > Sent: Monday, February 25, 2008 7:36 PM > > To: Lofton Henderson; cgmo-webcgm@lists.oasis-open.org > > Subject: RE: [cgmo-webcgm] getAppStructureExtent() was > > getObjectExtent() > > > > Hello, > > > > To answer Lofton's question: > > I think that we should use the same points as viewcontext (like you > > suggested) I just used the min/max points because that is > > what it said in the AI list - poor excuse but it is the one I > > am going to use. > > > > I think that the original use case was to be able align or > > move an APS relative to another one. (Being able to put a > > table_leg at the edge of the table_top object)? > > > > Another use that I thought of might be to be able to zoom > > into an APS but instead of making it full screen I want it to > > be only 90% of the available viewport. > > > > I don't think that it was intended to take line width or > > regions into account. > > > > > > -- > > Stuart Galt > > SGML Resource Group > > stuart.a.galt@boeing.com > > (206) 544-3656 > > > > > > > > > -----Original Message----- > > > From: Lofton Henderson [mailto:lofton@rockynet.com] > > > Sent: Monday, February 25, 2008 11:12 AM > > > To: Galt, Stuart A; cgmo-webcgm@lists.oasis-open.org > > > Subject: Re: [cgmo-webcgm] getAppStructureExtent() was > > > getObjectExtent() > > > > > > Stuart, All -- > > > > > > A question comes up. Which bounding box? Do you mean: > > > > > > 1.) the BB of the coordinates of the APS's graphical primitive > > > elements, as written in the metafile itself? > > > 2.) or, the effective BB, which would reflect a non-trival CTM > > > (current transformation matrix)? > > > 3.) or, something else (e.g., 'region' factored in)? > > > 4.) or, should it be parameter selectable (#1 or #2 or ...)? > > > > > > Related question: are things like line-width accounted for > > in the BB, > > > > > or not? > > > > > > (Does anyone recall our original use case(s)? That might help to > > > answer the questions.) > > > > > > -Lofton. > > > > > > At 10:45 AM 2/23/2008 -0700, Lofton Henderson wrote: > > > >Stuart -- > > > > > > > >Good job, especially the completeness by looking at every > > > section for > > > >needed changes. > > > > > > > >One small nit... > > > > > > > >At 04:09 PM 2/22/2008 -0800, Galt, Stuart A wrote: > > > >>Markups for getAppStructureExtent() > > > >> > > > >>Chapter 1 - no changes > > > >>Chapter 2 - no changes > > > >>Chapter 3 - no changes > > > >>Chapter 4 - no changes > > > >> > > > >>In 5.7.6 add to the IDL list > > > >> > > > >>WebCGMString getAppStructureExtent(); > > > >> > > > >>Add to the method descriptions: > > > >> > > > >>getAppStructureExtent() > > > >> Retrieves the bounding box rectangle of the > > > graphic elements > > > >>within an APS. The rectangle is defined the two corner points. > > > >>Parameters > > > >> None > > > >>Return Value > > > >> WebCGMString; the bounding rectangle min and max > > > pairs stored > > > >>in a string, or the empty string if the APS contains no > > > graphical elements. > > > > > > > >I seem to recall that we decided, about rectangles, that we would > > > >always parameterize as two diagonally-opposite corner points. So > > > >instead of > > > > > > > >xmin,xmax,ymin,ymax > > > >or > > > >xmin,ymin,xmax,ymax > > > > > > > >it would be: > > > >x1,y1,x2,y2 (the coordinates of P1,P2, which are two > > > >diagonally-opposite corner points). > > > > > > > >This looks similar to xmin,ymin,xmax,ymax, but it allows > > the use of > > > >either pair of diagonally-opposite corner points, whereas > > > the min-max > > > >only allows for the one pair. > > > > > > > >It is a small point. But it is at variance with present > > > (2.0) practice > > > >in > > > >Ch.3 and Ch.5, and I seem to recall some earlier > > resolution to stick > > > >with the way of CGM:1999 and WebCGM 2.0. > > > > > > > >Does anyone want to argue for min/max pairs? > > > > > > > >-Lofton. > > > > > > > >>Exceptions > > > >> None > > > >> > > > >>Chapter 6 - no changes > > > >>Chapter 7 - no changes > > > >>Chapter 8 > > > >> > > > >>Add to WebCGMAppStructure object methods: > > > >> > > > >>getAppStructureExtent() > > > >> This method has no parameters. > > > >> This method returns a String > > > >> > > > >> > > > >> > > > >>-- > > > >>Stuart Galt > > > >>SGML Resource Group > > > >>stuart.a.galt@boeing.com > > > >>(206) 544-3656 > > > >> > > > >> > > > >>------------------------------------------------------------ > > > --------- > > > >>To unsubscribe from this mail list, you must leave the > > > OASIS TC that > > > >>generates this mail. You may a link to this group and all > > > your TCs in > > > >>OASIS > > > >>at: > > > >>https://www.oasis-open.org/apps/org/workgroup/portal/my_work > > groups.php > > > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > > > >To unsubscribe from this mail list, you must leave the > > OASIS TC that > > > >generates this mail. You may a link to this group and all > > > your TCs in > > > >OASIS > > > >at: > > > >https://www.oasis-open.org/apps/org/workgroup/portal/my_workg > > roups.php > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS > > TC that generates this mail. You may a link to this group > > and all your TCs in OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr >oups.php > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS > > TC that generates this mail. You may a link to this group > > and all your TCs in OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr >oups.php > > > > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]