[Commit] papers/twin-ols2005 Makefile, 1.2, 1.3 ols.sty, 1.2, 1.3 twin-ols2005.tex, 1.2, 1.3

Keith Packard commit at keithp.com
Fri May 13 00:05:31 PDT 2005


Committed by: keithp

Update of /local/src/CVS/papers/twin-ols2005
In directory home.keithp.com:/tmp/cvs-serv10868

Modified Files:
	Makefile ols.sty twin-ols2005.tex 
Log Message:
Replace dvipdf with direct invocation of gs to create the pdf file
with the right paper size (A4 just isn't used around here)

Replace thebibliography environment with one suitable for this paper format

Replace usages of scshape with textsc as html output gets very confused by
scshape.

Shrink '@' to match cloister x height.

Html generator is confused by \foo\ style.  Replace with \foo~ which does
almost the same thing.

Add reference to CVS repository.


Index: Makefile
===================================================================
RCS file: /local/src/CVS/papers/twin-ols2005/Makefile,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- Makefile	13 May 2005 02:58:41 -0000	1.2
+++ Makefile	13 May 2005 07:05:28 -0000	1.3
@@ -38,8 +38,8 @@
 	latex $(TOP) || true
 	latex $(TOP)
 
-$(TOP).pdf: $(TOP).dvi
-	dvipdf $(TOP).dvi $@
+$(TOP).pdf: $(TOP).ps
+	gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=$@ $(TOP).ps
 
 #$(TOP).pdf: $(TEXFILES) $(PDFFILES)
 #	pdflatex $(TOP) || true

Index: ols.sty
===================================================================
RCS file: /local/src/CVS/papers/twin-ols2005/ols.sty,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ols.sty	13 May 2005 02:58:41 -0000	1.2
+++ ols.sty	13 May 2005 07:05:28 -0000	1.3
@@ -63,11 +63,35 @@
 {\normalbaselineskip}{\center\large\it\setlength{\baselineskip}{15.4pt}}}
 
 %make subsection titles italic in the text size
-%\def\subsection{\@startsection {subsection}{2}{\z@}{\normalbaselineskip}
-%{\normalbaselineskip}{\center\it}}
 \def\subsection{\@startsection {section}{1}{\z@}{\normalbaselineskip}
 {\normalbaselineskip}{\center\normalsize\it\setlength{\baselineskip}{12pt}}}
 
