[Gzz-commits] manuscripts ./gzigzag.bib Alph1/alph.rst AniFon...

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/10/15 06:36:41

Modified files:
        .              : gzigzag.bib 
        Alph1          : alph.rst 
        AniFont        : anifont.tex 

Log message:
        Arch sync

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/gzigzag.bib.diff?tr1=1.139&tr2=1.140&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/Alph1/alph.rst.diff?tr1=1.10&tr2=1.11&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/AniFont/anifont.tex.diff?tr1=1.10&tr2=1.11&r1=text&r2=text

Patches:
Index: manuscripts/Alph1/alph.rst
diff -u manuscripts/Alph1/alph.rst:1.10 manuscripts/Alph1/alph.rst:1.11
--- manuscripts/Alph1/alph.rst:1.10     Tue Sep 30 07:40:52 2003
+++ manuscripts/Alph1/alph.rst  Wed Oct 15 06:36:40 2003
@@ -3,417 +3,24 @@
 
=========================================================================================
 
 
+- here are some text models 
 
-Abstract
-========
+    - bitmap
 
-We introduce the Alph Fluid Media Model, a simple, 
-easily implementable version
-of the Xanalogical referential fluid media model.
+    - chars
 
-We present three techniques to make the model 
-easily applicable to modern systems.
+    - ohco
 
-The permanent addresses in the spans refer to *scrollblocks*, 
-clearly delimited, permanent blocks
-of fluid media data. A span can only contain fluid media units 
-from one scrollblock.
+    - xanalogical
 
-Random-id content-carrying spans are useful for text: 
-they allow most of the advantages
-of Xanalogical fluid media with only an increase 
-in space in non-Xanalogical uses, i.e., no 
-fetching the content of the span from afar.
+- Here's the RICC text model
 
-PageImage scrollblocks are used for interoperability 
-with the modern real world, where
-receiving PDFs and Postscript files, i.e., images of pages, is a reality.
+    - an instance of *transcludable text*, which is a generalization of 
xanalogical text
 
+    - this and this are the problems of xu text, normal text, here's the 
solution
 
-Introduction
-============
+- Here's how it's useful
 
+- Here's an example
 
