[Commit] papers/twin-ols2005 Makefile, NONE, 1.1 glyph.svg, NONE,
1.1 hint.svg, NONE, 1.1 keithp.bib, NONE, 1.1 lerp.5c, NONE,
1.1 ols-fonts.tex, NONE, 1.1 ols.sty, NONE,
1.1 twin-ols2005.tex, NONE, 1.1 twin.png, NONE, 1.1 zrl.sty,
NONE, 1.1
Keith Packard
commit at keithp.com
Thu May 12 18:34:43 PDT 2005
- Previous message: [Commit] papers/twin-ols2005 - New directory,NONE,NONE
- Next message: [Commit] papers/twin-ols2005 Makefile, 1.1, 1.2 README, NONE,
1.1 ols-fonts.tex, 1.1, 1.2 ols.sty, 1.1, 1.2 twin-ols2005.tex,
1.1, 1.2
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Committed by: keithp
Update of /local/src/CVS/papers/twin-ols2005
In directory home.keithp.com:/tmp/cvs-serv2503
Added Files:
Makefile glyph.svg hint.svg keithp.bib lerp.5c ols-fonts.tex
ols.sty twin-ols2005.tex twin.png zrl.sty
Log Message:
Add twin paper
--- NEW FILE: Makefile ---
.SUFFIXES: .tex .dvi .aux .eps .fig .dia .ps .pdf .bib .bbl .png .svg
.fig.eps:
fig2dev -L eps $< >$@
.fig.pdf:
fig2dev -L pdf $< >$@
.eps.pdf:
epstopdf $<
.png.eps:
pngtopnm -mix -background '#fff' $< | pnmdepth 255 | pnmtops -noturn -imagewidth 3.0 > $@
.svg.eps:
svg2png $< --scale=6 | pngtopnm -mix -background '#fff' | pnmdepth 255 | pnmtops -noturn -imagewidth 3.0 > $@
TOP=twin-ols2005
TEXFILES=$(TOP).tex
all: $(TOP).ps $(TOP).pdf $(TOP).www/$(TOP).html
#.PHONY: subdirs
subdirs:
# @${MAKE} -C figures ${MAKECMDGOALS}
# @${MAKE} -C examples ${MAKECMDGOALS}
SVGFILES:=$(wildcard *.svg)
PNGFILES:=$(wildcard *.png)
FIGFILES:=$(wildcard *.fig)
EPSFILES:=$(PNGFILES:.png=.eps)
EPSFILES+=$(FIGFILES:.fig=.eps)
EPSFILES+=$(SVGFILES:.svg=.eps)
PDFFILES=$(EPSFILES:.eps=.pdf)
$(TOP).ps: $(TOP).dvi
dvips -t letter -o $(TOP).ps $(TOP)
$(TOP).dvi: $(TEXFILES) $(EPSFILES) subdirs
latex $(TOP) || true
bibtex $(TOP) || true
latex $(TOP) || true
latex $(TOP)
#$(TOP).pdf: $(TOP).dvi
# dvipdf $(TOP).dvi $@
$(TOP).pdf: $(TEXFILES) $(PDFFILES)
pdflatex $(TOP) || true
bibtex $(TOP) || true
pdflatex $(TOP) || true
pdflatex $(TOP)
$(TOP).www/$(TOP).html: $(TOP).www $(TEXFILES)
latex2html -white -dir $(TOP).www -split 0 -no_navigation $(TOP).tex
$(TOP).www:
mkdir -p $@
clean: subdirs
rm -f *.aux *.dvi *.log
rm -f $(EPSFILES)
rm -f $(TOP).ps $(TOP).pdf $(TOP).bbl $(TOP).blg
rm -rf $(TOP).www
--- NEW FILE: glyph.svg ---
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg version="1.0" width="210" height="110"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
>
<g transform="scale(0.5,0.5)">
<!-- original hershey ampersand -->
<g transform="scale(9,9) translate(11.5,13.5)"
style="stroke-width:2;
stroke-linejoin:round;
stroke-linecap:round;
fill:none;stroke:#000000;">
<path d="M 10, -3
L 10, -4
L 9, -5
L 8, -5
L 7, -4
L 6, -2
L 4, 3
L 2, 6
L 0, 8
L -2, 9
L -6, 9
L -8, 8
L -9, 7
L -10, 5
L -10, 3
L -9, 1
L -8, 0
L -1, -4
L 0, -5
L 1, -7
L 1, -9
L 0, -11
L -2, -12
L -4, -11
L -5, -9
L -5, -7
L -4, -4
L -2, -1
L 3, 6
L 5, 8
L 7, 9
L 9, 9
L 10, 8
L 10, 7"/>
</g>
</g>
<g transform="scale(0.5,0.5) translate(210,0)">
<!-- twin ampersand derived from hershey ampersand -->
<g transform="scale(4.5,4.5) translate(3,45.5)"
style="stroke-width:4;
stroke-linejoin:round;
stroke-linecap:round;
fill:none;stroke:#000000;">
<path d="M 40, -24
C 40, -27, 39, -28, 37, -28
C 29, -28, 32, 0, 12, 0
C 0, 0, 0, -8, 0, -10
C 0, -24, 22, -20, 22, -34
C 22, -45, 10, -45, 10, -34
C 10, -27, 25, 0, 36, 0
C 39, 0, 40, -1, 40, -4"/>
</g>
</g>
</svg>
--- NEW FILE: hint.svg ---
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg version="1.0" width="335" height="240"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
>
<!-- twin B -->
<g transform="translate(0,0)">
<g transform="scale(4.5,4.5) translate(5,45.5)">
<!-- pixel grid -->
<g style="stroke-width:0.125;
fill:none;
stroke:#000000;
stroke-dasharray:1,1;">
<path d=" M -4, -45 L -4, 8"/>
<path d=" M 1, -45 L 1, 8"/>
<path d=" M 6, -45 L 6, 8"/>
<path d=" M 11, -45 L 11, 8"/>
<path d=" M 16, -45 L 16, 8"/>
<path d=" M 21, -45 L 21, 8"/>
<path d=" M 26, -45 L 26, 8"/>
<path d=" M -3, -43 L 27, -43"/>
<path d=" M -3, -38 L 27, -38"/>
<path d=" M -3, -33 L 27, -33"/>
<path d=" M -3, -28 L 27, -28"/>
<path d=" M -3, -23 L 27, -23"/>
<path d=" M -3, -18 L 27, -18"/>
<path d=" M -3, -13 L 27, -13"/>
<path d=" M -3, -8 L 27, -8"/>
<path d=" M -3, -3 L 27, -3"/>
<path d=" M -3, 2 L 27, 2"/>
<path d=" M -3, 7 L 27, 7"/>
</g>
<!-- letter -->
<g style="stroke-width:4;
stroke-linejoin:round;
stroke-linecap:round;
fill:none;stroke:#808080;">
<path d="M 0, -42
L, 0, 0"/>
<path d="M 0, -22
C 3, -26, 6, -28, 11, -28
C 22, -28, 24, -19, 24, -14
C 24, -9, 22, 0, 11, 0
C 6, 0, 3, -2, 0, -6"/>
</g>
<!-- points -->
<g style="fill:#000000;stroke:none;">
<circle cx="0" cy="-42" r="0.75"/>
<circle cx="0" cy="0" r="0.75"/>
<circle cx="0" cy="-22" r="0.75"/>
<circle cx="3" cy="-26" r="0.5"/>
<circle cx="6" cy="-28" r="0.5"/>
<circle cx="11" cy="-28" r="0.75"/>
<circle cx="22" cy="-28" r="0.5"/>
<circle cx="24" cy="-19" r="0.5"/>
<circle cx="24" cy="-14" r="0.75"/>
<circle cx="24" cy="-9" r="0.5"/>
<circle cx="22" cy="0" r="0.5"/>
<circle cx="11" cy="0" r="0.75"/>
<circle cx="6" cy="0" r="0.5"/>
<circle cx="3" cy="-2" r="0.5"/>
<circle cx="0" cy="-6" r="0.75"/>
</g>
<!-- hints -->
<g style="stroke-width:0.125;
fill:none;stroke:#000000;">
<!-- X hints -->
<path d="M 0, -45
L 0, 8"/>
<path d="M 24, -45
L 24, 8"/>
<!-- Y hints -->
<path d="M -3, -28
L 27, -28"/>
<path d="M -3, 0
L 27, 0"/>
</g>
</g>
</g>
<!-- twin B -->
<g transform="translate(190,0)">
<g transform="scale(4.5,4.5) translate(5,45.5)">
<!-- pixel grid -->
<g style="stroke-width:0.125;
fill:none;
stroke:#000000;
stroke-dasharray:1,1;">
<path d=" M -4, -45 L -4, 8"/>
<path d=" M 1, -45 L 1, 8"/>
<path d=" M 6, -45 L 6, 8"/>
<path d=" M 11, -45 L 11, 8"/>
<path d=" M 16, -45 L 16, 8"/>
<path d=" M 21, -45 L 21, 8"/>
<path d=" M 26, -45 L 26, 8"/>
<path d=" M -3, -43 L 27, -43"/>
<path d=" M -3, -38 L 27, -38"/>
<path d=" M -3, -33 L 27, -33"/>
<path d=" M -3, -28 L 27, -28"/>
<path d=" M -3, -23 L 27, -23"/>
<path d=" M -3, -18 L 27, -18"/>
<path d=" M -3, -13 L 27, -13"/>
<path d=" M -3, -8 L 27, -8"/>
<path d=" M -3, -3 L 27, -3"/>
<path d=" M -3, 2 L 27, 2"/>
<path d=" M -3, 7 L 27, 7"/>
</g>
<!-- letter -->
<g style="stroke-width:5;
stroke-linejoin:round;
stroke-linecap:round;
fill:none;stroke:#808080;">
<path d="M -1.5, -42
L, -1.5, -0.5"/>
<path d="M -1.5, -20.142857142857143
C 1.625, -23.714285714285714
4.75, -25.5
9.958333333333333, -25.5
C 21.416666666666667, -25.5
23.5, -17.464285714285714
23.5, -13
C 23.5, -8.535714285714286
21.416666666666667, -0.5
9.958333333333333, -0.5
C 4.75, -0.5
1.625, -2.285714285714286
-1.5, -5.857142857142857"/>
</g>
<!-- points -->
<g style="fill:#000000;stroke:none;">
<circle cx="-1.5" cy="-42" r="0.75"/>
<circle cx="-1.5" cy="-0.5" r="0.75"/>
<circle cx="-1.5" cy="-20.142857142857143" r="0.75"/>
<circle cx="1.625" cy="-23.714285714285714" r="0.5"/>
<circle cx="4.75" cy="-25.5" r="0.5"/>
<circle cx="9.958333333333333" cy="-25.5" r="0.75"/>
<circle cx="21.416666666666667" cy="-25.5" r="0.5"/>
<circle cx="23.5" cy="-17.464285714285714" r="0.5"/>
<circle cx="23.5" cy="-13" r="0.75"/>
<circle cx="23.5" cy="-8.535714285714286" r="0.5"/>
<circle cx="21.416666666666667" cy="-0.5" r="0.5"/>
<circle cx="9.958333333333333" cy="-0.5" r="0.75"/>
<circle cx="4.75" cy="-0.5" r="0.5"/>
<circle cx="1.625" cy="-2.285714285714286" r="0.5"/>
<circle cx="-1.5" cy="-5.857142857142857" r="0.75"/>
</g>
<!-- hints -->
<g style="stroke-width:0.125;
fill:none;stroke:#000000;">
<!-- X hints -->
<path d="M -1.5, -45
L -1.5, 8"/>
<path d="M 23.5, -45
L 23.5, 8"/>
<!-- Y hints -->
<path d="M -3, -25.5
L 27, -25.5"/>
<path d="M -3, -0.5
L 27, -0.5"/>
</g>
</g>
</g>
</svg>
--- NEW FILE: keithp.bib ---
% Keiths BiBTeX database
@book{autoconf,
title = "GNU Autoconf, Automake and Libtool",
author = "Gary V. Vaughan and Ben Elliston and Tom Tromey and Ian Lance Taylor",
publisher = "New Riders",
year = 2000,
note = {ISBN 1-57870-190-2}, },
@book{awk,
title = "The AWK programming language",
author = "A. V. Aho and P. J. Weinberger and B. W. Kerninghan",
publisher = "Addison-Wesley",
year = 1988, },
@manual{bc,
title = "BC - An Arbitrary Precision Desk-Calculator Language",
author = "Robert Morris and Lorinda Cherry",
organization = "AT\&T Bell Laboratories",
note = "Unix Programmer's Manual Volume 2, 7th Edition",
year = 1978, },
@article{blinn:1994,
title = "Compositing Theory",
author = "Jim Blinn",
journal = "IEEE Computer Graphics and Applications",
year = 1994,
month = "September",
note = "Republished in~\cite{blinn:1998}" }
@book{blinn:1998,
title = "{Jim Blinn's Corner: Dirty Pixels}",
author = "Jim Blinn",
year = 1998,
publisher = "Morgan Kaufmann",
isbn = "1-55860-455-3", }
@book{bsd:1989,
title = "{The Design and Implementation of the 4.3BSD UNIX Operating System}",
author = "Samual J. Leffler and Marshall Kirk McKusick and Machael
J. Karels and John S. Quarterman",
publisher = "Addison Wesley",
year = 1989, }
@techreport{dbe,
title = "{Double Buffer Extension Protocol}",
author = "Ian Elliott and David P. Wiggins",
institution = "X Consortium, Inc.",
type = "X Consortium Standard",
year = 1994, }
@manual{dc,
title = "DC - An Interactive Desk Calculator",
author = "Robert Morris and Lorinda Cherry",
organization = "AT\&T Bell Laboratories",
note = "Unix Programmer's Manual Volume 2, 7th Edition",
year = 1978, },
@book{DuBois-imake,
author = {Paul DuBois},
title = {{Software Portability with imake}},
year = {1993},
month = jul,
publisher = {O'Reilly \& Associates Inc},
series = {Nutshell Handbook Series},
category = {Practical Sofware Engineering},
note = {ISBN 1-56592-055-4}
}
@book{emacs,
title = "GNU Emacs Manual",
author = "Richard M. Stallman",
publisher = "Free Software Foundation",
edition = "fourteenth",
version = "20.7",
month = "June",
year = "2000" }
@misc{freetype2,
title = "The design of {FreeType} 2",
author = "David Turner and The FreeType Development Team",
year = 2000,
note = "\url{http://www.freetype.org/freetype2/docs/design/}",
},
@inproceedings{gj,
title = "Making the future safe for the past: Adding Genericity to the Java Programming Language",
author = "Gilad Bracha and Martin Odersky and David Stoutamire and Phillip Wadler",
month = "October",
booktitle = "Conference on Object-Oriented Programing systems, Languages and Applications (OOPSLA '98)",
year = 1998,
publisher = "ACM",
organization = "SIGPLAN", }
@book{gl:1.2.1,
title = "The OpenGL Graphics System: A Specification",
author = "Mark Segal and Kurt Akeley and Jon Leach (ed)",
version = "1.2.1",
publisher = "SGI",
year = 1999 },
@phdthesis{Hobby85,
author = {John D. Hobby},
title = {Digitized Brush Trajectories},
school = {Stanford University},
year = {1985},
note = {Also {\it Stanford Report STAN-CS-85-1070}}
}
@inproceedings{ http:1997,
author = "Henrik Frystyk Nielsen and James Gettys and Anselm Baird-Smith
and Eric Prud'hommeaux and Hakon Wium Lie and Chris Lilley",
title = "Network Performance Effects of HTTP/1.1, CSS1, and PNG",
booktitle = "ACM SIGCOMM '97 Conference Proceedings",
month = "September",
year = 1997,
organization = "Association for Computing Machinery",
url = "\url{http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html}"
},
@article{itsy,
title = "{Itsy: Stretching the Bounds of Mobile Computing}",
author = "William R. Hamburgen and Deborah A. Wallach and Marc A. Viredaz and Lawrence S. Brakmo and Carl A. Waldspurger and Joel F. Bartlett and Timothy Mann and Keith I. Farkas",
journal = "IEEE Computer",
year = 2001,
publisher = "Institute of Electrical and Electronics Engineers, Inc.",
volume = 34,
number = 4,
month = "April",
pages = "28-35", }
@book{java,
title = "Java",
author = "Juan Valdez",
publisher = "Not so hot books",
year = 1929, },
@inproceedings{lbx:1993,
title = "{An Update on Low Bandwidth X (LBX): A Standard For X and Serial Lines}",
author = "Jim Fulton and Chris Kent Kantarjiev",
booktitle = "Proceedings of the Seventh Annual X Technical Conference",
month = "January",
year = 1993,
pages = "251-266",
address = "Boston, MA",
organization = "MIT X Consortium",
},
@inproceedings{lbx:1994,
title = "{Design and Implementation of LBX: An Experiment Based Standard}",
author = "Keith Packard",
booktitle = "Proceedings of the Eighth Annual X Technical Conference",
month = "January",
year = 1994,
pages = "121-133",
address = "Boston, MA",
organization = "X Consortium",
},
@inproceedings{lmbench:1996,
title = "{lmbench: Portable tools for performance analysis}",
author = "Larry McVoy and Carl Staelin",
booktitle = "Technical Conference Proceedings",
month = "January",
year = 1996,
pages = "279-284",
address = "San Diego, CA",
organization = "USENIX", }
@book{ml,
title = "ML - disaster of a language",
author = "mephistopholes",
publisher = "hot books",
year = 1666, },
@book{mod3,
title = "Systems Programming with Modula-3",
author = "Greg Nelson",
publisher = "Prentice Hall",
year = 1991, }
@book{moscow,
title = "Moscow ML",
author = "John Stallin'",
publisher = "Gulag press",
year = 1906, },
@article{mtx:1992,
title = {{The Multi-Threaded X Server}},
author = "John Smith",
journal = "The X Resource",
publisher = "O'Reilly \& Associates, Inc.",
year = 1992,
volume = 1,
pages = "73-89",
month = "Winter", }
@article{layout:1993,
title = {{The LayoutWidget: A TeX Style Constraint Widget Class}},
author = "Keith Packard",
journal = "The X Resource",
publisher = "O'Reilly \& Associates, Inc.",
year = 1993,
volume = 5,
month = "Winter", }
@article{nelson:1996,
title = "Twelve Characteristics of Correct Antialiased Lines",
author = "Scott R. Nelson",
journal = "Journal of Graphics Tools",
year = 1996,
volume = 1,
number = 4,
pages = "1-20", },
@Article{Nistnet00,
author = "NIST Internetworking Technology Group",
title = "{NISTNet} network emulation package",
journal = "\url{http://www.antd.nist.gov/itg/nistnet/}",
month = jun,
year = "2000",
bibdate = "Thursday, June 29, 2000 at 16:40:15 (MEST)",
submitter = "Katarina Asplund",
}
@book{perl,
title = "Programming Perl",
author = "L. Wall and T. Christiansen and R. L. Schwartz",
publisher = "O'Reilly \& Associates, Inc.",
year = 1996,
edition = "Second", },
@manual{pike:draw,
title = "draw - screen graphics",
author = "Rob Pike",
organization = "Bell Laboratories",
year = 2000,
note = "Plan 9 Manual Page Entry", }
@article{platt:2000,
title = "Optimal Filtering for Patterned Displays",
author = "J. Platt",
journal = "IEEE Signal Processing Letters",
year = 2000,
volume = 7,
number = 7,
pages = "179-180",
}
@article{pitt:1967,
title = "Algorithm for drawing ellipses or hyperbolae with a digital plotter",
author = "M. L. V. Pitteway",
journal = "The Computer Journal",
year = 1967,
volume = 10,
number = 3,
pages = "282-289",
month = "November", }
@article{porterduff:1984,
title = "{Compositing Digital Images}",
author = "Thomas Porter and Tom Duff",
journal = "Computer Graphics",
year = 1984,
volume = 18,
number = 3,
pages = "253-259",
month = "July", }
@book{ps,
title = "PostScript Language Reference Manual",
author = {{Adobe Systems Incorporated}},
publisher = "Addison Wesley",
year = 1985, }
@book{python,
title = "Programming Python",
author = "Mark Lutz",
publisher = "O'Reilly \& Associates, Inc.",
year = 2001,
edition = "Second", }
@book{qt,
title = "Programming with Qt",
author = "Matthias Kalle Dalheimer",
publisher = "O'Reilly \& Associates, Inc.",
year = 2001,
month = "May",
edition = "second", }
@inproceedings{render:2000,
title = "{A New Rendering Model for X}",
author = "Keith Packard",
booktitle = "FREENIX Track, 2000 Usenix Annual Technical Conference",
month = "June",
year = 2000,
pages = "279-284",
address = "San Diego, CA",
organization = "USENIX", }
@inproceedings{render:2001,
title = "{Design and Implementation of the X Rendering Extension}",
author = "Keith Packard",
booktitle = "FREENIX Track, 2001 Usenix Annual Technical Conference",
month = "June",
year = 2001,
address = "Boston, MA",
organization = "USENIX", }
@book{scheme,
title = "Scheme - lisp sortof",
author = "Guy Wire",
publisher = "parenthetical statements",
year = 1969, },
@manual{sed,
title = "SED - A Non-interactive Text Editor",
author = "Lee E. McMahon",
organization = "AT\&T Bell Laboratories",
note = "Unix Programmer's Manual Volume 2, 7th Edition",
year = 1978, },
@techreport{shape,
title = "X Nonrectangular Window Shape Extension Protocol",
author = "Keith Packard",
institution = "MIT X Consortium",
type = "X Consortium Standard",
year = 1989, }
@article{sharedx:1994,
title = "{HP SharedX: A Tool for Real-Time Collaboration}",
author = "Daniel Garfinkel and Bruce C. Welti and Thomas W. Yip",
journal = "HP Journal",
year = 1994,
month = "April", }
@mastersthesis{xplot,
title = "TCP Packet Trace Analysis",
author = "Timothy J. Shepard",
school = "Massachusetts Institute of Technology",
year = "1990",
note = {Also {\it MIT LCS Tech Report 494}}
}
@inproceedings{simics:1998,
title = "{SimICS/sun4m: A Virtual Workstation}",
author = "Peter S. Magnusson and Fredrik Dahlgren and {H\aa kan} Grahn,
Magnus Karlsson and Fredrik Larsson and Fredrik Lundholm and Andreas Moestedt and Jim
Nilsson and Per {Stenstr\"{o}m} and Bengt Werner",
booktitle = "Technical Conference Proceedings",
month = "June",
year = 1998,
address = "New Orleans, LA",
organization = "USENIX", }
@techreport{sync:1991,
title = {{X Synchronization Extension Protocol, Version 3.0}},
author = "Tim Glauert and Dave Carver and Jim Gettys and David P. Wiggins",
institution = "X Version 11 Release 6",
type = "X Consortium Standard",
year = 1991, }
@manual{tinyx,
title = "Xkdrive - Tiny X server",
author = "Juliusz Chroboczek and Keith Packard",
organization = "The XFree86 Project, Inc.",
note = "XFree86 Release 4.0.3",
year = 2001, }
@techreport{trestle:1991,
title = "{Trestle Reference Manual}",
author = "Mark Manasse and Greg Nelson",
institution = "Digital Equipment Corporation Systems Research Center",
type = "Research Report",
number = 68,
month = "December",
year = 1991 }
@article{unix:1977,
title = "UNIX Implementation",
author = "K. Thompson",
journal = "The Bell System Technical Journal",
year = 1978,
volume = 57,
number = 6,
pages = "1931-1946",
month = "July-August", }
@book{x,
title = "X Window System",
author = "Robert W. Scheifler and James Gettys",
publisher = "Digital Press",
year = 1992,
edition = "Third", }
@book{xt,
title = "X Window System Toolkit",
author = "Paul J. Asente and Ralph R. Swick",
publisher = "Digital Press",
year = 1990, }
@techreport{x11perf:1994,
title = "{X11perf - X11 server performance test program}",
author = "Joel McCormack and Phil Karlton and Susan Angebranndt and
Chris Kent and Keith Packard and Graeme Gill",
institution = "X11 Version 11 Release 6.4",
type = "Manual Page",
year = 1994, }
@TechReport{AMD:2000:XTW,
author = "{AMD Corporation}",
title = "{x86-64$^{\mathrm{TM}}$ Technology White Paper}",
institution = "{AMD Corporation}",
address = "One AMD Place, Sunnyvale, CA 94088, USA",
pages = "12",
day = "17",
month = aug,
year = "2000",
bibdate = "Fri May 04 12:53:45 2001",
bibsource = "\url{http://www.amd.com/products/cpg/64bit/index.html}",
URL = "\url{http://www.amd.com/products/cpg/64bit/pdf/x86-64_wp.pdf};
\url{http://www1.amd.com/products/cpg/x8664bit/faq}",
acknowledgement = ack-nhfb,
annote = "The x86-64 architecture is definitely not an IA-64
implementation, but rather, an extension of IA-32 by
widening the integer registers to 64-bits.",
}
@techreport{xaa,
title = "{XAA.HOWTO}",
author = "Mark Vojkovich and Marc Aurele La France",
institution = "The XFree86 Project, Inc.",
year = 2000, }
@techreport{xfs,
title = "The X Font Service Protocol",
author = "Jim Fulton",
institution = "Network Computing Devices, Inc.",
type = "X Consortium Standard",
year = 1994, }
@techreport{xrender,
title = "{The X Rendering Extension}",
author = "Keith Packard",
institution = "The XFree86 Project, Inc.",
type = "XFree86 Draft Standard",
year = 2000, }
@book{pdf14,
title = "PDF Reference: Version 1.4",
edition = "3rd",
editor = "Adobe Systems Incorporated",
publisher = "Addison-Wesley",
year = 2001,
}
@book{knuth:d,
title = "METAFONT: The Program",
author = "Donald E. Knuth",
publisher = "Addison Wesley",
year = 1986,
series = "Computers & Typesetting",
volume = "D",
}
@book{gtk1,
title = "Developing Linux Applications with GTK+ and GDK",
author = "Eric Harlow",
publisher = "MacMillan Publishing Company",
year = 1999,
}
@book{xul,
title = "Creating Applications with Mozilla",
author = "David Boswell and Brian King and Ian Oeschger and Pete Collins and Eric Murphy",
publisher = "O'Reilly \& Associates, Inc.",
year = 2002,
}
@book{ssh,
title = "SSH, The Secure Shell: The Definitive Guide",
author = "Daniel J. Barrett and Richard Silverman",
publisher = "O'Reilly \& Associates, Inc.",
year = 2001,
}
@book{gzip,
title = "Gzip: The Data Compression Program",
author = "Jean-Loup Gailly",
publisher = "iUniverse.com",
edition = "1.2.4",
year = "1993",
}
@inproceedings{xrandr:2001,
title = "{The X Resize and Rotate Extension - RandR}",
author = "Jim Gettys and Keith Packard",
booktitle = "FREENIX Track, 2001 Usenix Annual Technical Conference",
month = "June",
year = 2001,
organization = "USENIX",
address = "Boston, MA",
url = "\url{http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/gettys.html}",
}
@inproceedings{xft:2001,
title = "{The Xft Font Library: Architecture and Users Guide}",
author = "Keith Packard",
booktitle = "XFree86 Technical Conference",
month = "November",
year = 2001,
address = "Oakland, CA",
organization = "USENIX",
}
@inproceedings{xcb:2001,
title = "{XCB}: An {X} Protocol C Binding",
author = "Bart Massey and Jamey Sharp",
booktitle = "XFree86 Technical Conference",
month = "November",
year = 2001,
address = "Oakland, CA",
organization = "USENIX",
}
@unpublished{pinzari,
author = "Gian Filippo Pinzari",
title = "The NX X Protocol Compressor",
note = "Electronic Communication",
month = "March",
year = "2003",
}
@inproceedings{Gettys:2002,
title = "{The Future is Coming, Where the X Window System Should Go}",
author = "James Gettys",
booktitle = "FREENIX Track, 2002 Usenix Annual Technical Conference",
month = "June",
year = 2002,
organization = "USENIX",
address = "Monterey, CA",
url = "\url{http://www.usenix.org/publications/library/proceedings/usenix02/tech/freenix/full_papers/gettys/gettys_html/index.html}",
}
@inproceedings{ramshaw83,
author = {Leo Guibas and Lyle Ramshaw and Jorge Stolfi},
title = {A kinetic framework for computational geometry},
booktitle = {Proceedings of the IEEE 1983 24th Annual Symposium on the Foundations of Computer Science},
year = {1983},
pages = {100--111},
publisher = {IEEE Computer Society Press},
}
@misc{ewing,
title = "Linux 2.0 Penguins",
author = "Larry Ewing",
note = "\url{http://www.isc.tamu.edu/~lewing/linux}",
}
@misc{budig,
title = "The Linux-Pinguin again",
author = "Simon Budig",
note = "\url{http://www.home.unix-ag.org/simon/penguin}",
}
@misc{gimp,
title = "The {GIMP}: The {GNU} Image Manipulation Program",
author = "Peter Mattis and Spencer Kimball and the GIMP developers",
note = "\url{http://www.gimp.org}",
}
@inproceedings{fontconfig,
title = "{Font Configuration and Customization for Open Source Systems}",
author = "Keith Packard",
booktitle = "2002 Gnome User's and Developers European Conference",
month = "April",
year = 2002,
organization = "Gnome",
address = "Seville, Spain",
url = "\url{http://keithp.com/~keithp/talks/guadec2002/}",
}
@misc{watanabe,
title = "3-D Shape and Outline",
author = "Isao Watanabe",
note = "\url{http://www.let.kumamoto-u.ac.jp/watanabe/Watanabe-E/Illus-E/3D-E/index.html}",
}
@book{seckel,
author = {Al Seckel},
title = {The Great Book of Optical Illusions},
publisher = {Firefly Books Ltd.},
year = {2002},
}
@inproceedings{xperf:2003,
title = "{X Window System Network Performance}",
author = "Keith Packard and James Gettys",
booktitle = "FREENIX Track, 2003 Usenix Annual Technical Conference",
month = "June",
year = 2003,
address = "San Antonio, TX",
organization = "USENIX", }
@inproceedings{cairo:2003,
title = "{Xr: Cross-device Rendering for Vector Graphics}",
author = "Carl Worth and Keith Packard",
booktitle = "Proceedings of the Ottawa Linux Symposium",
month = "July",
year = 2003,
address = "Ottawa, ON",
organization = "OLS", }
@inproceedings{anholt:2004,
title = "{High Performance X Servers in the Kdrive Architecture}",
author = "Eric Anholt",
booktitle = "FREENIX Track, 2004 Usenix Annual Technical Conference",
month = "July",
year = 2004,
address = "Boston, MA",
organization = "USENIX", }
@inproceedings{glitz:2004,
title = "{Glitz: Hardware Accelerated Image Compositing using OpenGL}",
author = "Peter Nilsson and David Reveman",
booktitle = "FREENIX Track, 2004 Usenix Annual Technical Conference",
month = "July",
year = 2004,
address = "Boston, MA",
organization = "USENIX", }
@misc{hal,
title = "{HAL Specification 0.2}",
author = "David Zeuthen",
note = "\url{http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html}",
}
@misc{directfb:2004,
title = "{DirectFB Overview (v0.2 for DirectFB 0.9.21)}",
author = "A. Hundt",
year = 2004,
month = "February",
note = "\url{http://www.directfb.org/documentation}"
}
@misc{croquet:2002,
title = "{Croquet: The Users Manual}",
author = "D. Smith and A. Raab and D. Reed and A. Kay",
edition = "Draft Revsion 0.1",
month = "October",
year = 2002,
note = "\url{http://glab.cs.uni-magdeburg.de/~croquet/downloads/Croquet0.1.pdf}",
}
@inproceedings{lookingglass:2004,
title = "{Project Looking Glass: 3D Desktop Exploration}",
author = "H. Kawahara and D. Johnson",
booktitle = "X Developers Conference",
month = "April",
year = 2004,
address = "Cambridge, MA",
}
@inproceedings{xselinux:2004,
title = "{Integrating XFree86 With Security-Enhanced Linux}",
author = "Eamon Walsh",
booktitle = "X Developers Conference",
month = "April",
year = 2004,
address = "Cambridge, MA",
note = "\url{http://freedesktop.org/Software/XDevConf/x-security-walsh.pdf}",
}
@misc{xevie:2004,
title = "{XEvIE - X Event Interception Extension}",
author = "S. Kreitman",
note = "\url{http://freedesktop.org/~stukreit/xevie.html}",
}
@techreport{xsync,
title = "{X Synchronization Extension Protocol, Version 3.0}",
author = "Tim Glauert and Dave Carver and James Gettys and David Wiggins",
insitution = "MIT X Consortium",
type = "X Consortium Standard",
year = 1992,
}
@techreport{littlecms,
title = "{Little CMS Engine 1.12 API Definition}",
author = "M. Maria",
note = "\url{http://www.littlecms.com/lcmsapi.txt}",
}
@techreport{ltsp:2002,
title = "{LTSP - Linux Terminal Server Project, Version 3.0}",
author = "Jim McQuillan",
month = "March",
year = 2002,
note = "\url{http://www.ltsp.org/documentation/ltsp-3.0-4-en.html}",
}
@techreport{xie:1996,
title = "{X Image Extension Protocol Version 5.02}",
author = "Robert N.C. Shelley and Robert W. Scheifler and Ben Fahy
and Jim Fulton and Keith Packard and Joe Mauro and Richard Hennessy and Tom
Vaughn",
insitution = "X Consortium",
type = "X Consortium Standard",
year = 1996,
}
@inproceedings{nickle:2001,
title = "{Nickle: Language Principles and Pragmatics}",
author = "Bart Massey and Keith Packard",
booktitle = "FREENIX Track, 2001 Usenix Annual Technical Conference",
month = "June",
year = 2001,
organization = "USENIX",
address = "Boston, MA",
url = "\url{http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/massey.html}",
}
--- NEW FILE: lerp.5c ---
real lerp (real v,
real before, real snap_before,
real after, real snap_after)
{
if (v < before) return v;
if (v > after) return after;
real dist = after - before;
real move_before = snap_before - before;
real move_after = snap_after - after;
real dist_before = v - before;
real dist_after = after - v;
real move = (dist_before * move_after + dist_after * move_before) / dist;
v += move;
return v;
}
real x_lerp (real x)
{
return lerp (x, 0, -1.5, 24, 23.5);
}
real y_lerp (real y)
{
return lerp (y, -28, -25.5, 0, -0.5);
}
void v (real x, real y)
{
printf ("\t <circle cx=\"%f\" cy=\"%f\", r=\"0.75\"/>\n", x_lerp (x), y_lerp (y));
}
v (0, -42)
v (0, 0)
v (0, -22)
v ( 3, -26)
v ( 6, -28)
v ( 11, -28)
v ( 22, -28)
v ( 24, -19)
v ( 24, -14)
v ( 24, -9)
v ( 22, 0)
v ( 11, 0)
v ( 6, 0)
v ( 3, -2)
v ( 0, -6)
--- NEW FILE: ols-fonts.tex ---
\usepackage{alltt}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{isolatin1}
\usepackage{latexsym}
\usepackage{textcomp}
%\usepackage{cloister}
%\renewcommand\baselinestretch{1.05}
\usepackage{times}
%\usepackage{eco}
\usepackage{url}
\usepackage[T1,obeyspaces]{zrl}
%\clubpenalty=0
%\widowpenalty=0
%\displaywidowpenalty=0
%\rightskip=0pt plus2em
%\spaceskip=.333em
%\xspaceskip=.5em
\renewcommand\labelitemi{$\diamond$}
% "verbatim" with line breaks, obeying spaces
\providecommand\code{\begingroup \xrlstyle{tt}\Xrl}
% as above, but okay to break lines at spaces
\providecommand\brcode{\begingroup \zrlstyle{tt}\Zrl}
% Same as the pair above, but 'l' for long == small type
\providecommand\lcode{\begingroup \small\xrlstyle{tt}\Xrl}
\providecommand\lbrcode{\begingroup \small\zrlstyle{tt}\Zrl}
% For identifiers - "verbatim" with line breaks at punctuation
\providecommand\ident{\begingroup \urlstyle{tt}\Url}
\providecommand\lident{\begingroup \small\urlstyle{tt}\Url}
--- NEW FILE: ols.sty ---
% TEMPLATE for Usenix papers, specifically to meet requirements of
% TCL97 committee.
% originally a template for producing IEEE-format articles using LaTeX.
% written by Matthew Ward, CS Department, Worcester Polytechnic Institute.
% adapted by David Beazley for his excellent SWIG paper in Proceedings,
% Tcl 96
% turned into a smartass generic template by De Clarke, with thanks to
% both the above pioneers
% use at your own risk. Complaints to /dev/null.
% make it two column with no page numbering, default is 10 point
% adapted for Ottawa Linux Symposium
% include following in document.
%\documentclass[twocolumn]{article}
%\usepackage{usits,epsfig}
\pagestyle{empty}
%set dimensions of columns, gap between columns, and space between paragraphs
%\setlength{\textheight}{8.75in}
%\setlength{\textheight}{9.0in}
% carefully computed to fit an even number of lines
% if even 1/1000 off, columns may not line up if a figure appears
\setlength{\textheight}{8.939in}
\setlength{\columnsep}{0.25in}
\setlength{\textwidth}{6.45in}
\setlength{\footskip}{0.0in}
\setlength{\topmargin}{-0.5in}
\setlength{\normalbaselineskip}{\baselineskip}
\setlength{\headheight}{0.0in}
\setlength{\headsep}{0.5in}
\setlength{\oddsidemargin}{0in}
%\setlength{\oddsidemargin}{-.065in}
%\setlength{\oddsidemargin}{-.17in}
\setlength{\parindent}{1em}
% \setlength{\parskip}{\baselineskip}
%\setlength{\parskip}{12pt plus3pt minus3pt}
\setlength{\parskip}{0in}
\setlength{\itemsep}{0in}
\setlength{\parsep}{0in}
\setlength{\topsep}{0in}
\setlength{\partopsep}{0in}
\setcounter{secnumdepth}{0}
% started out with art10.sty and modified params to conform to IEEE format
% further mods to conform to Usenix standard
\makeatletter
%as Latex considers descenders in its calculation of interline spacing,
%to get 12 point spacing for normalsize text, must set it to 10 points
\def\@normalsize{\@setsize\normalsize{12pt}\xpt\@xpt
\abovedisplayskip 10pt plus2pt minus5pt\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus3pt\belowdisplayshortskip 6pt plus3pt
minus3pt\let\@listi\@listI}
%make section titles italic and a bit larger, but set on the same leading
% as normal text
\def\section{\@startsection {section}{1}{\z@}{\normalbaselineskip}
{\normalbaselineskip}{\center\large\it\setlength{\baselineskip}{12pt}}}
%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}}}
\makeatother
% \let\fx=\footnoterule
% \usepackage{ftnright}
% \def\footnoterule{\fx}
% set up an if so writers can tell if the whole proceedings are
% being processed together
\newif\ifols
\ifx\olsmaster\undefined
\olsfalse
\else
\olsmaster=1
\olstrue
\fi
% set up an if so writers (and the proceedings) can tell if
% latex or pdflatex is being used, and include the proper
% packages as a result...
\newif\ifpdf
\ifx\pdfoutput\undefined
\pdffalse
\else
\pdfoutput=1
\pdftrue
\fi
--- NEW FILE: twin-ols2005.tex ---
\documentclass[twocolumn,10pt,twoside]{article}
\usepackage{ols}
\ifpdf
\usepackage[pdftex]{epsfig}
\else
\usepackage{epsfig}
\fi
\input{ols-fonts}
% For fonts with text digits
%\def\half{\hbox{\hspace{.15em}\raisebox{0.25em}{\scalebox{.7}{1}}\hspace{-.1em}\raisebox{0.08em}{\scalebox{.6}{/}}\hspace{-.1em}{\scalebox{.7}{2}}}}
% For fonts without text digits
\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}}
\newenvironment{kitemize}{\list{\raisebox{0.2em}{\tiny $\bullet$}}%
{\setlength{\parskip}{0in}
\setlength{\itemsep}{0in}
\setlength{\parsep}{0in}
\setlength{\topsep}{0in}
\setlength{\partopsep}{0in}
\setlength{\labelsep}{.3em}
\setlength{\leftmargin}{0in}}}
{\endlist}
\newenvironment{kcenter}{\list{}{\rightmargin\leftmargin
\setlength{\itemsep}{0in}
\setlength{\parsep}{0in}
\setlength{\topsep}{\baselineskip}
\setlength{\partopsep}{0in}}%
\item\relax}
{\endlist}
\pagestyle{myheadings}
\markboth{{\rm Keith Packard\hfill}}{{\rm \hfill\Twin: A Window System for `Sub-\PDA' Devices}}
\renewcommand{\thepage}{}
\begin{document}
%don't want date printed
\date{}
\frenchspacing
\title{\Twin: A Window System for `Sub-\PDA' Devices}
\author{
Keith Packard \\
{\normalsize HP Cambridge Research Labs}\\
{\normalsize keithp at keithp.com}\\
} % end author section
\maketitle
% You have to do this to suppress page numbers. Don't ask.
\thispagestyle{empty}
\section*{Abstract}
\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
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
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
as platforms for dissociated, distributed computing reseach. These
devices include small {\scshape lcd} or {\scshape 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.
In contrast, early graphical user interfaces for desktop platforms was more
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
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
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.
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
research.
\section{Assumptions}
\noindent The hardware described above can be generalized to provide a
framework within which the \twin\ architecture fits. By focusing on
specific hardware capabilties 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
very general nature of existing window systems, it seems interesting to
explore what happens when less variation is permitted.
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
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
also reduce power consumption by reducing off-chip data references.
The second limitation imposed was to require a color screen with fixed color
mapping. While this may appear purely beneficial to the user, the software
advantages are numerous as well. Imprecise rendering operations can now
generate small nearly invisible errors instead of visibly incorrect results
through the use of anti-aliased drawing. With smooth gradations of color
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
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
by twin are required to be fast enough to make this irrelevant.
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
been experienced by them. For example, X provides six different color
models for monochrome, colormapped and static color displays. In practice,
only TrueColor (separate monotonic red, green, blue elements in each pixel)
will ever be used by the majority of X users. Eliminating choice has
benefits beyond the mere reduction of window system code, it reflects
throughout the application stack.
\section{Windowing}
\noindent Windowing can be thought of as the process of simulating multiple, separate,
two-dimensional surfaces sharing the same display. These virtual surfaces,
or `windows,' are then combined into a single presentation. Traditional
window systems do this by presenting a `2\half' dimensional user interface which
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
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:
\begin{kitemize}
\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.
Decoupling these two operations means that rendering can operate at full
main memory speed instead of the reduced video controller memory speed
\item
Rendering operations needn't clip to overlapping windows. Eliminating the
need to perform clipping reduces the complexity and size of the window
system by eliminating the code needed to construct and maintain the clip
list data structures.
\item
Applications need not deal with damage events. In a traditional
clipping-based window system, applications must be able to reconstruct their
presentation data quickly to provide data for newly visible portions of
windows.
\item
Multiple window image formats can be supported, including those with
translucency information. By constructing the physical frame buffer data
from the combination of various window contents, it is possible to perform
arbitrary image manipulation operations on those window contents, including
translucency effects.
\end{kitemize}
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
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}
environments.
\section{Graphics}
\noindent The availability of small color screens using either {\scshape lcd} or {\scshape 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
is used to produce higher fidelity renderings within the limited screen
resolution. Per-pixel translucency is included to `see through' objects as
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
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
with the tools and that the system is `complete' in some informal sense.
\section{Pixel Manipulation}
\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. This
three-operand rendering operator forms the base upon which all drawing is built:
\begin{kcenter}
dest = (src {\scshape in} mask) {\scshape over}|{\scshape source} dest
\end{kcenter}
The {\scshape in}, {\scshape over} and {\scshape 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
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
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.
\section{Geometric Objects}
\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
original path as stroked by the convex path. The convolution operation
approximates the outline of the Minkowski sum of the two paths.
A path can then be drawn by scan converting it to a mask for use in the
basic rendering operation described above. Because the rendering operation
can handle translucency, this scan conversion operation does anti-aliasing
by super sampling the path and computing coverage data over each pixel.
The application interface includes an affine transformation from an
arbitrary 16.16 fixed point coordinate space to 12.4 fixed point pixel
space. The 16.16 fixed point values provide reasonable dynamic range for
hardware which does not include floating point acceleration. The 12.4 fixed
point pixel coordinates provide sufficient resolution to accurately
reproduce object geometry on the screen. Note that the screen is therefore
implicitly limited to 4096 pixels square.
\section{Glyph Representation}
\noindent Providing text at multiple sizes allows the user interface to take
maximal advantage of the limited screen size. This can either be done by
storing pre-computed glyphs at multiple sizes or preparing glyphs at
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 at a single size.
However, a straightforward rasterization of an outline does not provide an
ideal presentation on the screen. Outline fonts often include hinting
information to adjust glyph shapes at small pixel sizes to improve sharpness
and readability. This hinting information requires significantly more code
and data than the basic outlines themselves, making it impractical for the
target device class.
An alternative representation for glyphs is as stroke data. With only the
path of the pen recorded, the amount of data necessary to represent each
glyph is reduced. More significantly, with the stroke width information
isolated from the stroke path, it is possible to automatically adjust the
stroke positions to improve the presentation on the screen. A secondary
adjustment of the pen shape completes the hinting process. The results
compare favorably with fully hinted outline text.
An additional feature of the stroke representation is that producing oblique
and bold varients of the face are straightforward; slanting the text without
changing the pen shape provides a convincing oblique while increasing the
pen width produces a usable bold.
The glyphs themselves have a venerable history. The basic shapes come from
work done by Dr A.V. Hershey for the US National Bureau of Standards. Those
glyphs were designed for period pen plotters and were constructed from
straight line segments on a relatively low resolution grid. The complete
set of glyphs contains many different letterforms from simple gothic shapes
to letters constructed from multiple parallel strokes that provide an
illusion of varying stroke widths. Many additional decorative glyphs were
also designed.
>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,
designed as sequences of short line segments, were replaced by cubic
splines. This served both to improve the apperance of the glyphs under a
variety of transforms as well as to reduce the storage required for the
glyphs as a single cubic spline can replace many line segments.
Figure~\ref{fig:glyph} shows a glyph as originally designed with 33 line
segments and the same glyph described as seven B\`ezier splines. Storage
for this glyph was reduced from 99 to 52 bytes.
\begin{figure}[htbp]
\begin{centering}
\epsfig{file=glyph.eps}
\itshape
\caption{\itshape Converting Lines To Splines}
\label{fig:glyph}
\end{centering}
\end{figure}
\section{Glyph Hinting}
\noindent Given the desire to present text at a variety of sizes, the basic
glyph shapes need to undergo a scaling transformation and then be rasterized
to create an image. Unless this scaling is restricted to integer values,
the edges of the resulting strokes will not necessarily align with the pixel
grid. The resulting glyphs will appear fuzzy and will be hard to read.
To improve the appearance of the glyphs on the screen, a straightforward
mechanism was developed to reposition the glyph control points to improve
the rasterized result. The glyph data was augmented to include a list of X
and a list of Y coordinates. Each `snap' list contains values along the
respective axis where some point within the glyph is designed to lie on a
pixel boundary. These were constructed automatically by identifying all
vertical and horizontal segments of each glyph, including splines whos ends
are tangent to the vertical or horizontal.
The glyph coordinates are then scaled to the desired size. The two snap
lists (X and Y) are used to push glyph coordinates to the nearest pixel grid
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
to align the pen edges with the pixel edges. Figure~\ref{fig:hint} shows a
glyph being hinted in this fashion.
\begin{figure}[htbp]
\begin{centering}
\epsfig{file=hint.eps}
\itshape
\caption{\itshape Hinting A Glyph}
\label{fig:hint}
\end{centering}
\end{figure}
The effect is to stretch or shrink the glyph to align vertical and horizontal
strokes to the pixel grid. Glyphs designed with evenly spaced vertical or
horizontal stems (like `m') may end up unevenly spaced; a more sophisticated
hinting systems could take this into account by preserving the relative
spacing among multiple strokes.
\section{User Interface Objects}
\noindent With the basic window system supporting a single screen containing
many windows, the toolkit extends this model by creating a single top-level
widget. This top-level widget contains a single box for layout purposes.
Each box can contain a number of widgets or other boxes.
Layout within each box is done either horizontally or vertically with an
algorithm which comes from the Layout Widget\cite{layout:1993} that the
author developed for Xt\cite{xt} library. Each widget has a natural size
and stretch in both directions. The natural size and stretch of a box is
computed from the objects it contains. This forms the sole geometry
management mechnism within the toolkit and is reasonably competent at both
constructing a usable initial layout and adapting to externally imposed size
changes.
\section{Process \& Thread Model}
\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
parts of the window system in different threads:
\begin{kitemize}
\item
Input would run in one thread, events were dispatched without queuing
directly to the receiving object.
\item
Each window would have a thread to redisplay the window contents. These
threads would block on a semaphore awaiting a change in application state
before reconstructing the window contents. Per window locks could block
updates until the application state was consistent.
\item
The window system had a separate thread to compose the separate window
contents into the final screen display. The global redisplay thread would
block on a semaphore which the per-window redisplay threads would signal
when any window content changed. A global system lock could block updates
while any application state was inconsistent.
\end{kitemize}
This architecture was difficult to manage as it required per-task locking
between input and output. The lack of actual multi-tasking of the
application processing eliminated much of the value of threads.
Once this was working, support for threading was removed from the
custom operating system...
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
single logical task were removed.
Of course, once this was all working, the custom operating system was
replaced with ucLinux.
While the single thread model works fine in ucLinux, it would be nice to
split separate out tasks into processes. Right now, all of the tasks are
linked into a monolithic executable. This modularization work is
underway.
\section{Input Model}
\noindent A window system is responsible for collecting raw input data from
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
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
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
until the button is released.
Device events not associated with a pointer, such as keyboards, are routed
to a fixed `active' window. The active window is set under application
control, such as when a mouse button press occurs within an inactive window.
The active window need need not be the top-most window.
Under both the original multi-threaded model and the current single-threaded
model, there is no event queueing within the window system; events are
dispatched directly upon being received from a device. This is certainly
easy to manage and allows motion events to be easily discarded when the
system is too busy to process them. However, with the switch to multiple
independent processes running on ucLinux, it may become necesary to queue
events between the input collection agent and the application processing
them.
Within the toolkit, events are dispatched through each level of the
hierarchy. Within each box, keyboard events are statically routed to the
active box or widget while mouse events are routed to the containing box or
widget. By explicitly dispatching down each level, the containing widgets
and boxes can enforce whatever policy they like for event delivery,
including mouse or keyboard grabs, focus traversal and event replay.
While this mechanism is fully implemented, much investigation remains to be
done to explore what kinds of operations are useful and whether portions of
what is now application-defined behaviour should be migrated into common
code.
\section{Window Management}
\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
dispatch mechanism directs window management activities.
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.
\section{Status and Future Work}
\noindent As computing systems continue to press into ever smaller environments, the
ability to bring sophisticated user interface technologies along greatly
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
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.
\begin{figure}[htbp]
\begin{centering}
\epsfig{file=twin.eps}
\itshape
\caption{\itshape Sample Screen Image}
\label{fig:twin}
\end{centering}
\end{figure}
While the basic structure of the \twin\ window system is complete, the
toolkit is far from complete, having only a few rudementary 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.
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
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
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.
\bibliography{keithp}
\bibliographystyle{plain}
\end{document}
--- NEW FILE: twin.png ---
(This appears to be a binary file; contents omitted.)
--- NEW FILE: zrl.sty ---
%%%%% This file is a kludge until such time as I learn to do it elegantly. Sorry.
%% url - external. Intended for items which do not contain spaces, and
%% containing global options for obeying & breaking at spaces. But
%% we need to do change those things on the fly, so we're making a copy
%% of url.sty and defining two extra groups, zrl and xrl, that
%% permit handling these options on the fly.
%% Thus you can mix url without obeyspaces and/or spaces with the following:
%% zrl - url with obeyspaces,spaces turned on
%% xrl - url with obeyspaces turned on
% zrl.sty ver 1.4 02-Mar-1999 Donald Arseneau asnd at triumf.ca
% Copyright 1996-1999 Donald Arseneau, Vancouver, Canada.
% This program can be used, distributed, and modified under the terms
% of the LaTeX Project Public License.
%
% A form of \verb that allows linebreaks at certain characters or
% combinations of characters, accepts reconfiguration, and can usually
% be used in the argument to another command. It is intended for email
% addresses, hypertext links, directories/paths, etc., which normally
% have no spaces. The font may be selected using the \zrlstyle command,
% and new zrl-like commands can be defined using \zrldef.
%
% Usage: Conditions:
% \zrl{ } If the argument contains any "%", "#", or "^^", or ends with
% "\", it can't be used in the argument to another command.
% The argument must not contain unbalanced braces.
% \zrl| | ...where "|" is any character not used in the argument and not
% "{" or a space. The same restrictions as above except that the
% argument may contain unbalanced braces.
% \xyz for "\xyz" a defined-zrl; this can be used anywhere, no matter
% what characters it contains.
%
% See further instructions after "\endinput"
%
\def\Zrl at ttdo{% style assignments for tt fonts or T1 encoding
\def\ZrlBreaks{\do\.\do\@\do\\\do\/\do\!\do\_\do\|\do\%\do\;\do\>\do\]%
\do\)\do\,\do\?\do\'\do\+\do\=}%
\def\ZrlBigBreaks{\do\:\do at zrl@hyp}%
\def\ZrlNoBreaks{\do\(\do\[\do\{\do\<}% (unnecessary)
\def\ZrlSpecials{\do\ {\ }}%
\def\ZrlOrds{\do\*\do\-\do\~}% any ordinary characters that aren't usually
}
\def\Xrl at ttdo{% style assignments for tt fonts or T1 encoding
\def\XrlBreaks{\do\.\do\@\do\\\do\/\do\!\do\_\do\|\do\%\do\;\do\>\do\]%
\do\)\do\,\do\?\do\'\do\+\do\=}%
\def\XrlBigBreaks{\do\:\do at xrl@hyp}%
\def\XrlNoBreaks{\do\(\do\[\do\{\do\<}% (unnecessary)
\def\XrlSpecials{\do\ {\ }}%
\def\XrlOrds{\do\*\do\-\do\~}% any ordinary characters that aren't usually
}
\def\Zrl at do{% style assignments for OT1 fonts except tt
\def\ZrlBreaks{\do\.\do\@\do\/\do\!\do\%\do\;\do\]\do\)\do\,\do\?\do\+\do\=}%
\def\ZrlBigBreaks{\do\:\do at zrl@hyp}%
\def\ZrlNoBreaks{\do\(\do\[\do\{}% prevents breaks after *next* character
\def\ZrlSpecials{\do\<{\langle}\do\>{\mathbin{\rangle}}\do\_{\_%
\penalty\@m}\do\|{\mid}\do\{{\lbrace}\do\}{\mathbin{\rbrace}}\do
\\{\mathbin{\backslash}}\do\~{\raise.6ex\hbox{\m at th$\scriptstyle\sim$}}\do
\ {\ }}%
\def\ZrlOrds{\do\'\do\"\do\-}%
}
\def\Xrl at do{% style assignments for OT1 fonts except tt
\def\XrlBreaks{\do\.\do\@\do\/\do\!\do\%\do\;\do\]\do\)\do\,\do\?\do\+\do\=}%
\def\XrlBigBreaks{\do\:\do at xrl@hyp}%
\def\XrlNoBreaks{\do\(\do\[\do\{}% prevents breaks after *next* character
\def\XrlSpecials{\do\<{\langle}\do\>{\mathbin{\rangle}}\do\_{\_%
\penalty\@m}\do\|{\mid}\do\{{\lbrace}\do\}{\mathbin{\rbrace}}\do
\\{\mathbin{\backslash}}\do\~{\raise.6ex\hbox{\m at th$\scriptstyle\sim$}}\do
\ {\ }}%
\def\XrlOrds{\do\'\do\"\do\-}%
}
\def\zrl at ttstyle{%
\@ifundefined{selectfont}{\def\ZrlFont{\tt}}{\def\ZrlFont{\ttfamily}}\Zrl at ttdo
}
\def\xrl at ttstyle{%
\@ifundefined{selectfont}{\def\XrlFont{\tt}}{\def\XrlFont{\ttfamily}}\Xrl at ttdo
}
\def\zrl at rmstyle{%
\@ifundefined{selectfont}{\def\ZrlFont{\rm}}{\def\ZrlFont{\rmfamily}}\Zrl at do
}
\def\xrl at rmstyle{%
\@ifundefined{selectfont}{\def\XrlFont{\rm}}{\def\XrlFont{\rmfamily}}\Xrl at do
}
\def\zrl at sfstyle{%
\@ifundefined{selectfont}{\def\ZrlFont{\sf}}{\def\ZrlFont{\sffamily}}\Zrl at do
}
\def\xrl at sfstyle{%
\@ifundefined{selectfont}{\def\XrlFont{\sf}}{\def\XrlFont{\sffamily}}\Xrl at do
}
\def\zrl at samestyle{\ifdim\fontdimen\thr@@\font=\z@ \zrl at ttstyle \else
\zrl at rmstyle \fi \def\ZrlFont{}}
\def\xrl at samestyle{\ifdim\fontdimen\thr@@\font=\z@ \xrl at ttstyle \else
\xrl at rmstyle \fi \def\XrlFont{}}
\@ifundefined{strip at prefix}{\def\strip at prefix#1>{}}{}
\@ifundefined{verbatim at nolig@list}{\def\verbatim at nolig@list{\do\`}}{}
\def\Zrl{%
\begingroup \let\zrl at moving\relax\relax \endgroup
\ifmmode\@nomatherr$\fi
\ZrlFont $\fam\z@ \textfont\z@\font
\let\do\@makeother \dospecials % verbatim catcodes
\catcode`{\@ne \catcode`}\tw@ \catcode`\ 10 % except braces and spaces
\medmuskip0mu \thickmuskip\medmuskip \thinmuskip\medmuskip
\@tempcnta\fam\multiply\@tempcnta\@cclvi
\let\do\set at mathcode \ZrlOrds % ordinary characters that were special
\advance\@tempcnta 8192 \ZrlBreaks % bin
\advance\@tempcnta 4096 \ZrlBigBreaks % rel
\advance\@tempcnta 4096 \ZrlNoBreaks % open
\let\do\set at mathact \ZrlSpecials % active
\let\do\set at mathnolig \verbatim at nolig@list % prevent ligatures
\@ifnextchar\bgroup\Zrl at z\Zrl at y}
\def\Zrl at y#1{\catcode`{11 \catcode`}11
\def\@tempa##1#1{\Zrl at z{##1}}\@tempa}
\def\Zrl at z#1{\def\@tempa{#1}\expandafter\expandafter\expandafter\Zrl at Hook
\expandafter\strip at prefix\meaning\@tempa\ZrlRight\m at th$\endgroup}
\def\Zrl at Hook{\ZrlLeft}
\let\ZrlRight\@empty
\let\ZrlLeft\@empty
\def\Xrl{%
\begingroup \let\xrl at moving\relax\relax \endgroup
\ifmmode\@nomatherr$\fi
\XrlFont $\fam\z@ \textfont\z@\font
\let\do\@makeother \dospecials % verbatim catcodes
\catcode`{\@ne \catcode`}\tw@ \catcode`\ 10 % except braces and spaces
\medmuskip0mu \thickmuskip\medmuskip \thinmuskip\medmuskip
\@tempcnta\fam\multiply\@tempcnta\@cclvi
\let\do\set at mathcode \XrlOrds % ordinary characters that were special
\advance\@tempcnta 8192 \XrlBreaks % bin
\advance\@tempcnta 4096 \XrlBigBreaks % rel
\advance\@tempcnta 4096 \XrlNoBreaks % open
\let\do\set at mathact \XrlSpecials % active
\let\do\set at mathnolig \verbatim at nolig@list % prevent ligatures
\@ifnextchar\bgroup\Xrl at z\Xrl at y}
\def\Xrl at y#1{\catcode`{11 \catcode`}11
\def\@tempa##1#1{\Xrl at z{##1}}\@tempa}
\def\Xrl at z#1{\def\@tempa{#1}\expandafter\expandafter\expandafter\Xrl at Hook
\expandafter\strip at prefix\meaning\@tempa\XrlRight\m at th$\endgroup}
\def\Xrl at Hook{\XrlLeft}
\let\XrlRight\@empty
\let\XrlLeft\@empty
\def\set at mathcode#1{\count@`#1\advance\count@\@tempcnta\mathcode`#1\count@}
\def\set at mathact#1#2{\mathcode`#132768 \lccode`\~`#1\lowercase{\def~{#2}}}
\def\set at mathnolig#1{\ifnum\mathcode`#1<32768
\lccode`\~`#1\lowercase{\edef~{\mathchar\number\mathcode`#1_{\/}}}%
\mathcode`#132768 \fi}
\def\zrldef#1#2{\begingroup \setbox\z@\hbox\bgroup
\def\Zrl at z{\Zrl at def{#1}{#2}}#2}
\expandafter\ifx\csname DeclareRobustCommand\endcsname\relax
\def\Zrl at def#1#2#3{\m at th$\endgroup\egroup\endgroup
\def#1{#2{#3}}}
\else
\def\Zrl at def#1#2#3{\m at th$\endgroup\egroup\endgroup
\DeclareRobustCommand{#1}{#2{#3}}}
\fi
\def\xrldef#1#2{\begingroup \setbox\z@\hbox\bgroup
\def\Xrl at z{\Xrl at def{#1}{#2}}#2}
\expandafter\ifx\csname DeclareRobustCommand\endcsname\relax
\def\Xrl at def#1#2#3{\m at th$\endgroup\egroup\endgroup
\def#1{#2{#3}}}
\else
\def\Xrl at def#1#2#3{\m at th$\endgroup\egroup\endgroup
\DeclareRobustCommand{#1}{#2{#3}}}
\fi
\def\zrlstyle#1{\csname zrl@#1style\endcsname}
\def\xrlstyle#1{\csname xrl@#1style\endcsname}
% Sample (and default) configuration:
%
\newcommand\zrl{\begingroup \Zrl}
\newcommand\xrl{\begingroup \Xrl}
%
% picTeX defines \path, so declare it optionally:
\@ifundefined{path}{\newcommand\path{\begingroup \zrlstyle{tt}\Zrl}}{}
\@ifundefined{path}{\newcommand\path{\begingroup \xrlstyle{tt}\Xrl}}{}
%
% too many styles define \email like \address, so I will not define it.
% \newcommand\email{\begingroup \zrlstyle{rm}\Zrl}
% Process LaTeX \package options
%
\zrlstyle{tt}
%\let\Zrl at sppen\@M
\def\do at zrl@hyp{}% by default, no breaks after hyphens
%%%%%
\let\Zrl at sppen\relpenalty
\let\Zrl at Hook\relax
\xrlstyle{tt}
\let\Xrl at sppen\@M
\def\do at xrl@hyp{}% by default, no breaks after hyphens
\let\Xrl at Hook\relax
%%%%%
\@ifundefined{ProvidesPackage}{}{
\ProvidesPackage{zrl}[1999/03/02 \space ver 1.4 \space
Verb mode for zrls, email addresses, and file names]
\DeclareOption{hyphens}{\def\do at zrl@hyp{\do\-}\def\do at xrl@hyp{\do\-}}% allow breaks after hyphens
\DeclareOption{obeyspaces}{\let\Zrl at Hook\relax\let\Xrl at Hook\relax}% a flag for later
\DeclareOption{spaces}{\let\Zrl at sppen\relpenalty}
\DeclareOption{T1}{\let\Zrl at do\Zrl at ttdo\let\Xrl at do\Xrl at ttdo}
\ProcessOptions
\ifx\Zrl at Hook\relax % [obeyspaces] was declared
\def\Zrl at Hook#1\ZrlRight\m at th{\edef\@tempa{\noexpand\ZrlLeft
\Zrl at retain#1\Zrl at nosp\, }\@tempa\ZrlRight\m at th}
\def\Zrl at retain#1 {#1\penalty\Zrl at sppen\ \Zrl at retain}
\def\Zrl at nosp\,#1\Zrl at retain{}
\fi
\ifx\Xrl at Hook\relax % [obeyspaces] was declared
\def\Xrl at Hook#1\XrlRight\m at th{\edef\@tempa{\noexpand\XrlLeft
\Xrl at retain#1\Xrl at nosp\, }\@tempa\XrlRight\m at th}
\def\Xrl at retain#1 {#1\penalty\Xrl at sppen\ \Xrl at retain}
\def\Xrl at nosp\,#1\Xrl at retain{}
\fi
}
\edef\zrl at moving{\csname Zrl Error\endcsname}
\expandafter\edef\zrl at moving
{\csname zrl used in a moving argument.\endcsname}
\expandafter\expandafter\expandafter \let \zrl at moving\undefined
\edef\xrl at moving{\csname Xrl Error\endcsname}
\expandafter\edef\xrl at moving
{\csname xrl used in a moving argument.\endcsname}
\expandafter\expandafter\expandafter \let \xrl at moving\undefined
\endinput
%
% zrl.sty ver 1.4 02-Mar-1999 Donald Arseneau asnd at reg.triumf.ca
%
% This package defines "\zrl", a form of "\verb" that allows linebreaks,
% and can often be used in the argument to another command. It can be
% configured to print in different formats, and is particularly useful for
% hypertext links, email addresses, directories/paths, etc. The font may
% be selected using the "\zrlstyle" command and pre-defined text can be
% stored with the "\zrldef" command. New zrl-like commands can be defined,
% and a "\path" command is provided this way.
%
% Usage: Conditions:
% \zrl{ } If the argument contains any "%", "#", or "^^", or ends with
% "\", it can't be used in the argument to another command.
% The argument must not contain unbalanced braces.
% \zrl| | ...where "|" is any character not used in the argument and not
% "{" or a space. The same restrictions as above except that the
% argument may contain unbalanced braces.
% \xyz for "\xyz" a defined-zrl; this can be used anywhere, no matter
% what characters it contains.
%
% The "\zrl" command is fragile, and its argument is likely to be very
% fragile, but a defined-zrl is robust.
%
% Package Option: obeyspaces
% Ordinarily, all spaces are ignored in the zrl-text. The "[obeyspaces]"
% option allows spaces, but may introduce spurious spaces when a zrl
% containing "\" characters is given in the argument to another command.
% So if you need to obey spaces you can say "\usepackage[obeyspaces]{zrl}",
% and if you need both spaces and backslashes, use a `defined-zrl' for
% anything with "\".
%
% Package Option: hyphens
% Ordinarily, breaks are not allowed after "-" characters because this
% leads to confusion. (Is the "-" part of the address or just a hyphen?)
% The package option "[hyphens]" allows breaks after explicit hyphen
% characters. The "\zrl" command will *never ever* hyphenate words.
%
% Package Option: spaces
% Likewise, breaks are not usually allowed after spaces under the
% "[obeyspaces]" option, but giving the options "[obeyspaces,spaces]"
% will allow breaks at those spaces.
%
% Package Option: T1
% This signifies that you will be using T1-encoded fonts which contain
% some characters missing from most older (OT1) encoded TeX fonts. This
% changes the default definition for "\zrlstyle{rm}".
%
% Defining a defined-zrl:
% Take for example the email address "myself%node at gateway.net" which could
% not be given (using "\zrl" or "\verb") in a caption or parbox due to the
% percent sign. This address can be predefined with
% \zrldef{\myself}\zrl{myself%node at gateway.net} or
% \zrldef{\myself}\zrl|myself%node at gateway.net|
% and then you may use "\myself" instead of "\zrl{myself%node at gateway.net}"
% in an argument, and even in a moving argument like a caption because a
% defined-zrl is robust.
%
% Style:
% You can switch the style of printing using "\zrlstyle{tt}", where "tt"
% can be any defined style. The pre-defined styles are "tt", "rm", "sf",
% and "same" which all allow the same linebreaks but different fonts --
% the first three select a specific font and the "same" style uses the
% current text font. You can define your own styles with different fonts
% and/or line-breaking by following the explanations below. The "\zrl"
% command follows whatever the currently-set style dictates.
%
% Alternate commands:
% It may be desireable to have different things treated differently, each
% in a predefined style; e.g., if you want directory paths to always be
% in tt and email addresses to be rm, then you would define new zrl-like
% commands as follows:
%
% \newcommand\email{\begingroup \zrlstyle{rm}\Zrl}
% \newcommand\directory{\begingroup \zrlstyle{tt}\Zrl}
%
% You must follow this format closely, and NOTE that the final command is
% "\Zrl", not "\zrl". In fact, the "\directory" example is exactly the
% "\path" definition which is pre-defined in the package. If you look
% above, you will see that "\zrl" is defined with
% \newcommand\zrl{\begingroup \Zrl}
% I.e., using whatever zrl-style has been selected.
%
% You can make a defined-zrl for these other styles, using the usual
% "\zrldef" command as in this example:
%
% \zrldef{\myself}{\email}{myself%node.domain at gateway.net}
%
% which makes "\myself" act like "\email{myself%node.domain at gateway.net}",
% if the "\email" command is defined as above. The "\myself" command
% would then be robust.
%
% Defining styles:
% Before describing how to customize the printing style, it is best to
% mention something about the unusual implementation of "\zrl". Although
% the material is textual in nature, and the font specification required
% is a text-font command, the text is actually typeset in *math* mode.
% This allows the context-sensitive linebreaking, but also accounts for
% the default behavior of ignoring spaces. Now on to defining styles.
%
% To change the font or the list of characters that allow linebreaks, you
% could redefine the commands "\ZrlFont", "\ZrlBreaks", "\ZrlSpecials" etc.
% directly in the document, but it is better to define a new `zrl-style'
% (following the example of "\zrl at ttstyle" and "\zrl at rmstyle") which defines
% all of "\ZrlBigbreaks", "\ZrlNoBreaks", "\ZrlBreaks", "\ZrlSpecials", and
% "\ZrlFont".
%
% Changing font:
% The "\ZrlFont" command selects the font. The definition of "\ZrlFont"
% done by the pre-defined styles varies to cope with a variety of LaTeX
% font selection schemes, but it could be as simple as "\def\ZrlFont{\tt}".
% Depending on the font selected, some characters may need to be defined
% in the "\ZrlSpecials" list because many fonts don't contain all the
% standard input characters.
%
% Changing linebreaks:
% The list of characters that allow line-breaks is given by "\ZrlBreaks"
% and "\ZrlBigBreaks", which have the format "\do\c" for character "c".
% The differences are that `BigBreaks' have a lower penalty and have
% different breakpoints when in sequence (as in "http://"): `BigBreaks'
% are treated as mathrels while `Breaks' are mathbins (see The TeXbook,
% p.170). In particular, a series of `BigBreak' characters will break at
% the end and only at the end; a series of `Break' characters will break
% after the first and after every following *pair*; there will be no
% break after a `Break' character if a `BigBreak' follows. In the case
% of "http://" it doesn't matter whether ":" is a `Break' or `BigBreak' --
% the breaks are the same in either case; but for DECnet nodes with "::"
% it is important to prevent breaks *between* the colons, and that is why
% colons are `BigBreaks'.
%
% It is possible for characters to prevent breaks after the next following
% character (I use this for parentheses). Specify these in "\ZrlNoBreaks".
%
% You can do arbitrarily complex things with characters by making them
% active in math mode (mathcode hex-8000) and specifying the definition(s)
% in "\ZrlSpecials". This is used in the rm and sf styles for OT1 font
% encoding to handle several characters that are not present in those
% computer-modern style fonts. See the definition of "\Zrl at do", which
% is used by both "\zrl at rmstyle" and "\zrl at sfstyle"; it handles missing
% characters via "\ZrlSpecials". The nominal format for setting each
% special character "c" is: "\do\c{<definition>}", but you can include
% other definitions too.
%
%
% If all this sounds confusing ... well, it is! But I hope you won't need
% to redefine breakpoints -- the default assignments seem to work well for
% a wide variety of applications. If you do need to make changes, you can
% test for breakpoints using regular math mode and the characters "+=(a".
%
% Yet more flexibility:
% You can also customize the verbatim text by defining "\ZrlRight" and/or
% "\ZrlLeft", e.g., for ISO formatting of zrls surrounded by "< >", define
%
% \renewcommand\zrl{\begingroup \def\ZrlLeft{<zrl: }\def\ZrlRight{>}%
% \zrlstyle{tt}\Zrl}
%
% The meanings of "\ZrlLeft" and "\ZrlRight" are *not* reproduced verbatim.
% This lets you use formatting commands there, but you must be careful not
% to use TeX's special characters ("\^_%~#$&{}" etc.) improperly.
% You can also define "\ZrlLeft" to reprocess the verbatim text, but the
% format of the definition is special:
%
% \def\ZrlLeft#1\ZrlRight{ ... do things with #1 ... }
%
% Yes, that is "#1" followed by "\ZrlRight" then the definition. For
% example, to put a hyperTeX hypertext link in the DVI file:
%
% \def\ZrlLeft#1\ZrlRight{\special{html:<a href="#1">}#1\special{html:</a>}}
%
% Using this technique, zrl.sty can provide a convenient interface for
% performing various operations on verbatim text. You don't even need
% to print out the argument! For greatest efficiency in such obscure
% applications, you can define a null zrl-style where all the lists like
% "\ZrlBreaks" are empty.
%
% Revision History:
% ver 1.1 6-Feb-1996:
% Fix hyphens that wouldn't break and ligatures that weren't suppressed.
% ver 1.2 19-Oct-1996:
% Package option for T1 encoding; Hooks: "\ZrlLeft" and "\ZrlRight".
% ver 1.3 21-Jul-1997:
% Prohibit spaces as delimiter characters; change ascii tilde in OT1.
% ver 1.4 02-Mar-1999
% LaTeX license; moving-argument-error
% The End
Test file integrity: ASCII 32-57, 58-126: !"#$%&'()*+,-./0123456789
:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
- Previous message: [Commit] papers/twin-ols2005 - New directory,NONE,NONE
- Next message: [Commit] papers/twin-ols2005 Makefile, 1.1, 1.2 README, NONE,
1.1 ols-fonts.tex, 1.1, 1.2 ols.sty, 1.1, 1.2 twin-ols2005.tex,
1.1, 1.2
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Commit
mailing list