gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/xupdf article.rst


From: Janne V. Kujala
Subject: [Gzz-commits] manuscripts/xupdf article.rst
Date: Sat, 15 Feb 2003 13:54:19 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Janne V. Kujala <address@hidden>        03/02/15 13:54:19

Modified files:
        xupdf          : article.rst 

Log message:
        more example appl

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/xupdf/article.rst.diff?tr1=1.135&tr2=1.136&r1=text&r2=text

Patches:
Index: manuscripts/xupdf/article.rst
diff -u manuscripts/xupdf/article.rst:1.135 manuscripts/xupdf/article.rst:1.136
--- manuscripts/xupdf/article.rst:1.135 Sat Feb 15 10:58:40 2003
+++ manuscripts/xupdf/article.rst       Sat Feb 15 13:54:19 2003
@@ -712,7 +712,7 @@
 a combined spatial and xanalogical hypertext structure.
 The idea is to allow the user to create a structure for browsing, 
 annotating and connecting
-PDF files (e.g. academic articles) obtained from other sources.
+PDF files (e.g., academic articles) obtained from other sources.
 
 We take Cells a la Nelson's ZigZag[XXX ref] to be fundamental, point-like nodes
 of the structure. A cell can have two types of relationships, as shown
@@ -731,25 +731,36 @@
 the xanalogically connected cells' contexts as buoys.
 
 The xanalogical structure also allows for explicit xu Links, which are simply
-associations between two enfilades. These are also shown as buoys.
+associations between two *enfilades* (lists of references to fluid media 
units). 
 
-The PDF files obtained from external sources are considered to be images
-from the xanalogical media perspective. 
-In addition to showing the canvases and the cells on them, the primary
-application: browsing PDF files suggests allowing the user to also browse 
-whole PDF scrollblocks.
-
-the view should show in the buoys the important structure, i.e.,
-
-       - pdf-image-blocks should be shown as buoys anchored
-         at the other end of xu-link or at a transclusion show on screen
-       - the blocks for user-entered annotations should not be
-         shown but instead the canvases containing them
+.. These are also shown as buoys.
 
-(note: the same holds for the identity for bg textures).
+.. XXX: permanent vs fluid media
+   *fluid media* should be shortly defined
 
-the canvas structure can easily be extended to support "digital ink"
-annotations
+The PDF files obtained from external sources fit in the xanalogical structure
+as fluid media image blocks, 
+and the content of the annotations made by the user are stored in
+fluid media text blocks.
+In addition to showing the canvases and the cells on them, the primary
+application, browsing PDF files, suggests allowing the user to also browse 
+whole PDF image blocks.
+When browsing a PDF image block, the relevant fragments of xanalogically 
+linked documents and canvases containing a transclusion of the current document
+are shown as buoys.
+
+An important point here is that the user interface 
+only shows the structure that is relevant from the user's point of view. 
+A canvas node shows the original PDFs transcluded in the canvas as buoys,
+but the user is not interested in seeing the constituent media blocks of the 
annotations.
+For the same reason the annotations on a canvas do not have unique background 
textures
+(as the PDF transclusions do), but the whole canvas has a unique background 
texture
+based on its identity.
+
+The left-right orientation of the xanalogically linked buoys is determined by 
+the direction of the xanalogical link. 
+In this prototype, the orientation of a transclusion is fixed so
+that a transcluding canvas is always left of the PDF image block.
 
 .. raw:: latex
 
@@ -786,6 +797,10 @@
        - user editability 
 
        - 
+
+the canvas structure can easily be extended to support "digital ink"
+annotations
+
 
 The idea of making nodes recognizable so when coming
 across a familiar node through an unfamiliar route, it would




reply via email to

[Prev in Thread] Current Thread [Next in Thread]