[Gzz-commits] fenfire/docs design_SpanImages.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/fenfire
Module name:    fenfire
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/06/16 12:48:29

Modified files:
        docs           : design_SpanImages.rst 

Log message:
        More about design

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/fenfire/fenfire/docs/design_SpanImages.rst.diff?tr1=1.6&tr2=1.7&r1=text&r2=text

Patches:
Index: fenfire/docs/design_SpanImages.rst
diff -u fenfire/docs/design_SpanImages.rst:1.6 
fenfire/docs/design_SpanImages.rst:1.7
--- fenfire/docs/design_SpanImages.rst:1.6      Thu Jun 12 08:50:23 2003
+++ fenfire/docs/design_SpanImages.rst  Mon Jun 16 12:48:29 2003
@@ -24,24 +24,27 @@
 
 There are several details which will make life difficult:
 
-- For PageImageSpans, there are several possible mappings from span to vob, 
since
-  there are several possible renderings: without background paper, with 
background paper,
-  with halos or blurring on the background paper &c.
-  Obviously, the code to go from an OpenGL texture to the rendered vob must be 
pluggable to allow
-  for these features and future extensions in rendering of images of text.
+- For PageImageSpans, there are several possible mappings from span 
+  to vob, since there are several possible renderings: without background
+  paper, with background paper, with halos or blurring on the background
+  paper &c.  Obviously, the code to go from an OpenGL texture to the
+  rendered vob must be pluggable to allow for these features and future
+  extensions in rendering of images of text.
 
 - Both the whole page and fragments of the page may be desired as separate vobs
 
-- The coordinate system of the page in the texture is not fixed between 
different spans; 
-  different resolutions might be used.
+- The coordinate system of the page in the texture is not fixed between 
+  different spans; different resolutions might be used.
 
-- unused spans need to be garbage collected and their textures freed: must be 
able to handle
-  spaces with 10^6 different span images.
+- unused spans need to be garbage collected and their textures freed: 
+  must be able to handle spaces with 10^6 different span images.
 
-- Need to be able to get width/height of the finished vob - what are its 
extents in the cs it will be placed to
+- Need to be able to get width/height of the finished vob - what are 
+  its extents in the cs it will be placed to
 
-- Should be able to say (optionally) that the given span is put into an 
important or unimportant place;
-  although this may be unnecessary if the pixel counting works and culling is 
used
+- Should be able to say (optionally) that the given span is put into 
+  an important or unimportant place; although this may be unnecessary
+  if the pixel counting works and culling is used
 
 User-visible interface
 ======================
@@ -78,20 +81,23 @@
     vertically(90, yy, org.nongnu.libvob.Vob, SpanImageVob);
     vertically(90, zz, org.nongnu.alph.ImageSpan, SpanImageFactory);
 
-Apart from the option of creating different kinds of SpanImageFactories with 
different properties
-for e.g. page backgrounds, this is all the other classes need to see.
+Apart from the option of creating different kinds of SpanImageFactories
+with different properties for e.g. page backgrounds, this is all the
+other classes need to see.
 
 Implementation
 ==============
 
-The implementations are in ``org.fenfire.spanimages.gl`` (once an AWT 
implementation
-is made, it will be in the package ``org.fenfire.spanimages.fuzzybear``).
+The implementations are in ``org.fenfire.spanimages.gl``
+(once an AWT implementation is made, it will be in the package
+``org.fenfire.spanimages.fuzzybear``).
 
 ImageSpan vs PageImageSpan
 --------------------------
 
-It is reasonable to expect different treatment of Image and PageImage spans:
-for PageImageSpans, we may want libpaper backgrounds and text-enhancing 
transformations.
+It is reasonable to expect different treatment of Image and PageImage
+spans: for PageImageSpans, we may want libpaper backgrounds and
+text-enhancing transformations.
 
 ..  UML:: fenfirespansint2
 
@@ -110,8 +116,8 @@
     ---
     horizontally(80, xx, MuxSpanImageFactory, SpanImageFactory);
 
-MuxSpanImageFactory calls one factory for pageimagespans and the other for 
plain
-image spans.
+MuxSpanImageFactory calls one factory for pageimagespans and the other
+for plain image spans.
 
 Repository of loaded images
 ---------------------------
@@ -179,18 +185,18 @@
     vertically(80, zz, SingleImage, ww);
     
 
-An important architectural feature is that the classes are not static: this 
allows
-us to, e.g, plug in filters for the images of PageImageSpan.
+An important architectural feature is that the classes are not static:
+this allows us to, e.g, plug in filters for the images of PageImageSpan.
 
 Mapping Images to Paper objects
 -------------------------------
 
-The libPaper paper abstraction is useful for rendering sections of the images,
-with various settings. The input should be the TexGen matrix for the paper 
texture,
-and the GL texture object. 
+The libPaper paper abstraction is useful for rendering sections of the
+images, with various settings. The input should be the TexGen matrix
+for the paper texture, and the GL texture object.
 
-We may want to change this interface to include the scale of the characters on 
the paper
-at some point to allow better text enhancement.
+We may want to change this interface to include the scale of the
+characters on the paper at some point to allow better text enhancement.
 
 ..  UML:: fenfirespans_paper
 
@@ -217,10 +223,10 @@
 Statistics accumulation and memory pool handling
 ------------------------------------------------
 
-Now we come to the *raison d'etre* of this architecture:
-centralized handling of the feedback from vobscene rendering.
-The TexAccum class in Libvob is able to accumulate the approximate
-number of pixels rendered at each mipmap level of each texture.
+Now we come to the *raison d'etre* of this architecture: centralized
+handling of the feedback from vobscene rendering.  The TexAccum class in
+Libvob is able to accumulate the approximate number of pixels rendered
+at each mipmap level of each texture.
 
 ..  UML:: fenfirespans_texaccum
 
@@ -242,7 +248,7 @@
     ---
     q.n = PoolManager.s;
 
-    org.nongnu.libvob.memory.MemoryPartitioner.s + (0, -60) = PoolManager.n;
+    org.nongnu.libvob.memory.MemoryPartitioner.s + (0, 60) = PoolManager.n;