-...  Starting point: [nelson99xanalogicalneeded]_, where no references to 
tumblers &c are made.
-
-... "What is text" by DeRose(in FenPDF, SigDOC asterisk reprint), hierarchical 
content objects, ...
-Text models
-
-Udanax ... Sunless-sea!! (xanalogical prototype token_word) 
-
-Text Models
-===========
-
-text as bitmap is discussed in the OHCO reference...
-
-Sequence of characters
-----------------------
-
-The OHCO text model
--------------------
-
-Conception of "text" is slightly different from ours!!!
-
-- about representing *formatting* or *structure* of text - 
-  SGML and stuff.
-
-Gives models:
-
-- Text as bitmap
-- Text as a stream of characters
-- Text as characters and formatting instructions
-- Text as page layout
-- Text as a stream of content objects
-
-TEI!
-
-- recognizes problem of multiple hierarchies -- which RFM solves
-  (to a degree)
-
-- versioning
-
-    - claims useful, see e.g. chapter changing place
-
-    - however, if changes place *and* name, ???
-
-- BIG CLAIM: 
-
-    Text *is* an ordered hierarchy of content objects
-
-Uses quotation 
-
-    The trouble with "What You See Is What You Get"
-    is that "What You See Is All You've Got."
-
-    - Brian Kernighan
-
-As an example
-
-...
-
-SEE ALSO CRITIQUES IN SAME : 
-
-- Selber: [selberxxohcoconcerns]_
-
-    - too restrictive, no context of text, &c
-
-- Hill (not so relevant for us, I think)
-
-- Dicks [dicksxxohcothird]_
-
-    - graphics
-
-       - separate
-
-       - relationship bad
-
-       - intertwingled graphics and text!!
-
-    - typefaces &c
-       
-       - may be part of message sometimes
-
-    - large example
-
-       - immutable relations between text and graphics
-         found desirable by actual writers to get their
-         message across best
-
-- to summarize (tjl) all non-AI models have their limits!
-
-Live text
----------
-
-Live text [fraser90live]_ (unix grep -> editable, through remembering source )
-
-Referential fluid media (RFM)
------------------------------
-
-The abstraction of the fundamental idea of Xanalogical 
-systems described in [nelson99xanalogicalneeded]_
-is, formally,
-
-As discussed by Nelson [nelson99xanalogicalneeded]_, 
-the most fundamental and secret idea
-of the Xanalogical model was to endow each unit of "fluid media" 
-(i.e. character of text, 
-pixel of image, sample of sound, pixel in a frame in a video) 
-with a permanent, universal
-identifier.
-
-Advantages
-
-- searching for transclusions
-
-    - copies retain identity
-
-- better understanding of versions
-
-    - visualizations
-
-    - may allow better merge algorithms!
-
-- non-breaking links - ?
-
-- transcopyright, transclusions to other contexts - ?
-
-    - content-based micropayment
-
-
-Downsides
-
-- increased resource consumption for text (for images, sound, ... it's 
unnoticeable)
-
-    - not really an issue
-
-- central servers, content fetching, performance, ...
-
-    - we present an alternative solution
-
-
-Making an implementation of referential fluid media practical: Two concrete 
models
-==================================================================================
-
-In this section, we present two different directions that the basic RFM model
-can be taken towards, and argue that these different directions are suited
-for different types of media.
-
-- implemented: we flatten it to OHCO, with spans of letters being
-  OHCO content objects
-
-Content-addressed RFM (CARFM)
--------------------------------------------------
-
-Content addressing is a ... hash (NOTE)
-
-http://www.intranetjournal.com/articles/200306/ij_06_04_03a.html
-
-Instead of continuous permascrolls as the Udanax implementation uses,
-the content-addressed referential fluid media (CARFM) model is based on
-*scrollblocks* which are fixed blocks of fluid media referenced through 
-content-addressing.
-
-... A *span* in Alph is a reference to a single, contiguous (rectangular) 
-block of fluid media units
-inside a single scrollblock.
-
-Inserting text character by character is achieved through first creating
-a *temporary*, modifiable scroll block and temporary span objects
-using that, and converting the temporary scrollblock into a permanent,
-content-addressed scroll block before saving the data.
-
-We have first presented the basic idea of using scrollblocks in 
[lukka02guids]_, 
-
-Random-id content-carrying RFM (RICC RFM)
------------------------------------------
-
-Random-id content-carrying (RICC) spans are a novel twist 
-on the basic referential fluid
-media model. A RICC span consists of 
-
-- a **random** UUID (Unique Universal IDentifier)
-
-- offsets (in each dimension)
-
-- **the content** of the span
-
-Storing the actual content in the span is what makes RICC spans novel: 
-there is no real
-reference in them, just the identifier.
-
-- ... random numbers of 160 bits sufficient for ...
-
-Pros:
-
-- Easiest to program
-
-    - Only difference to strings in non-xanalogical use: 
-      take up somewhat more space!
-
-    - no need for servers, scrollblocks, ...
-
-- Gets most of the benefits of the full xanalogical model
-
-    - transclusions
-
-    - Xanalogical links
-
-- blends with XML (which handles text internally,
-  and media references externally)
-
-Cons:
-
-- Can only access the parts of the "scrollblock" that are stored in spans
-
-    - not, e.g., the full keystroke record envisioned by Nelson 
-      (private communication)
-
-- Spoofing ?
-
-    - cannot really do damage, as comparison is applied to *both* id *and* 
content
-
-- Transcopyright and micropayments not possible.
-
-    - direct tradeoff: *either* you need central servers and a big
-      framework, *or* you don't get these.
-
-Operability in a real-world context
-===================================
-
-Page Image Spans (PS/PDF/DjVu/...)
-----------------------------------
-
-The support for *PageImages* is one of the aspects of Alph geared 
-towards reasonable operability in a modern context.
-
-Fake Spans
-----------
-
-The Alph Content Format
-=======================
-
-- XML format used by ALPH
-
-- incl. URN-5, Storm URI
-of the Xanalogical model.
-
-
-Storm URIs
-----------
-
-- Like Data URIs, but with content hashes instead of data
-
-URN-5
------
-
-The Alph DTD
-------------
-
-
-Free (Libre) Implementation in Java + OpenGL
-============================================
-
-XXX Finish alph indices, ...
-
-Applications
-============
-
-In most languages, Strings are such a primitive data type
-that replacing them is not easy...
-
-need some programming
-
-Insert Alph into
-
-- an editor
-
-- 
-
-
-Conclusion
-==========
-
-...
-
-One of the major missing pieces in the Alph Fluid Media Model
-is support for web pages. Due to the variability of
-
-Future work
-
-- SVG and RFM
-
-    - could we approach what is dreamed of in [dicksxxohcothird]_?
-
-- Other alternatives: OHCO, but with permanent objects down to 
-  character level
-
-    - advantage: larger structure than a letter has its id
-
-    - "Who collected this information" ...
-
-
-...
-
-Notes
-=====
-
-We call our model the Alph Fluid Media Model to avoid trademark issues.
-The name Alph has its origins in the same poem as Xanadu(tm), 
-as the "sacred river".
-
-160 bits of randomness, or of hash are sufficient. blah blah
-
-
-The full model in a modern context
-==================================
-
-
-
-Aspects that have been implemented in other systems
----------------------------------------------------
-
-- Micropayments
-
-    - Refs...
-
-    - no success yet, consumer interest low, free access
-      or macroscopic payments (e.g. ACM: $XXX for article)
-      the norm.
-
-- Versioning
-
-    - did this appear somewhere before xu plans?
-
-    - arch/tla = *very* like the xanadu versioning system
-
-    - Enfilades not implemented
-
-
-Aspects that appear incompatible with modern systems
-----------------------------------------------------
-
-- Single central authority
-
-- Monolithic system storing all documents
-
-- Tumblers
-
-    - We *have* dns, URIs - somewhat similar but very different:
-
-       - Tumbler = LOGICAL hierarchical, not server address
-
-    - Has central authority; going out of vogue
-
-    - Referencing all of an author's work as a single span -- ...
-
-    - GUIDs
-
-    - UUID
-
-    - OIDs!
-
-      http://www.ariadne.ac.uk/issue8/unique-identifiers/
-
-    - DOIs
-
-- Xanadu "stations"
-
-    - Nelson's other predictions including carryable/wearable
-      computers came first, as well as cellular and wireless
-      networking
-
-
-The full Xanalogical model
-==========================
-
-XM
-
-Potentially useful aspects not currently in use
------------------------------------------------
-
-- The referential fluid media model - "permascrolls"
-
-- Transclusions
-
-- Xanalogical links
-
+- Done
Index: manuscripts/AniFont/anifont.tex
diff -u manuscripts/AniFont/anifont.tex:1.10 
manuscripts/AniFont/anifont.tex:1.11
--- manuscripts/AniFont/anifont.tex:1.10        Tue Oct 14 10:21:38 2003
+++ manuscripts/AniFont/anifont.tex     Wed Oct 15 06:36:40 2003
@@ -9,9 +9,9 @@
 \maketitle
 
 \begin{abstract}
