[Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Tuomas J. Lukka <address@hidden>        02/10/06 12:37:53

Modified files:
        doc/pegboard/1009: PEG_1009.rst 

Log message:
        resp

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1009/PEG_1009.rst.diff?tr1=1.5&tr2=1.6&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1009/PEG_1009.rst
diff -c gzz/doc/pegboard/1009/PEG_1009.rst:1.5 
gzz/doc/pegboard/1009/PEG_1009.rst:1.6
*** gzz/doc/pegboard/1009/PEG_1009.rst:1.5      Sun Oct  6 12:27:42 2002
--- gzz/doc/pegboard/1009/PEG_1009.rst  Sun Oct  6 12:37:53 2002
***************
*** 3,10 ****
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/06 16:27:42 $
! :Revision: $Revision: 1.5 $
  :Status:   Incomplete
  
  Transformations
--- 3,10 ----
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/06 16:37:53 $
! :Revision: $Revision: 1.6 $
  :Status:   Incomplete
  
  Transformations
***************
*** 27,39 ****
  .. IMPORTANT::
      Should 3D scaling be here as well?
      
! (Benja says:)
!  
!     ``scale`` doesn't belong here, because AWT cannot do it properly
      when text is involved (because text's aspect ratio may change
!     with size).
!     
!     (Therefore, 3D scale doesn't belong here, either.)
  
  And into AffineVobCoorder the following functions::
  
--- 27,43 ----
  .. IMPORTANT::
      Should 3D scaling be here as well?
      
!     (Benja says:) ``scale`` doesn't belong here, because AWT cannot do it 
properly
      when text is involved (because text's aspect ratio may change
!     with size).  (Therefore, 3D scale doesn't belong here, either.)
!       
!       (Tjl:) Well, coordsys already *does* scale. The thing is to just
!       ask for the font's width with the right scale, which you should
!       be able to ask the coordsys. Something like 
! 
!           scale = vs.getHeight(cs);
! 
!       ?
  
  And into AffineVobCoorder the following functions::
  
***************
*** 49,59 ****
      Should there be a third interface, ThreeDCoorder?
      Or leave it into GLVobCoorder for now, like distort?
      
! (Benja says:)
! 
!     What would rotate3D be for? In our 2 1/2 D world, the z axis
      is really different from x and y...
  
  Also, for all these functions, we should have a shorthand
  in VobScene:
  
--- 53,65 ----
      Should there be a third interface, ThreeDCoorder?
      Or leave it into GLVobCoorder for now, like distort?
      
!     (Benja says:) What would rotate3D be for? In our 2 1/2 D world, the z axis
      is really different from x and y...
  
+       (Tjl:) Well, have you looked at fillets demo? We don't always
+       want to keep in a 2 1/2 D world. Sometimes 3D is nice.
+       But maybe best to leave it to GLVobCoorder.
+ 
  Also, for all these functions, we should have a shorthand
  in VobScene:
  
***************
*** 62,67 ****
--- 68,75 ----
  just to make it a little easier to say them.
  
      (Benja:) How about just ``translate``?
+       
+       (Tjl:) Want to make sure it's not interpreted as "translate this 
vobscene".
  
  For the affine ones, the VobCoorder is cast into AffineVobCoorder, and
  the error propagated if it's not.
***************
*** 76,81 ****
--- 84,92 ----
      is used in an environment it wasn't programmed for, which may
      happen in a production system.)
  
+       (Tjl:) How about UnsupportedOperationException? Hmm..
+       or a subclass of that, NotAffineCoorder
+ 
  
  Transforming points into coordinate systems
  -------------------------------------------
***************
*** 100,105 ****
--- 111,120 ----
  
      (Benja:) I think ``inverseTransformPoints3`` should raise an exception
      if no reasonable inverse can be found.
+ 
+       (Tjl:) One that requires catch() or one that doesn't?
+       I don't really like the exception either way: a pseudoinverse
+       (closest to real inverse) can be well-defined.
  
  The reason for allowing the array ``pt[]`` to contain several points is
  simply performance.