W3C home > Mailing lists > Public > public-webcgm-wg@w3.org > December 2008

re: invalid/extreme rectangles in setView()

From: Lofton Henderson <lofton@rockynet.com>
Date: Thu, 04 Dec 2008 12:49:44 -0700
Message-Id: <5.1.0.14.2.20081204124221.03b5f410@localhost>
To: Don <dlarson@cgmlarson.com>,WebCGM WG <public-webcgm-wg@w3.org>

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)]"?

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.

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 19:50:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 December 2008 19:50:35 GMT