RE: re[2]: invalid/extreme rectangles in setView()

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 20:58:02 UTC