[Gzz-commits] gzz/doc/pegboard 1008/PEG_1008.rst 1009/PEG_100...

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      02/10/07 00:33:07

Modified files:
        doc/pegboard/1008: PEG_1008.rst 
        doc/pegboard/1009: PEG_1009.rst 
        doc/pegboard/1010: PEG_1010.rst 

Log message:
        comment, object

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1008/PEG_1008.rst.diff?tr1=1.12&tr2=1.13&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1009/PEG_1009.rst.diff?tr1=1.11&tr2=1.12&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1010/PEG_1010.rst.diff?tr1=1.6&tr2=1.7&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1008/PEG_1008.rst
diff -c gzz/doc/pegboard/1008/PEG_1008.rst:1.12 
gzz/doc/pegboard/1008/PEG_1008.rst:1.13
*** gzz/doc/pegboard/1008/PEG_1008.rst:1.12     Sun Oct  6 14:48:56 2002
--- gzz/doc/pegboard/1008/PEG_1008.rst  Mon Oct  7 00:33:07 2002
***************
*** 4,11 ****
  =============================================================
  
  :Authors:  Tuomas Lukka, Benja Fallenstein
! :Date:     $Date: 2002/10/06 18:48:56 $
! :Revision: $Revision: 1.12 $
  :Status:   Incomplete
  
  
--- 4,11 ----
  =============================================================
  
  :Authors:  Tuomas Lukka, Benja Fallenstein
! :Date:     $Date: 2002/10/07 04:33:07 $
! :Revision: $Revision: 1.13 $
  :Status:   Incomplete
  
  
***************
*** 32,37 ****
--- 32,46 ----
  font will render itself with baseline somewhere between y=1 and y=0, and 
  the line height such that the similar line rendered above would have its 
  y=1 coordinate at this vob's y=0.
+ 
+     (Benja:) I object to this peg on the grounds that without a clear
+     definition where the baseline will be, it is impossible to do
+     text layout. I also object because even though I asked for it,
+     there is no explanation of the considerations above, just a
+     (fuzzy) rule how it should work (``:-(``). With the rule given,
+     the baseline could be at y=0 or y=1, if the rendering is only
+     consistent in this choice, but text layout based on that is
+     absolutely impossible!
  
  The font will have its normal aspect ratio if the unit vectors 
  are equal, i.e. if the distances (0,1)..(0,0) and (0,1)..(1,1) are the same.
Index: gzz/doc/pegboard/1009/PEG_1009.rst
diff -c gzz/doc/pegboard/1009/PEG_1009.rst:1.11 
gzz/doc/pegboard/1009/PEG_1009.rst:1.12
*** gzz/doc/pegboard/1009/PEG_1009.rst:1.11     Sun Oct  6 14:50:42 2002
--- gzz/doc/pegboard/1009/PEG_1009.rst  Mon Oct  7 00:33:07 2002
***************
*** 4,11 ****
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/06 18:50:42 $
! :Revision: $Revision: 1.11 $
  :Status:   Incomplete
  
  Transformations
--- 4,11 ----
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/07 04:33:07 $
! :Revision: $Revision: 1.12 $
  :Status:   Incomplete
  
  Transformations
***************
*** 47,52 ****
--- 47,71 ----
                (Tjl:) I didn't make my point clear. We *can* do this,
                if we ask, at vobscene construction time,
                how tall a given cs will be. 
+                 
+                     (Benja:) Ah. Now I understand somewhat... However,
+                     even then, you cannot satisfy scaling in two dimensions,
+                     so it would have to be ``scale(int into, float scale)``.
+                     Also, you're talking about the "height" of a coordsys--
+                     what is this? Coordsys are, at this point, transformations
+                     of points-- so what's the "height" of a transformation?
+                     Finally, I still don't like scale being here, because
+                     generally having to know the scale before the view
+                     comes in means that we cannot switch to a system where
+                     (in gl) we determine the parent transformations
+                     *after* the views have done their job. For example in
+                     text layout, it would be nice if we could first render
+                     the text with a given width, then look at the resulting
+                     height and decide how to translate the result-- this
+                     requires that a coordsys gets its parent after it
+                     is first created-- not currently allowed, but not 
+                     impossible to change.
+                     
  
  And into AffineVobCoorder the following functions::
  
***************
*** 54,60 ****
      int scale(int into, float x, float y, float z);
  
  Also, for all these functions, we should have a shorthand
! in VobScene:
  
      public int translateCS(int into, Object key, float x, float y);
  
--- 73,79 ----
      int scale(int into, float x, float y, float z);
  
  Also, for all these functions, we should have a shorthand
! in VobScene::
  
      public int translateCS(int into, Object key, float x, float y);
  
Index: gzz/doc/pegboard/1010/PEG_1010.rst
diff -c gzz/doc/pegboard/1010/PEG_1010.rst:1.6 
gzz/doc/pegboard/1010/PEG_1010.rst:1.7
*** gzz/doc/pegboard/1010/PEG_1010.rst:1.6      Sun Oct  6 13:41:10 2002
--- gzz/doc/pegboard/1010/PEG_1010.rst  Mon Oct  7 00:33:07 2002
***************
*** 3,10 ****
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/06 17:41:10 $
! :Revision: $Revision: 1.6 $
  :Status:   Incomplete
  
  Main benefits
--- 3,10 ----
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/07 04:33:07 $
! :Revision: $Revision: 1.7 $
  :Status:   Incomplete
  
  Main benefits
***************
*** 119,122 ****
  
  would then work as expected.
  
! 
--- 119,123 ----
  
  would then work as expected.
  
!     (Benja:) ``buoyCS`` would be an addition to ``VobScene``? Also,
!     ``translate`` should be ``translateCS`` as of PEG 1009.