-We demonstrate a counterintuitive hardware-accelerated
-rendering trick:
-when rendering an isotropically textured 2 1/2D scene,
+We demonstrate a simple but counterintuitive hardware-accelerated
+rendering trick for improving image quality.
+When rendering an isotropically textured 2 1/2D scene,
 stretching an image when putting it into a texture
 and squishing it with texture coordinates when rendering yields 
 a slightly but significantly better 
@@ -20,21 +20,25 @@
 We show a simple way to understand why this trick works, and discuss
 various generalizations. We show examples of text rendered both ways.
 
-As background for the trick, we discuss harware anisotropic 
-texture filtering and show
-how to probe the filters to understand their function, paying 
+To show how our demonstration figures were
+generated,
+in an appendix we show how to probe and visualize the texture filtering 
happening
+on an actual hardware graphics accelerator in a general way, paying
 attention to what assumptions have to be made for such probing to work.
 
 
+
 \end{abstract}
 
 \section{Introduction}
 
 Recently, ...
 
+Texture mapping is a ubiquitous ... \cite{haeberli93texture}
+
 - off-line rendering: EWA XXXREF
 
-- Trilinear/bilinear (mipmap) filtering was designed to avoid temporal and 
spatial aliasing XXXREF
+- Trilinear/bilinear (mipmap) filtering was designed to avoid temporal and 
spatial aliasing\cite{williams83pyramidal}
 
 - can blur sharp edges (text) too much
 
@@ -44,7 +48,7 @@
 - basic anisotropic solution: more samples from the mipmaps than the 8 used for
   trilinear - better approximation of EWA. Modern graphics cards support up to 
XXX samples
 
-- Unextended OpenGL aniso: article on using lod bias etc to get it
+- Unextended OpenGL aniso: article on using lod bias etc to get 
it\cite{olano98pixelflow}
 
 - supersampling: FSAA / as above; however, most cards focus on multisampling, 
