created mirror
This commit is contained in:
whatever
BIN
Documentation/CyberText/1.png
Normal file
BIN
Documentation/CyberText/1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.5 KiB |
BIN
Documentation/CyberText/3.png
Normal file
BIN
Documentation/CyberText/3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.5 KiB |
BIN
Documentation/CyberText/4.png
Normal file
BIN
Documentation/CyberText/4.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.6 KiB |
11
Documentation/CyberText/Makefile
Normal file
11
Documentation/CyberText/Makefile
Normal file
@@ -0,0 +1,11 @@
|
||||
DIAGRAMS=../wmlinc/article.wml \
|
||||
rank1vert.png rank2vert.png rank3both.png permascroll.png
|
||||
|
||||
all: ct.html ct-ns4.html
|
||||
|
||||
ct.html: ct.wml $(DIAGRAMS)
|
||||
|
||||
ct-ns4.html: ct.wml $(DIAGRAMS)
|
||||
|
||||
include ../lib.mk
|
||||
|
||||
911
Documentation/CyberText/ct-old.wml
Normal file
911
Documentation/CyberText/ct-old.wml
Normal file
@@ -0,0 +1,911 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|
||||
"http://www.w3.org/TR/html4/strict.dtd">
|
||||
<!--
|
||||
This is an article intended for the CyberText yearbook.
|
||||
|
||||
It is written in WML, which is close to HTML while providing
|
||||
some easier ways to create certain constructions, such as
|
||||
the figure tag.
|
||||
|
||||
NOTE! This file uses WML 2.0.1
|
||||
|
||||
PLEASE PLEASE PLEASE don't edit .HTML. Edit .WML!!!! Actually,
|
||||
it's more important for you since your changes will be LOST FOREVER
|
||||
if you edit the .HTML files.
|
||||
-->
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<title>GZigZag: a platorm for Hypertext experiments</title>
|
||||
|
||||
#include '../wmlinc/article.wml'
|
||||
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<substdims>
|
||||
<H1>GZigZag: a platorm for Hypertext experiments</H1>
|
||||
<pre>$Id: ct-old.wml,v 1.1 2000/09/13 14:58:08 tjl Exp $</pre>
|
||||
<grid layout=3x3 spacing=20>
|
||||
<cell> <b>Tuomas Lukka</b> <br>
|
||||
<code>lukka@iki.fi</code><br>
|
||||
Dept. of Mathematical Information Technology <br>
|
||||
University of Jyväskylä
|
||||
</cell>
|
||||
<cell> <b>Vesa Parkkinen</b>
|
||||
</cell>
|
||||
<cell> <b>Katariina Ervasti</b></cell>
|
||||
<cell colspan=3> and </cell>
|
||||
<cell colspan=3> <b>Ted Nelson</b> </cell>
|
||||
</grid>
|
||||
|
||||
<toc>
|
||||
|
||||
|
||||
<p>
|
||||
This is a preprint of an article to appear in the Cybertext Yearbook 2000,
|
||||
edited by Markku Eskelinen & Raine Koskimaa, to be published by Research Unit
|
||||
for Contemporary Culture.
|
||||
All trademarks are the respective trademarks of their owners.
|
||||
|
||||
<warn>
|
||||
|
||||
<abstract>
|
||||
We present a short summary of the ongoing work at the Hyperstructure Group
|
||||
in Jyväskylä University.
|
||||
We are interested in structures that currently dominant software
|
||||
paradigm makes difficult
|
||||
or impossible to express or edit.
|
||||
For example, current operating systems are fixated on files and directories
|
||||
which could be replaced by a much more flexible and more
|
||||
fine-grained structural system.
|
||||
For many applications it would be useful to keep track of where text
|
||||
has been copied from via cut&paste. The current paradigm does not support
|
||||
this but e.g. the Xanadu88 paradigm does.
|
||||
Additionally we are interested in useful visualizations of these structures.
|
||||
|
||||
Most of our work is based on Nelson's ZigZag
|
||||
structure, and we have a prototype program GZigZag on which various
|
||||
variations are tried.
|
||||
</abstract>
|
||||
|
||||
|
||||
<h2>Introduction</h2>
|
||||
|
||||
<p>
|
||||
This article attempts to give an overview of the activities of the
|
||||
Hyperstructure Group at the University of Jyväskylä.
|
||||
The group, founded in fall-99 is focused on a long-term collaboration
|
||||
with Ted Nelson and implementing and testing
|
||||
his ZigZag design and some Xanadu designs.
|
||||
|
||||
<p>
|
||||
The most basic idea
|
||||
underlying all of our work is that today's computers do not
|
||||
allow the user to store and visualize most of the real structure of
|
||||
his information.
|
||||
An interesting feature of this problem is that it is never visible
|
||||
on a small scale, with a few documents or files. On a small scale, the human
|
||||
brain is able to superimpose the true structure of the data on the
|
||||
structure forced by the computer (filenames and directory hierarchies).
|
||||
|
||||
<p>
|
||||
Unfortunately, most software is only tested with small amounts
|
||||
of example data in the prototype stage.
|
||||
If there are hundreds of documents, modified by dozens of people,
|
||||
it is easy to fall into chaos unless the true structure of the data
|
||||
is used. One simple example of such true structure is that of origination(XXX):
|
||||
being able to track all text across several cut&paste operations and
|
||||
visualize this makes it simple to see what rearrangements other people
|
||||
have done on a piece of text after having seen it last time.
|
||||
|
||||
<p>
|
||||
Our work is based on Nelson's ZigZag structure XXXREF, introduced below.
|
||||
We often use the term ``ZigZag structure''. This is an approximation:
|
||||
ZigZag is in a sense a metastructure with which it is easy to model any
|
||||
structure, even structures that would be difficult to model on paper
|
||||
or on usual computer programs without a special program designed explicitly
|
||||
for that structure - for example a family tree.
|
||||
|
||||
|
||||
<h2>Basics of ZigZag</h2>
|
||||
|
||||
<p>
|
||||
ZigZag is a new way of putting information into computers, kind of a crossing
|
||||
between a database, a filesystem, a personal information manager and
|
||||
many others. And even that isn't sufficient to describe it: it's simply
|
||||
something new.
|
||||
There are two important differences between systems built on ZigZag
|
||||
and "normal" computer systems.
|
||||
|
||||
<p>
|
||||
First of all, files and directories are unnecessary (REF paradigms).
|
||||
A traditional filesystem uses filenames to refer to large chunks of
|
||||
information and possibly HTML-like anchors to refer to smaller pieces
|
||||
inside the files. This is a fragile way of representing the information
|
||||
since the only <em>structure</em> stored by the system is the files based
|
||||
on the names - finding which files reference a given file is timeconsuming
|
||||
or requires a pre-indexing scheme.
|
||||
ZigZag is a flexible hyperstructure, allowing different micro-level
|
||||
connections between various pieces of information.
|
||||
In ZigZag all references are two-directional and do not work through
|
||||
user-visible namespaces. Rather, the micro-level two-directional
|
||||
referencing is built right into the system. Changing some of
|
||||
the connections of a piece of information (e.g. renaming the "file" it
|
||||
is inside in the listing) will leave the other connections unchanged.
|
||||
|
||||
<p>XXXXX
|
||||
Second, in ZigZag, <em>all</em>
|
||||
the information about the system will be stored in the same structure.
|
||||
In Windows, there is a filesystem and separately from it, there is the
|
||||
registry. In UNIX, there is just the filesystem with configuration
|
||||
information for applications being represented as text files inside
|
||||
the same filesystem; same tools can be used to edit normal text files
|
||||
and configuration files.
|
||||
ZigZag takes this a step further: all information is in the same fine-grained
|
||||
structure instead of the coarse "file-grained" structure.
|
||||
The same tools can be used to edit any part of data on the system, be it
|
||||
metadata, configuration information, user interface bindings or a spreadsheet
|
||||
or document. XXX selitä paremmin
|
||||
|
||||
<h3> Cells and dimensions </h3>
|
||||
|
||||
<figure img="rank1vert.png" width="250px">
|
||||
Two ranks on <CODE>d.2</CODE>. The rules of the ZZ structure
|
||||
are that each cell may only be on one rank along a given dimension.
|
||||
</figure>
|
||||
|
||||
<figure img="rank2vert.png" width="250px">
|
||||
Two different ranks involving some of the same cells, on
|
||||
a different dimension <CODE>d.1</CODE>
|
||||
</figure>
|
||||
|
||||
<figure img="rank3both.png" width="250px">
|
||||
One possible way to flatten the ranks of the two previous
|
||||
figures to show both dimensions at once. Note how the structure
|
||||
feels locally spreadsheet-like at each cell but globally
|
||||
the connections between the cells must curve when flattened
|
||||
to a 2-D plane.
|
||||
</figure>
|
||||
|
||||
<p>
|
||||
In ZigZag, all data is in cells, much like a spreadsheet.
|
||||
The only important difference is that while a spreadsheet enforces
|
||||
a two- (or possibly three-) -dimensional lattice structure
|
||||
between the cells, ZigZag allows the cells to be connected in
|
||||
a much freer way.
|
||||
|
||||
<p>
|
||||
First of all, the number of dimensions is unlimited.
|
||||
Like on a spreadsheet, a dimension is still structured so that
|
||||
each cell may have one predecessor and one successor on each
|
||||
dimension, and the converse relationship "A is B's successor
|
||||
implies B is A's predecessor" holds.
|
||||
However, there are no restrictions <EM>between</EM> the dimensions
|
||||
for the connections: for example, in the figure,
|
||||
the cell A is located two steps right and three steps up
|
||||
from itself (right = <CODE>d.1</CODE>, down = <CODE>d.2</CODE>).
|
||||
|
||||
<p>
|
||||
To manage the potentially infinite number of dimensions,
|
||||
they are referred to with descriptive strings.
|
||||
The most commonly used dimensions are the three general-purpose
|
||||
dimensions <CODE>d.1</CODE>,
|
||||
<CODE>d.2</CODE> and <CODE>d.3</CODE> and then <CODE>d.clone</CODE>,
|
||||
used for logical duplication of cells and <CODE>d.cursor</CODE>, used
|
||||
for pointing. These uses are mostly a matter of convention.
|
||||
|
||||
<p>
|
||||
The strength of using dimensions instead of names (as in filenames)
|
||||
or numbers (as in pointers or references) to refer to other
|
||||
information is that all references are two-directional.
|
||||
This is an important feature since a large fraction of programming
|
||||
errors in languages such as HTML or C++ have to
|
||||
do with referring to things
|
||||
that are no longer there: on WWW, moving a page or changing the
|
||||
name of an anchor on a page breaks all links to that page or anchor,
|
||||
because the links are strings, naming the previous location.
|
||||
In C++, the references are pointers, i.e. numbers representing
|
||||
memory addresses: if the object being referred to is not any
|
||||
more at the given address, the program crashes.
|
||||
ZigZag introduces the concept of connection
|
||||
on a primitive level and obviates the need for making new systems
|
||||
of referencing for each new program. XXX
|
||||
|
||||
<p>
|
||||
There are many different possible structures with similar
|
||||
capabilities. What makes ZigZag special is the beautiful tradeoff
|
||||
between simplicity and complexity: each cell's neighborhood
|
||||
is limited by the two-neighbours-per-dimension rule but further
|
||||
away the cells can be connected to each other in a free fashion.
|
||||
|
||||
<h3> Rasters and operations: the default UI </h3>
|
||||
|
||||
<p>
|
||||
Given the complexity of the structure, it is usually impossible
|
||||
to see it all at once. Focus&context methods (XXXREF) are
|
||||
useful for simple visualizations: two or more dimensions are
|
||||
chosen, and the cells near the user's focus (cursor) are
|
||||
laid flat on the screen using those dimensions, as far as is
|
||||
possible within the limits of the structure. Since the structure
|
||||
locally resembles a spreadsheet, this visualization is extremely
|
||||
navigable, especially with animation between the motions.
|
||||
|
||||
<p>
|
||||
There are several different possibilities for choosing which cells
|
||||
to place where, called rastersXXX.
|
||||
The vanishing raster, for example, renders all cells
|
||||
up to a given number of steps from the cursor, while
|
||||
gradually reducing the size of the cells. This gives the user a good
|
||||
picture of what is happening slightly further along in the structure
|
||||
and uses the depth perception cues of the human eye to a great
|
||||
advantage. There are also rasters based on rectangular grids,
|
||||
with the two most important ones being the vertical and horizontal,
|
||||
which
|
||||
Examples of these rasters showing a looping structure are shown in
|
||||
XXX.
|
||||
|
||||
<p>
|
||||
Motion is performed through the keyboard or the mouse.
|
||||
Many simple edit operations take directions as parameters,
|
||||
so for instance, creating a new cell leftwards from the current
|
||||
cursor is achieved by pressing <KBD>n</KBD> and then the same
|
||||
key that normally moves the cursor left (<KBD>l</KBD>).
|
||||
|
||||
|
||||
<p>
|
||||
The basic operations include connecting and disconnecting cells,
|
||||
moving the cursor, rotating the view (choosing different dimensions
|
||||
to show on the X, Y and Z axes) and modifying the text in a cell.
|
||||
There are also some more complicated operations that are especially
|
||||
useful, such as hop, an example of which is shown in XXX.
|
||||
|
||||
<h3> Totality of the structure </h3>
|
||||
|
||||
<p>
|
||||
Currently, computers are complicated and messy.
|
||||
Application code has to worry about the structure of data on
|
||||
disk, the structure of data in memory, and the structure of data
|
||||
held by the operating and windowing systems.
|
||||
All these are usually different and cause applications to
|
||||
translate between each other, making the application overtly
|
||||
complicated.
|
||||
|
||||
<p>
|
||||
ZigZag represents all this data in the structure: the structure is
|
||||
persistent and unified.
|
||||
Just as with virtual memory,
|
||||
the program does not need to care whether a cell
|
||||
is in memory or on disk. The logical structure
|
||||
is the same. Of course, to retain an acceptable level of performance,
|
||||
solutions such as transient cells or saving only every <i>n</i>
|
||||
seconds have to be devised but these are optimizations rather
|
||||
than fundamental structure of the application.
|
||||
|
||||
<p>
|
||||
The unification of the structure is more difficult to explain
|
||||
since it reflects a completely different mindset from the ordinary.
|
||||
Ideally, the lower-level code which takes the structure and renders
|
||||
it on screen will have to know only one cell.
|
||||
From this cell, it uses the structure to find what windows are
|
||||
where, which cells to show
|
||||
in the centers (via <CODE>d.cursor</CODE>) and which dimensions
|
||||
to raster along (also via the structure).
|
||||
|
||||
<p>
|
||||
This greatly simplifies programming in ZigZag since <em>all</em>
|
||||
operations can be expressed as alterations to the structure.
|
||||
For example, when the user presses a key to move the cursor left,
|
||||
what happens is that the callback code looks through the structure
|
||||
to see which dimension is currently "left-right", then looks
|
||||
for the cursor and the cell leftwards of it. Finally, the code
|
||||
connects that cell in the structure so that it will thereafter
|
||||
be interpreted as the cursor.
|
||||
|
||||
<p>
|
||||
There are many other benefits as well: since all operations
|
||||
are in the structure, scripting becomes trivial since everything
|
||||
can be achieved simply through modifying the structure.
|
||||
|
||||
<p>
|
||||
Unification of data is not a new idea: the original
|
||||
UNIX philosophy of "everything is a file" contains some of the same
|
||||
spirit. However, the UNIX APIs still force the loading of files
|
||||
into memory into a different representation; in ZigZag, the cell
|
||||
structure is all you need.
|
||||
|
||||
<p>
|
||||
Another previous version of the same basic idea is the
|
||||
popular Model-View-Controller paradigm (XXXREF), where a program
|
||||
with a user interface is split into a model and
|
||||
user interfaces (views and controllers) to that model.
|
||||
This structure makes it simple to add a new view to the same data.
|
||||
ZigZag takes this approach to new heights by providing a
|
||||
<em>global</em> model which all features of the visible display
|
||||
use.
|
||||
|
||||
<h3> Permascrolls </h3>
|
||||
|
||||
<p>
|
||||
Permascrolls are a concept that originated in Xanadu88 (XXX???).
|
||||
The essential idea is that whenever a piece of <DFN>fluid media</DFN>
|
||||
(i.e. text, audio, video, image) enters the system, it is assigned
|
||||
a permanent identifier. After that, all references to that
|
||||
piece of media go through that identifier so that it is easy to find
|
||||
where a particular piece of text has been cut&pasted to, for example.
|
||||
|
||||
<p>
|
||||
Permascrolls seem to be the most easily misunderstood part of
|
||||
Xanadu88 because with today's web, confusing the physical
|
||||
location and the identity of a document is easy. A permascroll
|
||||
does <strong>not</strong> mean that all information should only be
|
||||
stored in one place. It is not an URL, but more like an URI: it
|
||||
is an identifier which is known to map to the same information
|
||||
always. It is also more fine-grained than run-of-the-mill W3C
|
||||
URIs, as it allows referencing any subset of the original up to
|
||||
an atomic level.
|
||||
Most commonly it is not single atoms in the permascroll that
|
||||
are referred to; rather, the reference type is
|
||||
<DFN>span</DFN>, which is a reference to a single contiguous piece
|
||||
of a permascroll.
|
||||
|
||||
<p> XXX SELITÄ VSTREAM HETI
|
||||
In the permascroll paradigm, a particular version
|
||||
of a "document" is represented as a vstream: a list
|
||||
of spans. Editing a document then consists of adding a new
|
||||
span, splitting existing spans, deleting existing spans and
|
||||
rearranging spans.
|
||||
|
||||
<figure img="permascroll.png" width="250px">
|
||||
Two different versions of a document using vstreams
|
||||
and permascrolls. The second version is produced from the
|
||||
first by a rearrangement and an insertion.
|
||||
When comparing the two versions side by side, it is
|
||||
easy to determine
|
||||
which parts are the same and simply have been rearranged
|
||||
by comparing the references to the permascroll.
|
||||
</figure>
|
||||
|
||||
<p>
|
||||
ZigZag supports permascolls by allowing a cell to contain
|
||||
a <DFN>span</DFN> (a reference to a single
|
||||
contiguous piece of the permascroll).
|
||||
A rank of cells on a dimension (usually <CODE>d.2</CODE>)
|
||||
can then be interpreted
|
||||
(see next section) as a virtual text (or other media) stream.
|
||||
|
||||
<p>
|
||||
To reiterate, a permascroll is not a place:
|
||||
it is a state of mind, in which you keep track of what all
|
||||
information copied or cut&pasted originally was.
|
||||
For example, it is planned that in a future version of GZigZag
|
||||
the user will be able to send an email with some cells
|
||||
as well as the parts of the permascroll that is referred to
|
||||
by those cells. The recipient's computer can then
|
||||
store those pieces of the permascroll and notice if any other
|
||||
references to them exist.
|
||||
In fact, permascrolls are excellent candidates for caching since
|
||||
the identifiers to the content are indeed permanent, unlike
|
||||
on WWW where the content of a cached URL can change at any time.
|
||||
|
||||
|
||||
<p>
|
||||
Another application where permascrolls show their power is
|
||||
comparison: most utilities used for text comparison (e.g. the
|
||||
unix <CODE>diff</CODE> utility) do a reasonably good job if the
|
||||
user is simply adding or removing or changing small pieces of
|
||||
text. However, such tools have great troubles with rearrangement,
|
||||
exactly because of the lacking text model where only the content,
|
||||
not the origin is stored. Thus, a rearrangement usually shows
|
||||
up as large insertions and deletions, which is actually exactly
|
||||
what it is, in the primitive text model.
|
||||
|
||||
<p>
|
||||
It is possible to overcome some of this problem by writing
|
||||
more and more refined algorithms for finding similar texts but
|
||||
once we get to phrase-level elements, they become useless since
|
||||
the same phrases can occur again and again in a document.
|
||||
|
||||
<p>
|
||||
With permascrolls, rearranging a text file is not about moving
|
||||
the text content - it's about moving <em>pointers</em> to the
|
||||
content. So two different revisions, the latter of which has
|
||||
been rearranged, still point to the same spans of text in the
|
||||
permascroll. Now, visualizing the differences becomes easy:
|
||||
all that is necessary is to point out to the user which pieces
|
||||
of text are stored in the same place in the permascroll.
|
||||
See Figure XXX below, where this is demonstrated.
|
||||
|
||||
<p>
|
||||
This feature may seem like unimportant but in projects with more
|
||||
than one worker and much rearrangement of the manuscript
|
||||
it can be truly invaluable for finding where a certain part of the
|
||||
previous version of the manuscript ended up.
|
||||
|
||||
<h3> Alternative visualizations: applitudes </h3>
|
||||
|
||||
<p>
|
||||
Although interesting, the above structure and visualizations
|
||||
would fit most applications rather poorly. However, given the
|
||||
basic ZZ structure it is simple to define new visualizations.
|
||||
|
||||
<p>
|
||||
Taken together, a visualization and operations are referred
|
||||
to as an <dfn>applitude</dfn>,
|
||||
as opposed to the traditional term application
|
||||
since all the data is still in the same structure and other
|
||||
operations can be used to edit this data and these operations
|
||||
can be used to edit other data.
|
||||
|
||||
<p>
|
||||
For example, a vstream is a kind of an applitude: there is a
|
||||
clearly defined internal structure and special operations for
|
||||
the vstream for inserting and deleting characters.
|
||||
There is also a good visualization of a text vstream: simply
|
||||
the characters in a paragraph (formatting capabilities will
|
||||
be added later).
|
||||
The default cell-based visualization and the natural vstream
|
||||
visualization for a small piece of text is shown in XXX.
|
||||
Note how the colored cursor is shown in both panes.
|
||||
|
||||
<p>
|
||||
The interesting thing about applitudes is that they can be designed
|
||||
to be connected to each other in a more fine-grained fashion than
|
||||
current embedding frameworks such as Bonobo, KParts, or OLE/COM.
|
||||
|
||||
|
||||
|
||||
|
||||
<h2>Some Textual Applitudes of ZigZag</h2>
|
||||
|
||||
<p>
|
||||
In this section, we'll look at some functioning applitudes.
|
||||
As explained in the previous section, the strength of ZigZag lies in that
|
||||
all these applitudes can be used together fairly easily since all the data
|
||||
is stored openly in the ZZ structure.
|
||||
|
||||
<p>
|
||||
One important function that GZigZag provides for all applitudes is
|
||||
<em>animation</em>. This works by associating a cell with all "things"
|
||||
that are rendered on the screen.
|
||||
When two "things" in subsequent keyframes (i.e. the fully rastered frames)
|
||||
are associated with each other, the system generates as many interpolated
|
||||
frames between them as the speed of the host machine allows.
|
||||
The time between keyframes is estimated from the interval between
|
||||
the user's keystrokes: the system attempts to be ready 100ms before
|
||||
the user strikes the next key. This gives the system a fluid, responsive
|
||||
feel while allowing smooth, slow animation if the user is moving slower.
|
||||
|
||||
<p>
|
||||
An example of such animation can be found in XXX ANIMATED GIF ON
|
||||
GZIGZAG PAGES
|
||||
|
||||
<h3>Text cloud - <strong>real</strong> cut&paste</h3>
|
||||
|
||||
<p>
|
||||
One of the points Nelson has made in several talks (XXX??? on paper?)
|
||||
is that the term "cut&paste", as used in the computer field, is
|
||||
a really bad choice of words. Originally cut&paste meant physically
|
||||
cutting a text into pieces, rearranging the pieces and glueing
|
||||
them together. This seems a little similar to what the computers
|
||||
do.
|
||||
|
||||
<p>
|
||||
However, there is a crucial difference: in physical cut&paste,
|
||||
the text can be cut up into as many pieces as desired;
|
||||
all the pieces are visible all the time; the pieces can be slowly
|
||||
rearranged into the optimum order in a parallel fashion.
|
||||
Indeed, when the text is cut up, the actual <em>data model</em>
|
||||
of the text
|
||||
is changed from the single text stream to a cloud of text
|
||||
fragments.
|
||||
|
||||
<p>
|
||||
Most current computer programs (XXX Exceptions?) force the user
|
||||
to stay within the formal one-stream text model all the time during
|
||||
editing, except for a single piece of text cut onto the "clipboard",
|
||||
which is not seen.
|
||||
This is why several people (REF: private communication) seem
|
||||
to use a second window next to the main one to hold fragments.
|
||||
This, of course, has several disadvantages: the fragments are
|
||||
stored separately from the main body of text, the fragments still
|
||||
have to be stored in the one-stream text model and the system is
|
||||
rather clumsy. Of course, some people are able to write near-perfect
|
||||
prose in near-perfect order.
|
||||
|
||||
<p>
|
||||
One of the interesting differences between this system
|
||||
and the dominant paradigm is the way of selecting text.
|
||||
In most current systems, selecting text is performed by
|
||||
painting, i.e. pressing the mouse button at one end of the
|
||||
span being selected and releasing the mouse button at
|
||||
the other end. In the TextCloud demo, text is never really
|
||||
"selected" in the same way: instead, the user can make any
|
||||
number of <dfn>cuts</dfn> into the document using the right
|
||||
mouse button. Then, when the user presses the left mouse button
|
||||
on some text and drags, the text is separated at the neighbouring
|
||||
cuts to allow the user move a single piece of text.
|
||||
|
||||
<p>
|
||||
Already Nelson's original mockup pictures about Xanadu
|
||||
(see XXX (pic on WWW))
|
||||
include transpointing windows, i.e. windows which show the
|
||||
connections of their respective contents graphically.
|
||||
These connections can be either transclusions or links. In this
|
||||
article, we concentrate on transclusions.
|
||||
|
||||
<p>
|
||||
GZigZag is probably (XXX???) the first system to implement such
|
||||
transpointing with beams: an earlier Xanadu client Pyxi by XXX
|
||||
shows transclusions by colors but does not do transpointing.
|
||||
The TextCloud applitude is a good place to see the transpointing beams
|
||||
in action: simply copying (i.e. dragging with Shift-MouseButton1 instead
|
||||
of just MouseButton1) a vstream creates a transclusion and the
|
||||
beam appears. Then, when editing one (or both) of the streams by
|
||||
cutting&pasting text the beams remain
|
||||
connected; this is because the beams are really connected to the actual
|
||||
text content, not just the external object.
|
||||
|
||||
<p>
|
||||
The TextCloud is a simple model and its current implementation clear
|
||||
limitations: all text must be stored in this one area and the size
|
||||
of the text cannot be changed.
|
||||
Also, it does not interface well with the other parts of the system.
|
||||
It is simply one step on the way towards the full system, in order
|
||||
to test one user interface aspect of it.
|
||||
|
||||
|
||||
<h3>Editing longer documents using cells</h3>
|
||||
|
||||
<p>
|
||||
A different way for editing longer documents is through putting
|
||||
vstream fragments of the documents in ZZ cells which are then rendered
|
||||
in a raster. All the structural capabilities of ZigZag are
|
||||
then in use for rearranging the pieces.
|
||||
|
||||
<p>
|
||||
This being ZigZag, note that "putting fragments in ZZ cells"
|
||||
does not a literal inclusion but an <i>interpreted inclusion</i>:
|
||||
the view has a special raster which knows how to look for
|
||||
the vstream to include in a cell.
|
||||
When the space is being rastered,
|
||||
|
||||
<p>
|
||||
Unfortunately this demo is not yet finished so we cannot offer
|
||||
a screenshot.
|
||||
|
||||
<h3>Hypertext without lexias (XXX?)</h3>
|
||||
|
||||
<p>
|
||||
Hypertext has come to mean "WWW-like" in many places:
|
||||
a paradigm where the user is presented with one lexiXXX,
|
||||
performs a selection, for example clicking with the mouse,
|
||||
and is taken to another lexiXXX.
|
||||
|
||||
<p>
|
||||
GZigZag makes it possible to easily create a wealth of flexible
|
||||
visualizations that do not use such fixed screenfuls of text.
|
||||
This is because GZigZag is built in a modular fashion and makes
|
||||
it easy to describe a new visualization.
|
||||
|
||||
<p>
|
||||
For example, let's start with a text model that contains
|
||||
simply paragraphs of text, one after another.
|
||||
|
||||
|
||||
<h3>Email or forums with coordinates</h3>
|
||||
|
||||
<p>
|
||||
In this section, we come once again to a problem which
|
||||
does not exist for small data sets. If there are
|
||||
only 10 messages in
|
||||
a mailbox, it does not matter in the least how incredibly
|
||||
bad the mail reading program is:
|
||||
humans can still manage since they can remember
|
||||
and overlay the true structure on top of the rigid and unnatural
|
||||
structure imposed
|
||||
by the mail reader program.
|
||||
|
||||
<p>
|
||||
However, consider the linux-kernel email list or
|
||||
corresponding high-volume newsgroups on the usenet.
|
||||
Most programs for reading news or email are based on the assumption
|
||||
that the reader wants to read all or most of the incoming messages -
|
||||
a natural assumption stemming from the original volume of the forums.
|
||||
However, with time the number of messages in a forum has grown
|
||||
unmanageably yet programs mostly offer only rigid pre-selection systems
|
||||
such as killfiles which remove all messages with a given subject
|
||||
or sender from the view.
|
||||
|
||||
|
||||
<p>
|
||||
ZigZag and FloatingWorld provide an interesting alternative
|
||||
which we have so far had time to only scratch the surface of.
|
||||
When a mailbox or a newsgroup is incorporated into the structure
|
||||
correctly, it is simple to write interesting visualizations
|
||||
that show some of the emails.
|
||||
|
||||
<p>
|
||||
The structure underlying the email applitude is described in
|
||||
FIGUREXXX.
|
||||
|
||||
<p>
|
||||
The first, simplest visualization FIGUREXXX
|
||||
is simply the traditional
|
||||
mailbox visualization, offered by many programs such as Pine, XXX.
|
||||
This simply shows some of the most relevant header fields of
|
||||
messages on each line, arranged vertically in the mailbox order.
|
||||
Already here ZigZag has several tricks up its sleeve. For example,
|
||||
a message may be stored in several "folders" (lists), either
|
||||
by using different dimensions for different folders or by
|
||||
cloning the headcell of the
|
||||
message onto different ranks on the same dimension.
|
||||
Another trick here is that it is easy to see which folders
|
||||
a given message has been connected to, since all connections are
|
||||
two-directional. This is an advantage caused by the fact that ZZ
|
||||
considers the message to be an entity rather than a stream of
|
||||
characters that can be copied but has no <em>identity</em>
|
||||
(like emails in normal email folder files).
|
||||
|
||||
<p>
|
||||
Sorting the emails is of course possible, either by presorting
|
||||
and making a rank of them and using that
|
||||
or by post-sorting at each time they are shown.
|
||||
For sorting, ZZ offers an interesting user interface: when the
|
||||
user moves the active cell <em>horizontally</em>, the list of
|
||||
mails is shown sorted according to that cell.
|
||||
XXX Mailboxes, many folders per email!!!!!
|
||||
XXX Good argument for postsorting or cached postsorting.
|
||||
XXX Notifications
|
||||
|
||||
<p>
|
||||
|
||||
<p>
|
||||
Now, one interesting thing that ZZ offers is multiple windows
|
||||
with different views whose cursors are bound together (using
|
||||
the cursor-cargo mechanism; see the ZZ Spec XXXREF).
|
||||
All the views above have one "active" cell. We can have several
|
||||
useful views visible at the same time, which stay in lockstep with
|
||||
each other.
|
||||
|
||||
|
||||
|
||||
<p>
|
||||
The FloatingWorld model offers an alternative: messages
|
||||
or icons of messages can be shown in a two- or three-dimensional
|
||||
coordinate system.
|
||||
|
||||
<p>
|
||||
Such a system is trivial to implement in a general fashion
|
||||
using ZigZag since the homogeneous structure makes it simple
|
||||
to specify paths to obtain coordinates through, whereas if
|
||||
using a traditional programming language, it would be all too easy
|
||||
to restrict the world of possible coordinates to some set
|
||||
that is easily specifiable in the structure that was chosen.
|
||||
|
||||
<p>
|
||||
Additionally, normal email programs or HyperMail (XXXREF)
|
||||
-like HTML indexers treat the messages as their own, making it
|
||||
almost impossible to link the discussions into the places where
|
||||
they would belong: for example, linking the discussion leading up
|
||||
to a particular decision in a standard (say XHTML) into the place
|
||||
in the standard would be an invaluable aid to those trying to
|
||||
understand afterwards how something is supposed to work.
|
||||
|
||||
<p>
|
||||
Consider, for instance, a document such as the Kernel Traffic
|
||||
weekly newsletter (XXXREF) which summarizes the main discussion threads
|
||||
on the Linux-Kernel mailing list that week.
|
||||
|
||||
XXX transclusions, etc.
|
||||
|
||||
<h3>Editing hyperliterature with nodes</h3>
|
||||
<p>
|
||||
- editing trad. hyperliterature easier: visualize the STRUCTURE of
|
||||
the whole work, then rendered into HTML
|
||||
|
||||
<h3>Scientific publishing using Xanadu hypertext</h3>
|
||||
|
||||
<p>
|
||||
A long-known problem in scientific publishing on paper media is
|
||||
that bibliographic references are always backwards in time, while
|
||||
it would often be more interesting for the reader to
|
||||
know the future references, i.e. either articles that refer
|
||||
to the current one or articles that the author has deemed
|
||||
interesting enough to refer to at a later date from publication.
|
||||
|
||||
<p>
|
||||
Now, in the Xanadu model, quoting is equivalent to linking because
|
||||
of transclusions.
|
||||
|
||||
<p>
|
||||
Transclusions may seem foreign as an instrument of quoting and
|
||||
responding to a selected portion of an article. However, they
|
||||
are actually quite close to another widely used paradigm: quoting
|
||||
when replying to an email. The only addition here is that
|
||||
the quoted parts (which are somehow visually indicated) are
|
||||
not copies but transclusions from the original article. Because of
|
||||
this, they are actively connected to the originals in an implicit
|
||||
two-way link.
|
||||
|
||||
<p>
|
||||
The system of moderation used on sites such as <code>slashdot.org</code>
|
||||
is surprisingly similar to the scientific refereeing process.
|
||||
The privilege of moderating other users' comments is granted
|
||||
to established members of the community (members whose previous
|
||||
moderations have been approved by other members), the process
|
||||
is anonymous and determines on whether users get to see the comment.
|
||||
However, there are important differences:
|
||||
<ul>
|
||||
<li> The moderation is not "accept/reject" but rather
|
||||
"leave as is/ increase score/ decrease score".
|
||||
<li> Comments are not deleted even if they have a low score;
|
||||
users browsing the site can set their comment limit
|
||||
themselves to determine what minimum rating for comments
|
||||
they wish to see.
|
||||
<li> A user has a default score based on his/her earlier
|
||||
success in posting comments
|
||||
<li> Comments are usually short notices on
|
||||
</ul>
|
||||
Upon consideration, some of these points are quite applicable
|
||||
to scientific publishing as well. Specifically, the "letters
|
||||
to the editor" section of scientific journals seems to be the
|
||||
closest that print journals can come to this kind of convenience.
|
||||
|
||||
<p>
|
||||
Indeed, this sort of publishing system could create a far more
|
||||
interactive scientific <em>discourse</em>.
|
||||
For example, a user can choose which links he wishes to see
|
||||
when reading an article: refereed links, all links, links by certain
|
||||
persons etc.
|
||||
|
||||
|
||||
|
||||
|
||||
<h2>The Code</h2>
|
||||
|
||||
<p>
|
||||
GZigZag, which is the program that is shown in all of the screenshots
|
||||
in this article, is free software. It is distributed under the FSF's
|
||||
Lesser General Public License (LGPL) and is available on SourceForge.
|
||||
|
||||
In the language of the free software community, "Patches accepted".
|
||||
|
||||
<h2>Conclusions</h2>
|
||||
<p>
|
||||
|
||||
<h2>Acknowledgements</h2>
|
||||
<p>
|
||||
|
||||
<h2>References</h2>
|
||||
<p>
|
||||
http://www.acm.org/cacm/AUG96/antimac.htm
|
||||
|
||||
<h2>Glossary</h2>
|
||||
|
||||
<p>
|
||||
This article uses many terms that are most likely unfamiliar to the reader.
|
||||
We attempt to summarize the most important ones below.
|
||||
|
||||
<hr>
|
||||
<dl>
|
||||
<dt>ZigZag structure / space
|
||||
<dd> A simple structure, based on <i>cells</i> and <i>dimensions</i>
|
||||
which the user is able to easily shape into any desired
|
||||
structure. All interrelated pieces of information can be
|
||||
close to each other on some dimension.
|
||||
<dt>cell
|
||||
<dd> The smallest unit of information in ZigZag.
|
||||
A cell can contain a text string or
|
||||
a single span in a permascroll; the separation is
|
||||
because a text string can be edited but a span can only
|
||||
be lengthened or shortened: no characters can be
|
||||
inserted. Cells are connected to each other along
|
||||
dimensions.
|
||||
<dt>dimension
|
||||
<dd> Connecting cells along dimensions is what ZigZag is
|
||||
about. Locally, dimensions work just like on a spreadsheet:
|
||||
each cell can be connected to one cell in the positive
|
||||
direction and to one cell in the negative direction
|
||||
along each dimension. However, there are no global constraints
|
||||
between the dimensions.
|
||||
|
||||
<dt>rank
|
||||
<dd> A rank on a dimension D is simply a set of cells that are
|
||||
connected to each other on D. A given cell can only
|
||||
be on one rank on a given dimension.
|
||||
|
||||
<dt>raster
|
||||
<dd> A simple visualization of the ZZ structure.
|
||||
A raster is given a cell to place in the center of
|
||||
the view and a set of dimensions chosen for the coordinate
|
||||
axes X, Y and possibly Z, and it starts at the center cell
|
||||
and places other cells on the screen according to simple
|
||||
rules.
|
||||
There are several different rasters.
|
||||
</dl>
|
||||
<hr>
|
||||
<dl>
|
||||
|
||||
<dt>FloatingWorld
|
||||
<dd> Ted Nelson's design built on top of ZigZag structure,
|
||||
based on <i>flobs</i>.
|
||||
<dt>flob
|
||||
<dd> A multi-dimensional flying object. That is, an entity
|
||||
representing something that may have any number of
|
||||
<i>flob coordinates</i>. For example, an email's sender is one
|
||||
flob coordinate, its subject another.
|
||||
|
||||
</dl>
|
||||
<hr>
|
||||
<dl>
|
||||
|
||||
|
||||
<dt>Xanadu88
|
||||
<dd> A hypertext system, finished in 1988, which works by
|
||||
stable <i>fluid media</i> content instead of URL-like pointers.
|
||||
<dt>fluid media
|
||||
<dd> Any media types that can be subdivided.
|
||||
Text, audio, video, images.
|
||||
<dt>permascroll
|
||||
<dd> A storage philosophy for fluid media where
|
||||
each smallest unit (e.g. character of text)
|
||||
is assigned a permanent identifier when
|
||||
it first enters the system. Of course,
|
||||
references to the smallest units usually happen
|
||||
through <i>span</i>s for efficiency.
|
||||
<dt>span
|
||||
<dd> A (reference to a) contiguous section of the permascroll.
|
||||
<dt>vstream
|
||||
<dd> A list of spans that describe a virtual stream of
|
||||
fluid media. A "document" or one version of a document.
|
||||
Modifying a document does not modify the permascroll, except
|
||||
by appending new inserted characters. Instead, the spans
|
||||
of the vstream are modified: split apart, new spans
|
||||
inserted etc.
|
||||
<dt>transclusion
|
||||
<dd> The inclusion of the same material in a permascroll in
|
||||
two different documents. One of the fundamentals of the Xanadu88
|
||||
model is that it is efficient to search for transclusions
|
||||
of a given span.
|
||||
<dt>transpointing windows
|
||||
<dd> Windows on a computer screen that show the connections or
|
||||
transclusions between each other.
|
||||
|
||||
</dl>
|
||||
|
||||
<h2>SCRATCH</h2>
|
||||
|
||||
<p>
|
||||
<b>
|
||||
This section contains rejected pieces of text that may still
|
||||
have some interest.</b>
|
||||
|
||||
<p>
|
||||
Naturally, if desired, dimensions can be used to construct
|
||||
systems analogous to files and directories: for instance,
|
||||
a number of cells going down <code>d.2</code> can contain names
|
||||
and these cells are connected on some dimension to the content
|
||||
for that "file".
|
||||
|
||||
<p>
|
||||
This is somewhat analogous
|
||||
to the hyperbolic visualization
|
||||
for graphs (XXXREF): hyperbolic space also looks locally like
|
||||
Euclidean space but there is more "room" because the correspondence
|
||||
to Euclidean space does not hold over distances.
|
||||
An interesting similarity between the two is the volume of balls:
|
||||
in hyperbolic space, the volume enclosed in a ball grows exponentially
|
||||
with the radius and the same is true for ZigZag - <em>if</em>
|
||||
desired; ZigZag cells can also be arranged in a less complex
|
||||
fashion where the growth of the volume of balls is more restricted.
|
||||
|
||||
<hr>
|
||||
</substdims>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
<!--
|
||||
vim: set syntax=html :
|
||||
-->
|
||||
|
||||
275
Documentation/CyberText/ct.wml
Normal file
275
Documentation/CyberText/ct.wml
Normal file
@@ -0,0 +1,275 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>GZigZag - A Platform for Cybertext Experiments</title>
|
||||
<meta name="keywords" content="GZigZag, ZigZag, Ted Nelson">
|
||||
</head>
|
||||
<body bgcolor="#ffffff" link="#cc0033" vlink="#888888" alink=
|
||||
"#ffffff">
|
||||
<blockquote>
|
||||
<p>
|
||||
<i>GZigZag - A Platform for Cybertext Experiments</i><br>
|
||||
Tuomas Lukka & Katariina Ervasti
|
||||
</p>
|
||||
|
||||
<p>ABSTRACT</p>
|
||||
|
||||
<p>This article describes GZigZag, which is currently the main project of the Hyperstructure Group
|
||||
at the univ. of Jyväskylä. GZigZag is an implemention of ZigZag, a computer paradigm invented
|
||||
by Ted Nelson. The paradigm abandons many currently central concepts, such as folders, files and
|
||||
applications, and instead offers a more flexible way to arrange information. Already at this early stage
|
||||
of development GZigZag has advantages compared with other computer systems.</p>
|
||||
|
||||
<p>1. INTRODUCTION</p>
|
||||
|
||||
<p>"COMPUTERS ARE FUNDAMENTALLY BROKEN" lectures Ted Nelson (7 February 2000). Unlike
|
||||
many other critics, he also offers ideas for improving the situation. Some of his ideas are
|
||||
currently being implemented by the Hyperstructure Group at the university of Jyväskylä, Finland.
|
||||
In this article we present a short summary of our ongoing work.</p>
|
||||
|
||||
<p>1.1 Defamiliarization of files, folders and applications</p>
|
||||
|
||||
<p>Nelson (1999a) offers many reasons for why users face difficulties with present PCs. This article
|
||||
only includes a short attempt to defamiliarize (<a href="#1">1</a>) folders, applications and files from the user's point of view.
|
||||
This is not an easy task, because folders, applications and files are one of the first things a beginner
|
||||
is taught and are not often questioned.</p>
|
||||
|
||||
<p>Hierarchical directories, also referred to as 'folders', were invented to help finding the right file
|
||||
among many files (Nelson 1999a). Let us say that in September -99 a writer has been writing an
|
||||
article dealing with the impossible nature of her cat Vilma. In September 2000 she wants to find the
|
||||
article again to edit it for a new purpose. In order to find the article, she opens a folder named 'Vilma'.
|
||||
The folder includes approximately twenty files, which are either versions of the final article or include
|
||||
some ideas the writer has considered worth writing down at some point of the writing process. The
|
||||
files have names such as <i>vilma3.doc</i>, <i>vilma4.doc</i>, <i>vilfoo.doc</i> and <i>vilmaprob.doc</i>. By the time the
|
||||
writer finished the article she had no time to make an index explaining the contents of each file. Finally,
|
||||
after opening and closing several files, she succeeds in finding the right file and starts working. When
|
||||
editing, she suddenly remembers that she had a slightly different version of a paragraph in another
|
||||
document. Once again, she has to start opening and closing files to find the right file.</p>
|
||||
|
||||
<p>Applications, then, are used for performing different tasks with the computer (Nelson 1999a). Problems
|
||||
arise when a user wants to use the same information in many applications. For example, a multimedia
|
||||
author, who has manipulated sound with SoundEdit, might want to use the sound in a multimedia
|
||||
presentation made with Macromedia Director. Since applications do not support all file formats,
|
||||
he has to find out which sound file formats Macromedia Director supports. After a study of sound
|
||||
file formats, he saves the file in a suitable format and imports it to Macromedia Director. Then, if he
|
||||
later views the presentation and wants to find a different sound sample, which he remembers recording
|
||||
in the same session, it will not be easy. This is because there is simply no connection between
|
||||
the Macromedia Director file and the original sound sample nor between the original sound sample
|
||||
and the second sample from the same session.</p>
|
||||
|
||||
<p>These examples demonstrate how the files and folders model of storing information is insufficient:
|
||||
it does not allow the users to track the conceptual relationships between related information or
|
||||
versions. Files, folders and applications are easy to understand but do not need to be, as
|
||||
Nelson (lecture, 30 August 2000) explains, fundamental concepts of software. The above
|
||||
problems could be solved by designing software differently, starting from different assumptions.</p>
|
||||
|
||||
<p>1.2 Traditions of Bush and Engelbart</p>
|
||||
|
||||
<p>Vannevar Bush and Douglas Engelbart developed ideas for tools that would improve the
|
||||
working conditions of people who perform complicated tasks in the complicated world. Bush, who
|
||||
had noticed the explosion of information already in the 1940's, is famous for proposing <i>Memex</i>,
|
||||
a "mechanized private file and library" designed to help individual scientists store and handle the
|
||||
growing amounts of information needed in their work (Bush 1945). Engelbart, the developer of NLS,
|
||||
a tool for collaborative work, writes about augmentation of man's intellect, which has been the goal
|
||||
of his work with computers. By augmenting man's intellect he means "increasing the capability
|
||||
of a man to approach a complex problem situation, gain comprehension to suit his particular
|
||||
needs and to derive solutions to problems" (Engelbart 1962). The purpose of our work is similar
|
||||
to Bush's and Engelbart's: we want to facilitate the production and arrangement of information
|
||||
by creating, as Nelson (1999b) expresses it, "a high-power personal and media system, with editing
|
||||
and presentation systems that expand the state of art".</p>
|
||||
|
||||
<p>2. BASICS OF ZIGZAG</p>
|
||||
|
||||
<p>Defining ZigZag is difficult, because ZigZag is so different from any software in the currently
|
||||
dominant computer paradigm. It is not an application but neither is it an operating system or
|
||||
a platform. It is a new way of putting information into computers, a cross between a database,
|
||||
a filesystem, a personal information manager and many others, and even that is not sufficient
|
||||
to describe it. ZigZag is simply something new and different.</p>
|
||||
|
||||
<p>3.1.1 Cells, Dimensions, Views and Applitudes</p>
|
||||
|
||||
<p>A ZigZag structure consists of cells and dimensions. A <b>cell</b> is the basic unit of information
|
||||
in ZigZag. A cell can contain an information unit of any kind, for example text (e.g. "Vilma"), an
|
||||
image (e.g. a picture of Vilma) or sound (e.g. "Meow" by Vilma). Cells can be connected with
|
||||
each other along <b>dimensions</b>, which are referred to with names such as <i>d.1</i> or <i>d.cursor</i>. On
|
||||
each dimension, each cell can have two neighbours: a predecessor and a successor. The number
|
||||
of dimensions is not restricted, and it is easy to create new dimensions. For example, if Ville wants
|
||||
to comment on many different cells, he could use <i>d.Ville-comment</i> for connecting his comments
|
||||
to the cells.</p>
|
||||
|
||||
<p>Figure 1 shows a simple structure. In the Figure, cells are represented by rectangles and neighbours
|
||||
along a dimension by a line.</p>
|
||||
|
||||
<p><a href="vilma.png">Figure 1</a>.<i>Seven cells, connected to each other along the two dimensions d.1 and d.2</i></p>
|
||||
|
||||
<p>There are several different visualizations (views) of the ZigZag structure. The views range from
|
||||
<b>general view</b>s that are useful for looking at all kinds of structures to <b>specific view</b>s
|
||||
that are useful for only one particular kind of structure. For example, Fig. 2 shows a generic view of a structure
|
||||
that represents a schedule of a day. This view can show any kind of structure in a fairly reasonable
|
||||
way, by showing the cells arranged along the dimensions and their text contents.</p>
|
||||
|
||||
<p><a href="kello.png">Figure 2</a>.<i>The most important events of a day in a general view</i></p>
|
||||
|
||||
<p>Figure 3, then, shows a specific view of the same structure. The underlying data is exactly the
|
||||
same, but the specific view designed especially for the purpose interprets the structure and draws
|
||||
the events in a more visual manner. Looking at another structure through this view would not make
|
||||
sense because the view is designed especially for this structure.</p>
|
||||
|
||||
<p><a href="kello-o.png">Figure 3</a>.<i>The same events in a specific view</i></p>
|
||||
|
||||
<p>Combining the specific view such as the schedule view above with special operations for editing
|
||||
such a structure, for example dragging the start and end times with the mouse makes an applitude.
|
||||
Thus, an <b>applitude</b> consists of views and operations designed for a particular purpose. Even though
|
||||
the term 'applitude' resembles the term 'application', there is an important difference: in ZigZag
|
||||
nothing is separate, and applitudes, unlike applications, can be combined with each other, as the
|
||||
example of the next section shows.</p>
|
||||
|
||||
<p>3.1.2 Example: Address Book and Family Tree in GZigZag</p>
|
||||
|
||||
<p>One of the first examples Nelson (pers.com., 25 August 2000) has used to demonstrate
|
||||
ZigZag is the <i>Holm Family Demo</i>, a family tree prepared for his talk at the University of Oslo
|
||||
to show how he is related to one of the professors of the university. Here, a variant of Nelson's
|
||||
original example is used, combined with an address book.</p>
|
||||
|
||||
<p>The structure of the address book is simple: it is a list of names and addresses . The names are
|
||||
listed along <i>d.2</i> in alphabetical order. The addresses are connected to the names along <i>d.1</i>.
|
||||
Figure 4 shows the (incomplete) address book in the row view.</p>
|
||||
|
||||
<p><a href="1.png">Figure 4</a>. <i>The address book in the row view</i>.</p>
|
||||
|
||||
<p>Since the list of relatives is long, only a subset of it can be seen on the screen at a time. In Figure 4
|
||||
the cursor is on the cell 'cousin 1'. Moving the cursor down would cause more cells below
|
||||
the 'grandfather 2' cell on <i>d.2</i> to become visible.</p>
|
||||
|
||||
<p>Next, the address book is combined with the family tree, which is represented by a slightly more
|
||||
complicated structure, shown in Figure 3.</p>
|
||||
|
||||
<p><a href="3.png">Figure 5</a>. <i>One family of the family tree in the row view</i></p>
|
||||
|
||||
<p>The two dimensions <i>d.marriage</i> and <i>d.children</i> are used to represent the family tree. Siblings
|
||||
are connected along <i>d.children</i>, and married couples along <i>d.marriage</i> (<a href="#2">2</a>). An extra cell ("+") is used
|
||||
on <i>d.marriage</i> to make the structure symmetric, and the list of children from the marriage on
|
||||
<i>d.children</i> starts from that cell. Figures 5 and 6 show two different views of the structure.
|
||||
The row view, as Figure 5 shows, enables dealing with one family at a time. The vanishing
|
||||
view shown in Figure 6 gives a better picture of the family tree as a whole.</p>
|
||||
|
||||
<p><a href="4.png">Figure 6</a>. <i>The family tree in the vanishing view</i>
|
||||
|
||||
<p>It is important to realize that the same cells are used to represent the relatives in both the
|
||||
address book and the family tree, and that the connections related to the two applitudes are
|
||||
along different dimensions. In the default views only two or three dimensions (x,y,z) can be
|
||||
shown at the screen at a time. As it can be seen on Figure 4, the dimensions used for viewing
|
||||
the address book are x=<i>d.1</i> and y=<i>d.2</i>. Rotating the dimensions to
|
||||
x=<i>d.marriage</i> and y=<i>d.children</i> shows the family tree, as in Figure 5.</p>
|
||||
|
||||
<p>The address book and the family tree could be combined with further applitudes. For example,
|
||||
a cell representing a person could also be connected to photographs and emails having to do
|
||||
with that person. Simply all related information could be connected so that it is easily accessible.
|
||||
A consequence of the ZigZag structure is that all connections are two-directional, which means
|
||||
that navigating between related information is easy.</p>
|
||||
|
||||
<p>3.2 Utility of GZigZag</p>
|
||||
|
||||
<p>ZigZag offers several advantages compared with existing computer systems. To begin with, as Nelson (pers.com., 25 August 2000) usually
|
||||
remarks after showing his <i>Holm Family Demo</i>, "we did not create a genealogy program". Modeling a complicated structure such as the family
|
||||
tree on usual computer systems would require creating a specific program for that purpose. Modeling a complicated structure using
|
||||
GZigZag requires only creating of new cells and connecting them along dimensions.</p>
|
||||
|
||||
<p>Remarkably, there are no separate files and applications in ZigZag. As seen above, the same
|
||||
cells can simultaneously be part of different structures without any restrictive boundaries.
|
||||
Thus, a multimedia author using GZigZag would not have the same problem as the multimedia
|
||||
author described in 2.1. Connecting the same cells in various structures also facilitates updating
|
||||
information. Updating the last name of a newly married aunt in the family tree and address book
|
||||
requires updating only one cell.</p>
|
||||
|
||||
<p>In addition to this, ZigZag is a more flexible way to arrange information than the conventional
|
||||
files and folders model. A certain piece of information is found by following the connections
|
||||
that the user has previously made based on his associations. Hence, a user of GZigZag does
|
||||
not need to remember file names in order to find the right information. The writer looking for
|
||||
a document containing an interesting paragraph about Vilma (described in 2.1) could simply
|
||||
follow a connection made previously. Also, moving between different versions of the same
|
||||
paragraph is simple when using the Xanadu content model.</p>
|
||||
|
||||
<p>Finally, ZigZag separates the structure and visualization of information. This is somewhat
|
||||
similar to HTML 4.0 and CSS, but ZigZag generalizes this: all structures and all visualizations
|
||||
are possible. The same GZigZag structure can be used in different media from mobile
|
||||
phones to the immersive virtual reality of the CAVE, because different visualizations
|
||||
can be constructed to take full advantage of each medium.</p>
|
||||
|
||||
<p>3. CONCLUSION AND FUTURE WORK</p>
|
||||
|
||||
<p>The primary purpose of this article, which is the first publication of the Hyperstructure Group,
|
||||
is to present a short summary of our ongoing work, especially GZigZag. This is not a simple
|
||||
task because we are dealing with such a different view of the computer. Indeed, the difficulty
|
||||
of explaining the new ideas to people has been one of the main problems of Nelson's broader
|
||||
Xanadu project.</p>
|
||||
|
||||
<p>In the near future we are focused on developing a stable, working GZigZag on the Java
|
||||
platform and cellular language Clang, which would make programming easier. We are also
|
||||
planning a network protocol for exchanging cells between computers
|
||||
and developing applitudes for several purposes in order to learn more about the system.</p>
|
||||
|
||||
<p>We believe that Nelson's ideas are creative, excellent, original and that they should finally be
|
||||
understood and implemented. Our long-term goal is to develop a computer system we would
|
||||
like to use ourselves. ;-)</p>
|
||||
|
||||
<p>Everyone interested in our project is welcome to test and work on the current version of GZigZag,
|
||||
which can be downloaded from <a href="http://gzigzag.sourceforge.net">the project's homepage</a>. GZigZag is a free software project: the
|
||||
source code is released under the LGPL license and interested parties are welcome to join
|
||||
our mailing list. By the time this article is published, we hope to have released the first stable
|
||||
version (recommended for non-developers). "Patches", as people of the free software
|
||||
community say, and any other ideas of developing the system are gladly accepted.</p>
|
||||
|
||||
<p>ACKNOWLEDGEMENTS</p>
|
||||
|
||||
<p>We would like to thank Theodor Holm Nelson and Marlene Mallicoat for our collaboration.
|
||||
We would also like to thank the other members of the Hyperstructure Group: Tuukka Hastrup,
|
||||
Antti-Juhani Kaijanaho and Vesa Parkkinen.</p>
|
||||
|
||||
<p>FOOTNOTES</p>
|
||||
|
||||
<p><a name="1">1 According to Fowler (1986: 35, 42) defamiliarization is the use of a strategy to force us to look at familiar things in a critical way, to see the
|
||||
absurdity of a familiar object. Criticism, as Fowler sees it, is not a negative practice. The basic motivation for criticism is "healthily sceptical
|
||||
inquisitiveness", which can give a stimulus to developing things for better (Fowler 1986: 34).</a></p>
|
||||
|
||||
<p><a name="2">2 If a person has been married several times, a mechanism called cloning is used to represent this in the structure. However,
|
||||
this is beyond the scope of this article.</a></p>
|
||||
|
||||
<p>REFERENCES</p>
|
||||
|
||||
<p><u>Print References</u></p>
|
||||
|
||||
<p>Fowler, Roger (1986). <i>Linguistic Criticism</i>. Oxford: Oxford University Press.</p>
|
||||
|
||||
<p><u>Electronic References</u></p>
|
||||
|
||||
<p>Bush, Vannevar (1945). <i>As We May Think</i>. <br>
|
||||
Available in the Internet: <a href="http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm">
|
||||
http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm</a></p>
|
||||
|
||||
<p>Engelbart, Douglas (1962). <i>Augmenting Human Intellect: A Conceptual Framework. </i> <br>
|
||||
Available in the Internet: <a href="http://www.histech.rwth-aachen.de/www/quellen/engelbart/ahi62index.html">
|
||||
http://www.histech.rwth-aachen.de/www/quellen/engelbart/ahi62index.html</a></p>
|
||||
|
||||
<p>Nelson, Ted (1999a). <i>Ted Nelson's Computer Paradigm, Expressed as One-Liners.</i> <br>
|
||||
Available in the Internet: <a href="http://www.sfc.keio.ac.jp/~ted/TN/WRITINGS/TCOMPARADIGM/tedCompOneLiners.html">
|
||||
http://www.sfc.keio.ac.jp/~ted/TN/WRITINGS/TCOMPARADIGM/tedCompOneLiners.html</a></p>
|
||||
|
||||
<p>Nelson, Ted (1999b). <i>ZX Views.</i><br>
|
||||
Available in the Internet: <a href="http://www.xanadu.com/FW99/ZXviews.html">
|
||||
http://www.xanadu.com/FW99/ZXviews.html</a></p>
|
||||
|
||||
<p><u>Other References</u>
|
||||
|
||||
<p>Nelson, Ted. Lectures at the University of Jyväskylä. 7 February 2000 & 30 August 2000.</p>
|
||||
|
||||
<p>Nelson, Ted. Conversation with the authors. 25 August 2000.</p>
|
||||
|
||||
</blockquote>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
Documentation/CyberText/email.dia
Normal file
BIN
Documentation/CyberText/email.dia
Normal file
Binary file not shown.
BIN
Documentation/CyberText/kello-o.png
Normal file
BIN
Documentation/CyberText/kello-o.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
Documentation/CyberText/kello.png
Normal file
BIN
Documentation/CyberText/kello.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.2 KiB |
BIN
Documentation/CyberText/permascroll.dia
Normal file
BIN
Documentation/CyberText/permascroll.dia
Normal file
Binary file not shown.
601
Documentation/CyberText/rank1vert.dia
Normal file
601
Documentation/CyberText/rank1vert.dia
Normal file
@@ -0,0 +1,601 @@
|
||||
<?xml version="1.0"?>
|
||||
<diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
|
||||
<diagramdata>
|
||||
<attribute name="background">
|
||||
<color val="#ffffff"/>
|
||||
</attribute>
|
||||
<attribute name="paper">
|
||||
<composite type="paper">
|
||||
<attribute name="name">
|
||||
<string>#A4#</string>
|
||||
</attribute>
|
||||
<attribute name="tmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="bmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="lmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="rmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="is_portrait">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
<attribute name="scaling">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="fitto">
|
||||
<boolean val="false"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</diagramdata>
|
||||
<layer name="Background" visible="true">
|
||||
<object type="Standard - Box" version="0" id="O0">
|
||||
<attribute name="obj_pos">
|
||||
<point val="1,1"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,0.95;5.05,10.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="1,1"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="9"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O1">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,2"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,1.2069;3.403,2.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#A#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,2"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O2">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,2.7069;3.403,3.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#B#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O3">
|
||||
<attribute name="obj_pos">
|
||||
<point val="1,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,2.45;5.05,2.55"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="1,2.5"/>
|
||||
<point val="5,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O4">
|
||||
<attribute name="obj_pos">
|
||||
<point val="5,4"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,3.95;5.05,4.05"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="5,4"/>
|
||||
<point val="1,4"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O5">
|
||||
<attribute name="obj_pos">
|
||||
<point val="1,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,5.45;5.05,5.55"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="1,5.5"/>
|
||||
<point val="5,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O0" connection="3"/>
|
||||
<connection handle="1" to="O0" connection="4"/>
|
||||
</connections>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O6">
|
||||
<attribute name="obj_pos">
|
||||
<point val="1,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,8.45;5.05,8.55"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="1,8.5"/>
|
||||
<point val="5,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O7">
|
||||
<attribute name="obj_pos">
|
||||
<point val="1,7"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,6.95;5.05,7.05"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="1,7"/>
|
||||
<point val="5,7"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O8">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,4.2069;3.403,5.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#C#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O9">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,5.7069;3.403,6.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#D#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O10">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,8"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,7.2069;3.403,8.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#E#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,8"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O11">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,8.7069;3.403,9.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#F#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O12">
|
||||
<attribute name="obj_pos">
|
||||
<point val="6,1"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="5.15,0.15;6.85,10.85"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="6,1"/>
|
||||
<point val="6,10"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<attribute name="line_width">
|
||||
<real val="0.1"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow">
|
||||
<enum val="3"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow_length">
|
||||
<real val="0.8"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow_width">
|
||||
<real val="0.8"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O13">
|
||||
<attribute name="obj_pos">
|
||||
<point val="7,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="5.991,4.7069;8.009,5.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#d.2#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="7,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O14">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,2.45;13.05,8.55"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="9,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="6"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O15">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,4"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,3.95;13.05,4.05"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="9,4"/>
|
||||
<point val="13,4"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O16">
|
||||
<attribute name="obj_pos">
|
||||
<point val="13,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,2.45;13.05,2.55"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="13,2.5"/>
|
||||
<point val="9,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O14" connection="2"/>
|
||||
<connection handle="1" to="O14" connection="0"/>
|
||||
</connections>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O17">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,5.45;13.05,5.55"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="9,5.5"/>
|
||||
<point val="13,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O14" connection="3"/>
|
||||
<connection handle="1" to="O14" connection="4"/>
|
||||
</connections>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O18">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,7"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,6.95;13.05,7.05"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="9,7"/>
|
||||
<point val="13,7"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O19">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,5.45;13.05,5.55"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="9,5.5"/>
|
||||
<point val="13,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O14" connection="3"/>
|
||||
<connection handle="1" to="O14" connection="4"/>
|
||||
</connections>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O20">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,2.7069;11.403,3.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#G#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O21">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,4.2069;11.403,5.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#H#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O22">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,5.7069;11.403,6.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#I#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O23">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,8"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,7.2069;11.403,8.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#J#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,8"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
</layer>
|
||||
</diagram>
|
||||
375
Documentation/CyberText/rank2vert.dia
Normal file
375
Documentation/CyberText/rank2vert.dia
Normal file
@@ -0,0 +1,375 @@
|
||||
<?xml version="1.0"?>
|
||||
<diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
|
||||
<diagramdata>
|
||||
<attribute name="background">
|
||||
<color val="#ffffff"/>
|
||||
</attribute>
|
||||
<attribute name="paper">
|
||||
<composite type="paper">
|
||||
<attribute name="name">
|
||||
<string>#A4#</string>
|
||||
</attribute>
|
||||
<attribute name="tmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="bmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="lmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="rmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="is_portrait">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
<attribute name="scaling">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="fitto">
|
||||
<boolean val="false"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</diagramdata>
|
||||
<layer name="Background" visible="true">
|
||||
<object type="Standard - Box" version="0" id="O0">
|
||||
<attribute name="obj_pos">
|
||||
<point val="1,1"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,0.95;5.05,2.55"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="1,1"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O1">
|
||||
<attribute name="obj_pos">
|
||||
<point val="1,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,2.45;5.05,4.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="1,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O2">
|
||||
<attribute name="obj_pos">
|
||||
<point val="1,4"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.95,3.95;5.05,5.55"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="1,4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O3">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,1"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,0.95;13.05,2.55"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="9,1"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O4">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,2.45;13.05,4.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="9,2.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O5">
|
||||
<attribute name="obj_pos">
|
||||
<point val="6,1"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="5.15,0.15;6.85,6.35"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="6,1"/>
|
||||
<point val="6,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<attribute name="line_width">
|
||||
<real val="0.1"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow">
|
||||
<enum val="3"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow_length">
|
||||
<real val="0.8"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow_width">
|
||||
<real val="0.8"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O6">
|
||||
<attribute name="obj_pos">
|
||||
<point val="7,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="5.991,2.7069;8.009,3.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#d.1#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="7,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O7">
|
||||
<attribute name="obj_pos">
|
||||
<point val="-8,12"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="-8,11.2069;-8,12.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>##</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="-8,12"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O8">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,2"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,1.2069;3.403,2.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#A#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,2"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O9">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,2.7069;3.403,3.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#G#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O10">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,2"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,1.2069;11.403,2.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#F#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,2"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O11">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,2.7069;11.403,3.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#J#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,3.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O12">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.597,4.2069;3.403,5.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#D#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="3,5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
</layer>
|
||||
</diagram>
|
||||
745
Documentation/CyberText/rank3both.dia
Normal file
745
Documentation/CyberText/rank3both.dia
Normal file
@@ -0,0 +1,745 @@
|
||||
<?xml version="1.0"?>
|
||||
<diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
|
||||
<diagramdata>
|
||||
<attribute name="background">
|
||||
<color val="#ffffff"/>
|
||||
</attribute>
|
||||
<attribute name="paper">
|
||||
<composite type="paper">
|
||||
<attribute name="name">
|
||||
<string>#A4#</string>
|
||||
</attribute>
|
||||
<attribute name="tmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="bmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="lmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="rmargin">
|
||||
<real val="2.82"/>
|
||||
</attribute>
|
||||
<attribute name="is_portrait">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
<attribute name="scaling">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="fitto">
|
||||
<boolean val="false"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</diagramdata>
|
||||
<layer name="Background" visible="true">
|
||||
<object type="Standard - Box" version="0" id="O0">
|
||||
<attribute name="obj_pos">
|
||||
<point val="4,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="3.95,5.45;8.05,7.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="4,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O1">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,5.45;13.05,7.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="9,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O2">
|
||||
<attribute name="obj_pos">
|
||||
<point val="4,7"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="3.95,6.95;8.05,8.55"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="4,7"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O3">
|
||||
<attribute name="obj_pos">
|
||||
<point val="14,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="13.95,5.45;18.05,7.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="14,5.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O4">
|
||||
<attribute name="obj_pos">
|
||||
<point val="4,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="3.95,8.45;8.05,10.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="4,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O5">
|
||||
<attribute name="obj_pos">
|
||||
<point val="14,7"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="13.95,6.95;18.05,8.55"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="14,7"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O6">
|
||||
<attribute name="obj_pos">
|
||||
<point val="14,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="13.95,8.45;18.05,10.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="14,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O7">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,7"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,6.95;13.05,8.55"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="9,7"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O8">
|
||||
<attribute name="obj_pos">
|
||||
<point val="9,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="8.95,8.45;13.05,10.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="9,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Box" version="0" id="O9">
|
||||
<attribute name="obj_pos">
|
||||
<point val="19,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="18.95,8.45;23.05,10.05"/>
|
||||
</attribute>
|
||||
<attribute name="elem_corner">
|
||||
<point val="19,8.5"/>
|
||||
</attribute>
|
||||
<attribute name="elem_width">
|
||||
<real val="4"/>
|
||||
</attribute>
|
||||
<attribute name="elem_height">
|
||||
<real val="1.5"/>
|
||||
</attribute>
|
||||
<attribute name="show_background">
|
||||
<boolean val="true"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O10">
|
||||
<attribute name="obj_pos">
|
||||
<point val="6,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="5.597,5.7069;6.403,6.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#A#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="6,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O11">
|
||||
<attribute name="obj_pos">
|
||||
<point val="6,8"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="5.597,7.2069;6.403,8.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#B#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="6,8"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O12">
|
||||
<attribute name="obj_pos">
|
||||
<point val="6,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="5.597,8.7069;6.403,9.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#C#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="6,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O13">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,5.7069;11.403,6.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#G#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O14">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,8"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,7.2069;11.403,8.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#H#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,8"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O15">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.597,8.7069;11.403,9.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#I#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O16">
|
||||
<attribute name="obj_pos">
|
||||
<point val="16,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="15.597,5.7069;16.403,6.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#D#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="16,6.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O17">
|
||||
<attribute name="obj_pos">
|
||||
<point val="16,8"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="15.597,7.2069;16.403,8.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#E#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="16,8"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O18">
|
||||
<attribute name="obj_pos">
|
||||
<point val="16,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="15.597,8.7069;16.403,9.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#F#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="16,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O19">
|
||||
<attribute name="obj_pos">
|
||||
<point val="21,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="20.597,8.7069;21.403,9.7069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#J#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="21,9.5"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O20">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,4"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.15,3.15;21.85,4.85"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="3,4"/>
|
||||
<point val="21,4"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<attribute name="line_width">
|
||||
<real val="0.1"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow">
|
||||
<enum val="3"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow_length">
|
||||
<real val="0.8"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow_width">
|
||||
<real val="0.8"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O21">
|
||||
<attribute name="obj_pos">
|
||||
<point val="3,4"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="2.15,3.15;3.85,11.35"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="3,4"/>
|
||||
<point val="3,10.5"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<attribute name="line_width">
|
||||
<real val="0.1"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow">
|
||||
<enum val="3"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow_length">
|
||||
<real val="0.8"/>
|
||||
</attribute>
|
||||
<attribute name="end_arrow_width">
|
||||
<real val="0.8"/>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O22">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,4"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="9.991,3.2069;12.009,4.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#d.1#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="11,4"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - Text" version="0" id="O23">
|
||||
<attribute name="obj_pos">
|
||||
<point val="2,8"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="0.991,7.2069;3.009,8.2069"/>
|
||||
</attribute>
|
||||
<attribute name="text">
|
||||
<composite type="text">
|
||||
<attribute name="string">
|
||||
<string>#d.2#</string>
|
||||
</attribute>
|
||||
<attribute name="font">
|
||||
<font name="Courier"/>
|
||||
</attribute>
|
||||
<attribute name="height">
|
||||
<real val="1"/>
|
||||
</attribute>
|
||||
<attribute name="pos">
|
||||
<point val="2,8"/>
|
||||
</attribute>
|
||||
<attribute name="color">
|
||||
<color val="#000000"/>
|
||||
</attribute>
|
||||
<attribute name="alignment">
|
||||
<enum val="1"/>
|
||||
</attribute>
|
||||
</composite>
|
||||
</attribute>
|
||||
</object>
|
||||
<object type="Standard - BezierLine" version="0" id="O24">
|
||||
<attribute name="obj_pos">
|
||||
<point val="6,10"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="5.95,0.45;16.05,16.55"/>
|
||||
</attribute>
|
||||
<attribute name="bez_points">
|
||||
<point val="6,10"/>
|
||||
<point val="6,16.5"/>
|
||||
<point val="16,0.5"/>
|
||||
<point val="16,5.5"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O4" connection="6"/>
|
||||
<connection handle="3" to="O3" connection="1"/>
|
||||
</connections>
|
||||
</object>
|
||||
<object type="Standard - BezierLine" version="0" id="O25">
|
||||
<attribute name="obj_pos">
|
||||
<point val="11,10"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="10.95,1.45;21.05,16.05"/>
|
||||
</attribute>
|
||||
<attribute name="bez_points">
|
||||
<point val="11,10"/>
|
||||
<point val="11,16"/>
|
||||
<point val="21,1.5"/>
|
||||
<point val="21,8.5"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O8" connection="6"/>
|
||||
<connection handle="3" to="O9" connection="1"/>
|
||||
</connections>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O26">
|
||||
<attribute name="obj_pos">
|
||||
<point val="8,6.25"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="7.95,6.2;9.05,6.3"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="8,6.25"/>
|
||||
<point val="9,6.25"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O0" connection="4"/>
|
||||
<connection handle="1" to="O1" connection="3"/>
|
||||
</connections>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O27">
|
||||
<attribute name="obj_pos">
|
||||
<point val="14,6.25"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="12.95,6.2;14.05,6.3"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="14,6.25"/>
|
||||
<point val="13,6.25"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O3" connection="3"/>
|
||||
<connection handle="1" to="O1" connection="4"/>
|
||||
</connections>
|
||||
</object>
|
||||
<object type="Standard - Line" version="0" id="O28">
|
||||
<attribute name="obj_pos">
|
||||
<point val="18,9.25"/>
|
||||
</attribute>
|
||||
<attribute name="obj_bb">
|
||||
<rectangle val="17.95,9.2;19.05,9.3"/>
|
||||
</attribute>
|
||||
<attribute name="conn_endpoints">
|
||||
<point val="18,9.25"/>
|
||||
<point val="19,9.25"/>
|
||||
</attribute>
|
||||
<attribute name="numcp">
|
||||
<int val="1"/>
|
||||
</attribute>
|
||||
<connections>
|
||||
<connection handle="0" to="O6" connection="4"/>
|
||||
<connection handle="1" to="O9" connection="3"/>
|
||||
</connections>
|
||||
</object>
|
||||
</layer>
|
||||
</diagram>
|
||||
BIN
Documentation/CyberText/vilma.png
Normal file
BIN
Documentation/CyberText/vilma.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.3 KiB |
Reference in New Issue
Block a user