- From: Lofton Henderson <lofton@rockynet.com>
- Date: Thu, 04 Dec 2008 14:46:12 -0700
- To: "WebCGM WG" <public-webcgm-wg@w3.org>
Okay, we have: 1 vote for "as is" in 2.1 LCWD -- lower-left and upper-right corners. And addressing the implied error condition (in setView -- invalid rectangle) if, for example, the input points were upper-left and lower-right. 1 vote for changing to "two diagonal corner points", consistent with all other rectangles in WebCGM. Other thoughts? Unless there is a clear majority for changing, "as is" wins. Just to clarify... Btw, as I understand, no one is proposing error conditions in WebCGMRect, are they? I thought Ben was asking for some return indication or exception from setView(). So it would be possible to create a WebCGMRect with the 4 numbers leading to a "bad" rect. E.g., myRect.xll>myRect.xur and yRect.yll>myRect.yur (Although Ben asked about setView(), what would unionRect() do about bad input?) -Lofton. At 03:57 PM 12/4/2008 -0500, Bezaire, Benoit wrote: >Let's try an make is easy for script writers, ok? Else these new DOM >calls will never get used. > >Two opposite corner points just complicates the code for script writers, >they have to add 'checks' to determine which point is which. I didn't >oppose the decision for viewcontext back in WebCGM 2.0 since script >writers were unlikely to change the viewcontext. I think it's different >for WebCGMRect() though. > >Benoit. > >-----Original Message----- >From: public-webcgm-wg-request@w3.org >[mailto:public-webcgm-wg-request@w3.org] On Behalf Of Don >Sent: Thursday, December 04, 2008 3:30 PM >To: Lofton Henderson; WebCGM WG >Subject: re[2]: invalid/extreme rectangles in setView() > > >Lofton, > > > At 01:12 PM 12/4/2008 -0600, Don wrote: > > > >Lofton, > > > > > > > All -- > > > > > > > This is a dangling open piece of Benoit's setView() questions. >We closed > > > the other piece (about different aspect ratios). I >can't find any thread > > > discussion about this piece, after >Benoit's message below (top), and > > > it apparently remains open. > > > > > > > Discussion? > > > > > >I believe we should have very basic checking for Invalid rectangle >and > >return boolean as Benoit suggested. A minimal invalidity check >would be > >if ymax < ymin or xmax < ymin. > > > Side question: I just looked at WebCGMRect. Does anyone recall why >we > parameterized it in terms of "lower left corner" and "upper right > > corner"? Why not just "two diagonally opposite corner points P1 and >P2 > [(x1,y1) and (x2,y2)]"? > >I not sure why but I think it would be nice to be consistent with >viewcontext where we define viewcontext as "defining two corner points >of a rectangle". > >http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-IC.html#webcgm_3 >_2_2_2 > > > For the former, it sets up an error condition (or is "error prone"). >Do we > need that error condition? For the latter, the only error >condition is a > degenerate rectangle, i.e., zero area, i.e., >xmin=xmax and/or ymin=ymax. > >I don't think we need any error checking at all on WebCGMRect. A >programmer may want to set a WebCGMRect = 0,0,0,0 for example as some >kind of indication. > >Don. > > There may be a reason we did it this way (more error prone, or >allows > setting an error), but I don't recall it. I do recall the >stuff about > getObjExt() on an APS with no primitives, but we now >return 'null' for > that, so we don't need the somewhat hokey mirrored >rectangle. > > > >http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-DOM.html#webcgmr >ect > > > -Lofton. > > > > > > -Lofton. > > > > > > > At 09:44 AM 11/19/2008 -0500, Bezaire, Benoit wrote: > > > > I remember this thread. I don't want to reopen old issues. > > > > > > > > However, for this particular API, a script writer can easily >loose the > > > display (zooming on a very small rectangle or >zooming our far enough that > > > nothing is displayed). I think the >API should at least return a more > > > meaningful value. > > > > > > > > Some options: > > > > i) boolean: TRUE if new view was set; FALSE is rectangle was >invalid. > > > > ii) float: returns the scale factor between the old view and >the new view. > > > > > 0 is successful, failed otherwise. > > > > iii) WebCGMRect: a rectangle defining the old view. > > > > > > > > Any of those would help the script writer understand what went >wrong, > > > instead of getting in touch with technical support. > > > > > > > > Benoit. > > > > > > > From: Lofton Henderson [mailto:lofton@rockynet.com] > > > >Sent: Tuesday, November 18, 2008 7:08 PM > > > To: Bezaire, Benoit; >WebCGM WG > > > Subject: Re: Question about setView() > > > > > > > At 08:57 AM 11/18/2008 -0500, Bezaire, Benoit wrote: > > > > I'm wondering if the wording of setView() is not a bit short? >The draft > > > doesn't say anything about invalid rectangles being >passed in for example. > > > > > > > > Should more feedback be sent to the user? Currently, the >function > > > prototype has a void return type. Should we change >that to a boolean or > > > something else? or throw an exception >perhaps. > > > > Dieter raised and we discussed a similar question a few months >back. >As a > > > > general rule, CGM and WebCGM say what happens with valid input >but have > > > been relatively silent about error fallbacks, viewer >error reactions, etc. > > > > What we have done most recently is say something like "...has >no effect". > > > > We generally have not gone to more extensive error reactions. >See for > > > example the 'grnode' stuff that we added to the >interfaces. > > > > > > > My view is that, if we start opening the door to saying what >viewers do > > > for this and that bad input, where do we stop? >Should we go back and > > > define mandatory error responses for all >bad input? > > > > > > > Note that the profile (Ch.6) *does* talk a lot about >"degeneracies". >It > > > > says what is the graphical effect of a degenerate primitive, >etc., and > > > this is what is *suggested* in CGM:1999 itself -- >WebCGM just makes > it > > > normative. (But saysnothing more >about what the viewer should do > when > > > encountering >degeneracies. Silent? Warning? Task-bar "abnormality" > > > > icon?) > > > > > > > I guess I favor "...invalid input has no effect, neither >graphical nor to > > > the DOM tree." Then leave it to the >implementor, what else the viewer > > > might do in the way of error >response to the user. > > > > > > > > I also question the possibility of a major scale change, ex: >scaling > > in by > > > a factor of 100 (and loosing sight of the >overall picture). Should the > > > user be told that such a change >occurred? > > > > I guess I view this as another choice for implementors. > > > > > > > I could also live with putting some valid limits on it. >"Valid rectangles > > > shall not change the scale by more than >...blah..." > > > > > > > -Lofton.
Received on Thursday, 4 December 2008 21:47:04 UTC