not supersampling - 
   no help for textures
@@ -59,10 +63,6 @@
   TrueType shows maybe not the right model but ...
 
 
-The rest of the article is organized as follows.
-
-\section{Surprise: stretch-squish can yield better images in orthogonal 
transformations}
-
 - case we consider: sharp edges, orthogonal (or nearly so) transformations, 
e.g. text
 
 - for sharp edges / small features, even under orthogonal transformations, 
trilinear bad:
@@ -74,14 +74,48 @@
   stretch the texture in one direction, squish back by texture coordinates. 
activate
   the aniso filter. Aniso filters planned so that they don't flicker, either.
 
+
+The rest of the article is organized as follows.
+
+\section{Surprise: stretch-squish can yield better images in orthogonal 
transformations}
+
+Recently, we were looking at increasing the resolution of the page
+textures in our system which shows PDF files in a fisheye view, using
+2048x2048 textures for the pages.  
+Hardware anisotropic filtering was
+enabled in order for the fisheye transformation not to blur the textures.  
+The pages were approximately
+letter-size and already scaled vertically nearly to the maximum size,
+but scaled isotropically.  We decided to try to scale both axes to
+the maximum extent, anisotropically, even though we suspected it might
+degrade the image quality.
+
+However, it did not. To our great surprise, the image quality (the
+readability of the text) actually \emph{improved significantly}.
+Stretching the text in the texture and squishing it back with adjusting
+the texture coordinates improved image quality.
+
+The most important area for reading is naturally the center of the fisheye,
+where the transformation is nearly orthonormal - the 
+edges are mostly used for getting a sense of the context, not for reading.
+
+After some investigation, we discovered that we had found a special case
+of a general principle: if a texture image is only transformed through 
+rotation and isotropic scaling, a better filtering result is always obtained
+by applying the stretch-squish operation.
+
 \begin{figure}
 a)\\
 b)\\
 \caption{
-\label{figstretchsquish}
-a) Normal texturing 
+\label{figstretchsquishsamples}
+Texture samples' contribution to a pixel's value.
+Appendix A shows how
+these figures can be generated easily to show the actual behaviour of the 
hardware.
+a) Normal trilinear filtering. Playing around with a view like this of 
filtering
+can show how \emph{bad} trilinear filtering really is. 
 b) Stretching the texture and squishing it allows more samples to be used
-through an anisotropic filter.
+through an anisotropic filter. Here: XXX
 }
 \end{figure}
 
@@ -124,10 +158,6 @@
   how must faster than real supersampling -- does aniso filter provide
   ``optimal'' quality / cost ratio?
 
-- effect was first noticed when fitting a Letter PDF page into 2048x2048 
texture:
-  earlier used only part of resolution, anisotropic version surprisingly 
improved
-  the result significantly
-
 
 
 \section{Conclusion}
@@ -146,6 +176,9 @@
   it is widely implemented and optimized and thus it can be used to obtain 
   a significant improvement for a moderate performance hit.
 
+- this is a REALLY SIMPLE way to get a SOMEWHAT better quality. For dramatic 
improvements,
+  real supersampling is needed
+
 Seveeral aspects we did not touch
 
 - basic model of filtering - well-known (e.g. advanced opengl course notes): 
@@ -153,8 +186,6 @@
 
 - LCD-text
 
-- due to the driver situation (ATI's Linux drivers still weak) we haven't been 
able to 
-  test ATI cards ...
 
 
 \section{Acknowledgments}
Index: manuscripts/gzigzag.bib
diff -u manuscripts/gzigzag.bib:1.139 manuscripts/gzigzag.bib:1.140
--- manuscripts/gzigzag.bib:1.139       Mon Sep 22 11:45:39 2003
+++ manuscripts/gzigzag.bib     Wed Oct 15 06:36:40 2003
@@ -2363,6 +2363,15 @@
     year = "1986",
     url = "citeseer.nj.nec.com/heckbert86survey.html" }
 
address@hidden,
+    author = "Marc Olano and Shrijeet Mukherjee and Angus Dorbie",
+    title = "Vertex-based Anisotropic Texturing",
+    booktitle = "HWWS'01",
+    year = "2001",
+    pages = "95-98"
+}
+
+
 @comment -----------------------------------------
 @comment Procedural texturing
 @comment -------------------------------------------
@@ -6163,3 +6172,5 @@
     month= "August",
     year = "1990" 
 }
+
+