- From: Don <dlarson@cgmlarson.com>
- Date: Thu, 4 Dec 2008 14:30:10 -0600
- To: Lofton Henderson <lofton@rockynet.com>, WebCGM WG <public-webcgm-wg@w3.org>
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#webcgmrect > -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 20:31:25 UTC