kc3-lang/ftgl

diff --git a/README.txt b/README.txt
index dbdd636..1d3d19b 100755
--- a/README.txt
+++ b/README.txt
@@ -1,5 +1,5 @@
-FTGL 1.3b4
-December 11 2001
+FTGL 1.3b5
+January 27 2002
 
 DESCRIPTION:
 
@@ -48,7 +48,36 @@ http://homepages.paradise.net.nz/henryj/
 
 
 
-//========================================================================
+//==============================================================================
+
+Version 2??????
+My initial design of FTGL was in 2 distinct parts...the freetype stuff and
+the FTGL stuff. The freetype side contained wrappers for the freetype stuff
+(surprise) and the ftgl side handled all the opengl stuff. All communication
+was done via FTFace <-> FTFont. This felt right from a design point of view
+because conceptually it made sense, it was clean, simple and it insulated
+FTGL from changes in freetype. Up to version 1.3 I have rigidly stuck to
+this 'rule'. Unfortunately this has been at the expense of the code. This
+became most evident when dealing with char maps. Common sense would argue
+that charmaps and the glyph container are intimately related, but because
+of the 'rule' the communication path between them is...
+FTGlyphContainer <-> FTFont <-> FTFace <-> FTCharMap
+This is bollocks and has lead to some ugly code.
+I am not about abandon the design completely, just the rule that says all
+communication should be via FTFace <-> FTFont. I will still maintain
+wrappers for freetype objects, but they will interface with ftgl in places
+that make the most sense from a code efficiency point of view.
+
+move glyph creation out of constructor, but oad the freetype glyph and get
+the metrics.
+Change all dim stuff to float. Make my own floating point version of
+FT_Vector.
+Move Charmap to be owned by glyph container. See above
+Try out cbloom sorted vector in charmap. faster than std::map?
+Enable access to raw glyph data
+State handling...
+inline base class methods
+
 
 Things to think about...
 
@@ -63,9 +92,6 @@ is the earliest but what happens if the client doesn't set the char size?
 Define a default size, check if glyphlist is valid in render function, if
 not call size with default size.
 
-Might have to move the init code out of the glyph constructors into an
-init function so that they can return errors.
-
 good sites...
 http://cgm.cs.mcgill.ca/~luc/
 http://www.blackpawn.com/texts/lightmaps/default.html
@@ -98,7 +124,7 @@ Seems terribily inefficient but to do that, but doing it as
 above I seem to be leaking memory.
 
 
-No, this is the correct behaviour. Each call to TT_Load_Glyph
+No, this is the correct behavior. Each call to TT_Load_Glyph
 overwrites the previous content.. and this was designed on
 purpose because the real content of a TT_Glyph object is
 _really_ complex with TrueType, and you don't want to create
diff --git a/TODO.txt b/TODO.txt
index 532fca2..66e3f3c 100644
--- a/TODO.txt
+++ b/TODO.txt
@@ -1,9 +1,10 @@
-FTGL 1.3b4
-December 11 2001
+FTGL 1.3b5
+January 27 2002
 
 TODO:
 	- namespace ftgl or gltt?
-	- make a decision about what units to use for font metrics!!!
+	- use float for all font metrics and advance metrics.
+	
 	
 FUTURE:
 	- select face ie italic, bold etc
@@ -23,8 +24,18 @@ FUTURE:
 	  5 polylines (0.2 step) for every curve, adjust the fineness for
 	  the length of the curve. But then you should also test the angle
 	  of the tangents as well.
+	- Guard classes - vectoriser
+	- Template methods
+    - Move the init code out of the glyph constructors into an init
+      function so that they can return errors.
+      
 
 BUGS:
+	- FTExtrdGlyph - Some glyph contours are 'wound' in reverse causing
+	  the 'sides' of the extrusions to be culled. First fix only half
+	  worked. When calculating the winding using the summed area I need
+	  to use the outside contour only. How do I know it's an outside
+	  contour? A workaround is to disable face culling.
 	- Advance/Kerning is screwed up for really small point sizes eg 2 point.
 	  This is because I'm trying to use FT_Vector which is integer based.
 	  I will probably have to make my own struct with floats.
@@ -36,8 +47,3 @@ BUGS:
 	  hopefully the freetype guys will sort this.
 	- FTVectoriser seems to position some points incorrectly. confusing
 	  line point with control point at start or end????
-	- FTExtrdGlyph - Some glyph contours are 'wound' in reverse causing
-	  the 'sides' of the extrusions to be culled. First fix only half
-	  worked. When calculating the winding using the summed area I need
-	  to use the outside contour only. How do I know it's an outside
-	  contour? A workaround is to disable face culling.