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#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