+% replace the bibliography list environment to provide something
+% that looks like the kitemize environment above.
+\renewenvironment{thebibliography}[1]
+     {\section*{\refname}%
+      \@mkboth{\MakeUppercase\refname}{\MakeUppercase\refname}%
+      \list{{\rm \@arabic\c at enumiv}}%
+      {     \setlength{\parskip}{0in}
+	    \setlength{\itemsep}{\baselineskip}
+	    \setlength{\parsep}{0in}
+	    \setlength{\topsep}{0in}
+	    \setlength{\partopsep}{0in}
+	    \settowidth\labelwidth{\@biblabel{#1}}%
+            \setlength{\leftmargin}{0in}
+	    \setlength{\labelsep}{.3em}
+            \usecounter{enumiv}%
+            \let\p at enumiv\@empty
+            \renewcommand\theenumiv{\@arabic\c at enumiv}}%
+      \sloppy
+      \clubpenalty4000
+      \@clubpenalty \clubpenalty
+      \widowpenalty4000%
+      \sfcode`\.\@m}
+     {\def\@noitemerr
+       {\@latex at warning{Empty `thebibliography' environment}}%
+      \endlist}
+
 \makeatother
 
 % \let\fx=\footnoterule

Index: twin-ols2005.tex
===================================================================
RCS file: /local/src/CVS/papers/twin-ols2005/twin-ols2005.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- twin-ols2005.tex	13 May 2005 02:58:41 -0000	1.2
+++ twin-ols2005.tex	13 May 2005 07:05:28 -0000	1.3
@@ -14,16 +14,20 @@
 \def\half{\hbox{\hspace{.15em}\raisebox{0.28em}{\scalebox{.7}{1}}\hspace{-.11em}\raisebox{0.2em}{\scalebox{.73}{/}}\hspace{-.1em}{\scalebox{.7}{2}}}}
 
 % For fonts with small caps
-\def\twin{{\scshape twin}}
-\def\Twin{T{\scshape win}}
-\def\pda{{\scshape pda}}
-\def\PDA{{\scshape pda}}
-\def\cpu{{\scshape cpu}}
-\def\cpus{{\scshape cpu}s}
-\def\mb{{\scshape mb}}
-\def\kb{{\scshape kb}}
+\def\twin{\textsc{twin}}
+\def\Twin{T\textsc{win}}
+\def\pda{\textsc{pda}}
+\def\PDA{\textsc{pda}}
+\def\cpu{\textsc{cpu}}
+\def\cpus{\textsc{cpu}s}
+\def\mb{\textsc{mb}}
+\def\kb{\textsc{kb}}
+\def\ascii{\textsc{ascii}}
+\def\lcd{\textsc{lcd}}
+\def\oled{\textsc{oled}}
+\def\tms{\textsc{tms}}
 
-\newenvironment{kitemize}{\list{\raisebox{0.2em}{\tiny $\bullet$}}%
+\newenvironment{kitemize}{\list{\raisebox{0.2em}{\tiny$\bullet$}}%
 			 {\setlength{\parskip}{0in}
 			  \setlength{\itemsep}{0in}
 			  \setlength{\parsep}{0in}
@@ -41,8 +45,9 @@
 			 \item\relax}
 			{\endlist}
 
+
 \pagestyle{myheadings}
-\markboth{{\rm Keith Packard\hfill}}{{\rm \hfill\Twin: A Window System for `Sub-\PDA' Devices}}
+\markboth{{\rm Keith Packard\hfill}}{{\rm\hfill\Twin: A Window System for `Sub-\PDA' Devices}}
 \renewcommand{\thepage}{}
 
 \begin{document}
@@ -56,8 +61,8 @@
 
 \author{
 Keith Packard \\
-{\normalsize HP Cambridge Research Labs}\\
-{\normalsize keithp at keithp.com}\\
+{\normalsize HP Cambridge Research Laboratory}\\
+{\normalsize keithp{\footnotesize @}keithp.com}\\
 } % end author section
 
 \maketitle
@@ -70,55 +75,55 @@
 \noindent With embedded systems gaining high resolution displays and
 powerful \cpus,
 the desire for sophisticated graphical user interfaces can be realized in
-even the smallest of systems. While the \cpu\ power available for a given
+even the smallest of systems. While the \cpu~power available for a given
 power budget has increased dramatically, these tiny systems remain severely
 memory constrained. This unique environment presents interesting challenges
 in graphical system design and implementation. To explore this particular
 space, a new window system, \twin, has been developed. Using ideas from
-modern window systems in larger environments, \twin\ offers overlapping
+modern window systems in larger environments, \twin~offers overlapping
 translucent windows, anti-aliased graphics and scalable fonts in a total
 memory budget of 100\kb.
 
 \section{Motivation}
 
 \noindent Researchers at the HP Cambridge Research Laboratory are building a
-collection of sub-{\scshape pda} sized general purpose networked computers
+collection of sub-\pda~sized general purpose networked computers
 as platforms for dissociated, distributed computing research. These devices
-include small {\scshape lcd} or {\scshape oled} screens, a few buttons and
+include small \lcd~or \oled~screens, a few buttons and
 occasionally some kind of pointing device. 
 
-One of the hardware platforms under development consists of a {\scshape
-tms}320 series
-{\scshape dsp} (200{\scshape mh}z, fixed point, 384{\scshape
-kb} on-chip {\scshape ram}), 8{\scshape mb} of flash
-memory, an Agilent {\scshape adns}-2030 Optical mouse sensor, a Zigbee (802.15.4)
-wireless networking interface and an Epson {\scshape l}2{\scshape
-f}50176{\scshape t}00 {\scshape lcd} screen (1.1", 120
-x 160 color). At 200{\scshape mh}z, this processor is capable of significant
-computation, but 384{\scshape kb} holds little data. 
+One of the hardware platforms under development consists of a {{\scshape
+tms}}320 series
+\textsc{dsp} (200\textsc{mh}z, fixed point, 384{\scshape
+kb} on-chip \textsc{ram}), 8\textsc{mb} of flash
+memory, an Agilent \textsc{adns}-2030 Optical mouse sensor, a Zigbee (802.15.4)
+wireless networking interface and an Epson \textsc{l}2{\scshape
+f}50176\textsc{t}00 \textsc{lcd} screen (1.1", 120
+x 160 color). At 200\textsc{mh}z, this processor is capable of significant
+computation, but 384\textsc{kb} holds little data. 
 
 In contrast, early graphical user interfaces for desktop platforms was more
-constrained by available \cpu\ performance than by memory. Early
+constrained by available \cpu~performance than by memory. Early
 workstations had at least a million pixels and a megabyte of physical memory
-but only about 1 {\scshape mips} of processing power. Software in this
+but only about 1 \textsc{mips} of processing power. Software in this
 environment was much more a matter of what could be made fast enough than
 what would fit in memory. 
 
-While the X Window System\cite{x} has been ported to reasonably small
+While the X window system\cite{x} has been ported to reasonably small
 environments\cite{itsy}, a minimal combination of window system server,
 protocol library and application toolkit consumes on the order of 4 to 
-5\mb\ of memory, some ten times more than is available in the target platform.
+5\mb~of memory, some ten times more than is available in the target platform.
 
 Given the new challenge of providing a graphical user interface in these
 tiny devices, it seemed reasonable to revisit the whole graphical
-architecture and construct a new system from the ground up. The \twin\ window
-system (for {\scshape t}iny {\scshape win}dow system) is the result of this
+architecture and construct a new system from the ground up. The \twin~window
+system (for \textsc{t}iny \textsc{win}dow system) is the result of this
 research.
 
 \section{Assumptions}
 
 \noindent The hardware described above can be generalized to provide a
-framework within which the \twin\ architecture fits. By focusing on
+framework within which the \twin~architecture fits. By focusing on
 specific hardware capabilities and limitations, the window system will more
 completely utilize those limited resources. Of course, over-constraining
 the requirements can limit the potential target environments. Given the
@@ -127,11 +132,11 @@
 
 The first assumption made was that little-to-no graphics acceleration is
 available within the frame buffer, and that the frame buffer is attached to
-the \cpu\ through a relatively slow link. This combination means that most
-drawing should be done with the \cpu\ in local memory, and not directly to the
+the \cpu~through a relatively slow link. This combination means that most
+drawing should be done with the \cpu~in local memory, and not directly to the
 frame buffer. This has an additional benefit in encouraging synchronized
 screen updates where intermediate rendering results are never made visible
-to the user. If the \cpu\ has sufficient on-chip storage, this design can
+to the user. If the \cpu~has sufficient on-chip storage, this design can
 also reduce power consumption by reducing off-chip data references.
 
 The second limitation imposed was to require a color screen with fixed color
@@ -142,15 +147,15 @@
 available, there is no requirement that the system support dithering or
 other color-approximating schemes.
 
-Finally, \twin\ assumes that the target machine provides respectable 
-\cpu\ performance. This reduces the need to cache intermediate rendering
+Finally, \twin~assumes that the target machine provides respectable 
+\cpu~performance. This reduces the need to cache intermediate rendering
 results, like glyph images for text. Having a homogeneously performant
-target market means that \twin\ need support only one general performance
-class of drawing operations. For example, \twin\ supports only anti-aliased
-drawing; non-antialiased drawing would be faster, but the \cpus\ supported
+target market means that \twin~need support only one general performance
+class of drawing operations. For example, \twin~supports only anti-aliased
+drawing; non-antialiased drawing would be faster, but the \cpus~supported
 by twin are required to be fast enough to make this irrelevant.
 
-The combined effect of these environmental limitations means that \twin\ can
+The combined effect of these environmental limitations means that \twin~can
 provide significant functionality with little wasted code. Window systems
 designed for a range of target platforms must often generalize functionality
 and expose applications to variability which will not, in practice, ever
@@ -170,7 +175,7 @@
 assigns different constant Z values to each object so that the windows
 appear to be stacked on top of one another.
 
-\Twin\ provides this traditional metaphor through an architecture similar to
+\Twin~provides this traditional metaphor through an architecture similar to
 the X window system Composite extension in that all applications draw to
 off-screen image buffers which are then combined and placed in the physical
 frame buffer. This has many advantages:
@@ -178,7 +183,7 @@
 \item
 Rendering performance is decoupled from frame buffer performance. As the
 embedded frame buffer controllers include a private frame buffer, the
-bandwidth available to the \cpu\ for that memory is quite restricted.
+bandwidth available to the \cpu~for that memory is quite restricted.
 Decoupling these two operations means that rendering can operate at full
 main memory speed instead of the reduced video controller memory speed
 \item
@@ -201,16 +206,16 @@
 
 In the model supported in the X window system by the Composite extension, an
 external application is responsible for directing the system in constructing
-the final screen image from the off-screen window contents. \Twin\ has a
+the final screen image from the off-screen window contents. \Twin~has a
 simpler model where window contents are composited together through a fixed
 mechanism. This, of course, eliminates significant complexity but at the
 cost of also eliminating significant generality.
-\Twin\ does not, and is not likely to, support immersive 3{\scshape d}
+\Twin~does not, and is not likely to, support immersive 3\textsc{d}
 environments.
 
 \section{Graphics}
 
-\noindent The availability of small color screens using either {\scshape lcd} or {\scshape oled}
+\noindent The availability of small color screens using either \textsc{lcd} or \textsc{oled}
 technologies combined with sufficient \cpu power have encouraged the
 inclusion of a rendering model designed to take maximal advantage of the
 limited pixel resolution available. Anti-aliasing and sub-pixel addressing
@@ -219,7 +224,7 @@
 well as permit arbitrary object shapes to minimize unused space on the
 screen.
 
-The complete drawing stack provides a simacrulum of the {\scshape pdf} 1.4
+The complete drawing stack provides a simacrulum of the \textsc{pdf} 1.4
 drawing environment, complete with affine transforms, color image blending
 and PostScript path construction and drawing tools. Leveraging this classic
 and well known environment ensures both that developers will feel comfortable
@@ -227,32 +232,32 @@
 
 \section{Pixel Manipulation}
 
-\noindent \Twin\ uses the basic rendering operational model from
+\noindent \Twin~uses the basic rendering operational model from
 \hbox{8\half}\cite{pike:draw}, the window system developed for the Plan 9
 operating system by Cox and Pike, the same as used in the X render
 extension\cite{render:2001}. This three-operand rendering operator forms the
 base upon which all drawing is built:
 
 \begin{kcenter}
-dst = (src {\scshape in} mask) {\scshape over}|{\scshape source} dst
+dst = (src \textsc{in} mask) \textsc{over}|\textsc{source} dst
 \end{kcenter}
 
-The {\scshape in}, {\scshape over} and {\scshape source} operators are as
+The \textsc{in}, \textsc{over} and \textsc{source} operators are as
 defined by Porter and Duff.\cite{porterduff:1984} By manipulating the
 operands, this single operator performs all of the basic rendering
-facilities in the \twin\ system. Geometric operations are performed by
+facilities in the \twin~system. Geometric operations are performed by
 constructing a suitable mask operand based on the shape of the geometry.
 
-Pixel data are limited in \twin\ to three formats, 8 bit alpha, 32 bit
-{\scshape argb} and 16 bit {\scshape rgb}. Limiting formats in this way
+Pixel data are limited in \twin~to three formats, 8 bit alpha, 32 bit
+\textsc{argb} and 16 bit \textsc{rgb}. Limiting formats in this way
 along with the limited number of operators in the basic rendering equation
 provided an opportunity to instantiate each combination in custom
 compositing code. With three formats for each operand and two operators,
-there are 54 different rendering functions in 13\kb\ of code.
+there are 54 different rendering functions in 13\kb~of code.
 
 \section{Geometric Objects}
 
-\noindent For geometric operations, \twin\ uses the basic model from PostScript as
+\noindent For geometric operations, \twin~uses the basic model from PostScript as
 implemented in the cairo graphics system.\cite{cairo:2003} `Paths' are
 constructed from a sequence of lines and B\`ezier splines. An arbitrary path
 can be convolved with a convex path to construct a new path representing the
@@ -280,8 +285,8 @@
 run-time from scalable data. Commercial scalable font formats all represent
 glyphs in outline form. The resulting glyph is constructed by filling a
 complex shape constructed from lines and splines. The outline data for one
-face for the {\scshape ascii} character set could be compressed to less than
-7\kb\ -- significantly smaller than the storage needed for a bitmap
+face for the \textsc{ascii} character set could be compressed to less than
+7\kb~-- significantly smaller than the storage needed for a bitmap
 face at a single size.
 
 However, a straightforward rasterization of an outline does not provide an
@@ -315,7 +320,7 @@
 
 From this set of shapes, a simple gothic set of letters, numbers and
 punctuation was chosen. Additional glyphs were designed to provide a
-complete {\scshape ascii} set. The curves within the Hershey glyphs,
+complete \textsc{ascii} set. The curves within the Hershey glyphs,
 designed as sequences of short line segments, were replaced by cubic
 splines. This served both to improve the appearance of the glyphs under a
 variety of transforms as well as to reduce the storage required for the
@@ -356,7 +361,7 @@
 line. Coordinates between points on a snap list are moved so that the
 relative distance from the nearest snapped coordinates remain the same.
 The pen width is snapped to the nearest integer size. If the snapped pen
-width is odd, the entire glyph is pushed \half\ a pixel in both directions
+width is odd, the entire glyph is pushed \half~a pixel in both directions
 to align the pen edges with the pixel edges. Figure~\ref{fig:hint} shows a
 glyph being hinted in this fashion.
 
@@ -394,9 +399,9 @@
 
 \section{Process \& Thread Model}
 
-\noindent \Twin\ was initially developed to run on a custom embedded
+\noindent \Twin~was initially developed to run on a custom embedded
 operating system. This operating system design initially included simple
-cooperative threading support, and \twin\ was designed to run different
+cooperative threading support, and \twin~was designed to run different
 parts of the window system in different threads:
 \begin{kitemize}
 \item
@@ -420,9 +425,9 @@
 application processing eliminated much of the value of threads.
 
 Once this was working, support for threading was removed from the
-custom operating system...
+custom operating system.
 
-With no thread support at all, \twin\ was redesigned with a global event
+With no thread support at all, \twin~was redesigned with a global event
 loop monitoring input, timers and work queues. The combination of these
 three mechanisms replaced the collection of threads described above fairly
 easily, and the complexities of locking between input and output within a
@@ -442,12 +447,12 @@
 the user in the form of button, pointer and key manipulation and
 distributing them to the appropriate applications.
 
-\Twin\ takes a simplistic approach to this process, providing a single
+\Twin~takes a simplistic approach to this process, providing a single
 immutable model. Pointer events are delivered to the window containing the
 pointing device. Transparent areas of each window are excluded from this
 containment, so arbitrary shapes can be used to select for input.
 
-\Twin\ assumes that any pointing device will have at least one associated
+\Twin~assumes that any pointing device will have at least one associated
 signal -- a mouse button, a screen touch or perhaps something else.
 When pressed, the pointing device is `grabbed' by the window containing the
 pointer at that point. Motion information is delivered only to that window
@@ -481,7 +486,7 @@
 
 \section{Window Management}
 
-\noindent \Twin\ embeds window management right into the toolkit. Support
+\noindent \Twin~embeds window management right into the toolkit. Support
 for resize, move and minimization is not under the control of an external
 application. Instead, the toolkit automatically constructs suitable
 decorations for each window as regular toolkit objects and the normal event
@@ -489,7 +494,7 @@
 
 While external management is a valuable architectural feature in a
 heterogeneous desktop environment, the additional space, time and complexity
-rules this out in today's Sub-\pda\ world.
+rules this out in today's Sub-\pda~world.
 
 \section{Status and Future Work}
 
@@ -498,7 +503,7 @@
 increases both the value of such products as well as the scope of the
 potential market.
 
-The \twin\ window compositing mechanism, graphics model and event delivery
+The \twin~window compositing mechanism, graphics model and event delivery
 system have been implemented using a mock-up of the hardware running on
 Linux using the X window system. Figure~\ref{fig:twin} shows most of
 the current capabilities in the system.
@@ -513,22 +518,22 @@
  \end{centering}
 \end{figure}
 
-While the basic structure of the \twin\ window system is complete, the
+While the basic structure of the \twin~window system is complete, the
 toolkit is far from complete, having only a few rudimentary widgets. And,
 as mentioned above, the port to ucLinux is not yet taking advantage of the
 multiple process support in that environment. These changes will likely be
-accompanied by others as \twin\ is finally running on the target hardware.
+accompanied by others as \twin~is finally running on the target hardware.
 
 In the x86 emulation environment, the window system along with a small cadre
-of demonstration applications now fits in about 50\kb\ of text space with
+of demonstration applications now fits in about 50\kb~of text space with
 memory above that limited largely to the storage of the off-screen window
-contents. Performance on a 1.2{\scshape gh}z laptop processor is more than
+contents. Performance on a 1.2\textsc{gh}z laptop processor is more than
 adequate; it will be rather interesting to see how these algorithms scale
 down to the target \cpu.
 
-The current source code is available from via {\scshape CVS}, follow the
-link from http://keithp.com. The code is licensed with an {\scshape
-MIT}-style license, permitting liberal commercial use.
+The current source code is available from via \textsc{cvs}, follow the
+link from http://keithp.com. The code is licensed with an
+\textsc{mit}-style license, permitting liberal commercial use.
 
 \bibliography{keithp}
 




More information about the Commit mailing list