diff options
Diffstat (limited to 'usergrps/uktug/baskervi/7_1/lout.tex')
-rw-r--r-- | usergrps/uktug/baskervi/7_1/lout.tex | 696 |
1 files changed, 696 insertions, 0 deletions
diff --git a/usergrps/uktug/baskervi/7_1/lout.tex b/usergrps/uktug/baskervi/7_1/lout.tex new file mode 100644 index 0000000000..abee52f059 --- /dev/null +++ b/usergrps/uktug/baskervi/7_1/lout.tex @@ -0,0 +1,696 @@ +\title{The Future of Document Formatting (Working Paper)} + +\begin{Article} + +\section{Abstract} +Document formatting systems have reached a plateau. Although existing +systems are being steadily enhanced, the next major step forward will +require a union of the best features of batch formatters, interactive +document editors, and page description languages. This paper draws +on its author's twelve years of experience designing, implementing, +and enhancing the Lout document formatting system to identify the +remaining problems in document formatting and explore some possible +solutions. + +\section{Introduction} + +Document formatting is one of the most widespread applications of +computers. Improvements in document formatting software and the +hardware on which it is based have revolutionized the production +of documents and enlarged our conception of what a document might be. + +Any attempt at this point to define `document' would run a risk of +being overtaken by events; already documents commonly include moving +images, sound, and dynamic updating as their sources of information +change in real time. It is perhaps safe to say that a document +is information arranged for presentation to a person; the information may +be called the \emph{content}, and the arrangement its \emph{layout}. Document +formatting is essentially about mapping content to layout, although functions +that do not exactly fit this definition, such as spelling and grammar +checking, or even creation and editing of content, are often found in +document formatting systems. + +Document formatting systems fall into two camps. In one camp are +the interactive document editors, ranging from word processing systems +such as Microsoft Word~\cite {microsoft1996word} up to desktop +publishing systems such as FrameMaker~\cite {adobe1995frame} and +Interleaf~\cite {interleaf1996}. These offer an editable screen image +of the document layout. In the other camp are the batch formatters, such as +troff~\cite {ossanna1976troff}, Scribe~\cite {reid1980scribe}, +\TeX~\cite {knuth1984tex}, and Lout~\cite {kingston1995lout.program}, +which process text files with embedded markup to produce non-editable +layout. In this paper the above names will stand for the entire +software family; \TeX\ includes \LaTeX~\cite {lamport1986latex}, +FrameMaker includes FrameMaker+SGML, and so on. Somewhere in between +are the hypertext~\cite {goldfarb1991hytime} net browsers, based on +HTML, which are primitive batch formatters offering limited interactivity +such as the ability to click on a hyperlink or fill in a form. + +All of these systems are being actively enhanced by their developers, +with new versions appearing regularly. For example, FrameMaker and +Interleaf have responded to the World-Wide Web phenomenon by adding +support for SGML~\cite {goldfarb1990sgml} and HTML. Nevertheless, +viewed from a wider perspective, they all appear to have reached a plateau, +in the sense that each has fundamental limitations that are not +likely to be overcome. For example, troff, \TeX\ and Lout are batch +formatters% (except for Lyx~\cite {ettrich1996lyx}) +and are not likely to become interactive; FrameMaker and Interleaf +are not as extensible as the batch formatters and, again, are not +likely to become so. + +One frequently hears arguments for or against these systems, but the +truth is that none of them is ideal yet all have something to offer +to the future of document formatting. What is needed now is a +synthesis of the best features of all of these systems. + +Papers which reflect on document formatting seem to be very rare. The +survey paper by Furuta, Scofield and Shaw~\cite {furuta1982survey} +is still well worth reading; Kernighan~\cite {kernighan1989retro} +reflects on the troff family; this author has described the design +and implementation of Lout~\cite {kingston1993lout.design}. But for +the most part one has to infer principles from the systems themselves, +and to look among the specialized applications such as music +formatting~\cite {foxley1987music}, graph +drawing \cite {kernighan1982pic, vanwyk1980, krishnamurthy1995unix}, +or non-European languages for requirements. + +This paper draws on its author's twelve years of experience in +designing, implementing, and enhancing the Lout document formatting +system, plus his more limited experience of the systems mentioned +above, to identify a set of requirements for a document formatting +system that would be a significant advance on all current systems, and +to explore their interactions. + + +\section{Requirements} + + +This section identifies the most significant requirements for a document +formatting system. Efficiency in space will cease to be a requirement +in the next few years. Efficiency in time is of course essential, as +are other requirements that apply to any large software system, such +as robustness, openness, and an interface that permits users of varying +levels of expertise to work productively. + +The other requirements are editability, extensibility, generality, and +optimality. Each of these requirements is discussed in turn in the sections +that follow, together with problems that it presents either alone +or in conjunction with previous requirements. + +It is not possible to prove that this list of requirements is complete, but +the author has carefully compared it against the features of most of the +document formatting systems listed earlier. The only major omission has +been the convenience features commonly found in interactive systems, +such as spelling and grammar checkers, input and output in a variety of +data formats, version control, and so on. These are valuable features, +but they have little to do with document formatting in the core sense +of mapping content to layout. + + +\subsection{Editability} + + +Editability, the ability to edit content while viewing layout, is the +strong suit of word processing and desktop publishing systems. Fairly +or not fairly, many users will not accept batch formatting. Also, the +batch formatting edit-format-view cycle is too slow when the +layout rule is `what pleases the eye,' such as in diagrams, or when +content must be altered to achieve a good layout, for example in +paragraphs containing long unbreakable inline equations. + +Interactive interfaces also have an advantage when the logical structure +does not follow a tree pattern. A good example is the editing of +graphs (the combinatorial kind). Users of an interactive system can +click on any pair of nodes to indicate that they are to be joined by +an edge. In a batch system, because the structure is not tree-like, +it is necessary for the user to invent names for the nodes and use the +names when creating edges, which is considerably more error-prone. By +contrast, equations do follow a tree pattern and so there is never any +need to attach names to subexpressions. + +Critics of interactive systems typically complain about the lack +of content structure in interactive editors, and also about their +weakness as editors compared with good text editors. Neither problem +would seem to be inherent, and in fact recent versions of high-end +document editors (FrameMaker+SGML for example) are addressing the +content structure problem. + +Openness to such auxiliary applications as free-text search and +retrieval and creation of documents by computer programs requires +that an archive format based on marked-up text be included in any +interactive system. It only takes a little care to make such a +format readable by humans. Thus an interactive system is automatically +also a batch system. + + +\subsection{Extensibility} + + +Extensibility in a document formatting system means the easy addition +of new features. It is the strong suit of batch formatters. For +example, this author's Lout system has no built-in knowledge of +equations, tables, or page layout (not even the concept of a page is +built-in); these are all added by means of packages of definitions +written in the Lout language, which is sufficiently high-level to +make them fairly easy to produce. + +Extensibility implies some initial kernel of primitive features upon +which the extensions are built. These would include horizontal and +vertical stacking, rotation, and so on. The most interesting such +feature is the mechanism for getting floating figures and footnotes +into their places: diversions and traps in troff, floating insertions +in \TeX, galleys in Lout. There must also be ways of combining and +packaging the primitives into features useful to the end user. + +Although a system not built on such a kernel is conceivable, it seems +scarcely possible to this author that such a system could supply all +the features demanded by end users. The list is so vast -- equations, +tables, graphs, chemical molecules, music, and so on -- that some +kind of high-level kernel language seems essential to achieving them +in any reasonable time and with any consistency, just as high-level +programming languages are essential to large software projects. + +Typography generates requirements for many features, such as hyphenation, +spacing and kerning, ligatures, and so on. A document formatting system +must produce good typography, because end users cannot be expected to +do it themselves. Many of these features are dependent on the current +language, and many English or European-oriented systems have failed to +be extensible to the typography of languages outside that sphere. A good +source of features needed in world-wide typography is Apple Computer's +QuickDraw GX~\cite {apple1996quickdraw}, although their approach of +implementing the features in C is relatively non-extensible since it +requires recompilation. + +When an interactive system is extended with a new feature, it must be +possible to continue editing in its vicinity. + +Ultimately, the layout of a document is a function of its content, so we +may identify features with functions. In extreme cases, such as optimal +layout, a function may take the entire document as its parameter; but +usually it has small, clearly delimited parameters as in +\[\mathit{ built\_up\_fraction(numerator, denominator)}\] +There may also be implicit parameters inherited from the context, such +as the current font size. + +It is quite reasonable to insist that within any editing session the +collection of features be immutable. Thus it is not essential to be +able to edit the definition of any function while viewing any +layout. In some cases, such as simple abbreviations, editing of +definitions is quite simple and could easily be supported. But more +complex functions, such as optimal layout or graph layout, are defined by +computer programs and so are not amenable to editing in this way. + +In a similar vein, it is correct to insist that those parts of the +layout originating within definitions be immutable. For example, the +bar in a built-up fraction should not be editable. This does not +preclude the addition of parameters to $\mathit{ built\_up\_fraction}$ to +control the appearance of the bar if desired, but to allow the user to +arbitrarily change the bar would produce a layout whose origin as a +built-up fraction must be lost. + +Thus, editability of features really only means editability of their +parameters. + +The most favourable case occurs when the function displays a parameter +in a form similar to that which it would have taken if it had been +entered outside the function. For example, $\mathit{ built\_up\_fraction}$ +displays both its parameters, changing their appearance only slightly +(by squeezing vertical spacing within them, and possibly changing the +font size). The user can edit such a parameter as though +it was not a parameter at all, and so (inductively) can edit parameters +of parameters and so on without limit. This is essentially how equation +editors work, and the Lilac system~\cite {brooks1991lilac} has +demonstrated it in an extensible framework, although using a kernel +language too incomplete to support the full range of features required +by users. A function may display a parameter more than once, in +which case editing one display must change them all. + +Preserving editability of displayed parameters is a difficult problem +when the function is implemented externally to the document editing +system. For example, if an external graph layout +program~\cite {krishnamurthy1995unix} is employed, +the result cannot be returned as a bitmap or PostScript file; rather +a set of coordinate pairs or something similar is required so that the +document formatter can place the nodes itself and hence understand +where they ended up. + +It has been suggested that a non-editable result is acceptable in such +cases if a click in the region it occupies signals the opening of a separate +editor that does undertand what is going on in that region. This is the +interactive equivalent of the preprocessor approach used by troff, and +it has the same drawbacks of lack of consistency, duplication of +features, and loss of generality (since even if every editor may +invoke every other editor, the communication channels between them typically +cannot convey such information as the current font, available space, and +so on). An architecture based on a single master editor with slave +non-interactive formatting programs is preferable. + +Parameters which are not displayed are a nightmare, and are responsible +for much of what is ad-hoc in existing interactive systems. Two main +approaches are in use. The first is the `style sheet' or `dialogue box' +approach, in which the user who selects a feature with non-displayed +parameters is presented with a box listing them and asked to supply +values: a font name, a location to place a figure, a style of +numbering, or whatever. This is the most general method, easily adapted +for use in an extensible system. It works particularly well when the +parameters have sensible default values, for then use of the box is +optional, and when they have only a small range of possible values, for +then the values may be displayed in a menu. + +Second is the `inference' method. Every parameter has some effect on +layout, otherwise it would be useless. So the user is offered a means +of manipulating layout, and the parameter's value is +inferred from it. For example, most editors permit an included graphic +to be clipped by clicking on its boundary and moving the mouse; scaling +and even rotation may be set by such means. Drawing programs allow +nodes to be dragged about in the drawing area. `Master pages' or +`template pages,' which allow the user to specify entire page layouts +involving many parameters simultaneously, demonstrate the value +of the inference method. + +The great drawback of the inference method is that an inference +interface has to be invented for every non-displayed parameter, and this is +difficult in an extensible system. However, it should at least be +possible to implement an inference interface for all suitable non-displayed +parameters of kernel features, such as the $\mathit{ boundary}$ parameter +of $\mathit{ clip()}$, and in cases such as +\begin{eqnarray*} +\lefteqn{ + \mathit{define\ user\_level\_feature}(\mathit{\dots,boundary,\dots}) = + }\\ +&& \dots \mathit{clip}(\mathit{\dots, boundary, \dots}) \dots +\end{eqnarray*} +to propagate this interface upwards from kernel features to user level +features. Then every user level feature that offers clipping as a +parameter, for example, will do so in the same way. + + +\subsection{Generality} + + +By generality we will mean the absence of illogical restrictions on the +use of features, either in the contexts in which they may be used, or +in the values that may be assigned to their parameters. (These are +formally the same thing, but the distinction is useful.) + +Examples of illogical context restrictions are extremely common in +document formatting systems. FrameMaker permits objects to be +rotated in certain contexts (when they are table entries, for example) +but not others. In troff it is very easy to include an equation within +a table, but very much harder to include a table in an equation. Not +all context restrictions are illogical, of course: a chapter should +not begin within a table, for example. + +Lack of context generality takes a severe toll, because it means that +implementation code, possibly highly sophisticated and with a great deal +to offer, is locked into a few limited contexts. For example, FrameMaker +has a very interesting equation editor, but there seems to be no hope +that its code can be used for such tasks as editing tree diagrams or +diagrams of chemical molecules, despite the technical similarities +among these tasks. + +Examples of illogical domain restrictions are particularly common among +geometrical functions. For example, \LaTeX\ will produce lines only at +certain fixed angles, and most systems only really understand rectangular +shapes. The PostScript page description language~\cite {adobe1990ps} +is far ahead of everything else in geometrical +generality: in PostScript, arbitrary curves (even disconnected ones) +made of lines, arcs, and Bezier curves may be drawn and filled, and +arbitrary combinations of rotation, scaling and translation may be +applied to arbitrarily complex fragments of documents lying within one page. + +The abandonment of rectangles in favour of arbitrary shapes would have +widespread beneficial effects if done in full generality. Text could fill +arbitrary shapes and run around arbitrary graphics. Fonts could be defined +(as they are in PostScript) as collections of arbitrary shapes, permitting +kerning of arbitrary pairs of glyphs, not just glyphs of equal font and +font size as at present, thus solving the subscript kerning problem. Line +spacing could reflect the true appearance of lines, not be crudely based on +the highest ascender and lowest descender. Optimizations based on bounding +boxes and caching should be able to solve the efficiency problems. + + +\subsection{Optimality} + + +By optimality is meant the ability to find the best possible layout for +the given content. An optimal layout is not necessarily a good layout, +because some documents have no good layout. Optimal layout thus cannot +remove the burden of rewriting content to achieve good layout, but in +practice it does greatly reduce that burden, and this is why it is has +been included. + +The idea that layout could be optimal seems to be due to Knuth and +Plass~\cite {knuth1981bpl}, who presented an algorithm for the optimal +breaking of a paragraph into lines which is used in Knuth's \TeX\ +system. Research work was done on more general optimality as +well~\cite {plass1981}, although this author is unsure how much of this +work was incorporated into \TeX. + +Suitably generalized, their paragraph breaking algorithm is as follows. The +first step is to deduce from the content a sequence of atomic formatting +steps. For example, the content +\[\mathit{The\ cat\ sat\ on\ the\ mat}\] +might have sequence +\[\begin{array}{l} +\mathit{create\_empty\_paragraph}\\ +\mathit{add\_word\_to\_paragraph(The)}\\ +\mathit{add\_word\_to\_paragraph(cat)}\\ +\dots +\end{array}\] +Every prefix of this sequence should define a legal document in its own +right; the whole sequence defines the document we wish to format. The +question as to what constitutes an atomic operation is not of fundamental +importance; one could choose to add one letter at a time, or an entire +paragraph. + +Define a \emph{badness} function from layouts to integers. Small values +indicate good layouts, large values indicate poor ones. There are no +restrictions on how this function is defined, except the practical one +of being computable in a reasonable time. + +Now there will be several ways in which each atomic step may be +performed. For example, +$\mathit{ add\_word\_to\_paragraph}$ could add its word to the end of the +current line, or it could start a new line, or it could even start a +new page or column. This leads to a tree structure: + +\begin{picture}(160,100) + +\put(45,40){\framebox(24,12)[l]{\ The}} + +\put(105,34){\framebox(22,22){}} +\put(105,40){\makebox(21,20)[l]{\ The}} +\put(105,30){\makebox(21,20)[l]{\ cat}} + +\put(105,77){\framebox(41,14)[l]{\ The cat}} + + +\put(105,0){\framebox(46,14)[l]{\ The $|$ cat}} + +\put(69,52){\vector(1,1){36}} +\put(69,46){\vector(1,0){36}} +\put(69,40){\vector(1,-1){36}} +\end{picture} + +\noindent +Each node is a layout of a partial document, each edge is one atomic +operation. + +The next atomic operation is applied to each leaf node, creating more +partial documents, and so on until the sequence ends and the leaf +nodes represent all layouts of the document of interest. The leaf node +of minimum badness is the optimal layout. + +This model can incorporate diverging operation sequences caused by +layout dependencies. For example, suppose the word \emph{abacus} has an +index entry attached to it, and that along one path in the tree this +word appears on page 99, while along another it appears on page +100. Then, in the sequence of operations defining the index, we will +find +%@ID @OneRow lines @Break @Eq { +\[ +\begin{array}{l} +\ldots\\ +\mathit{add\_word\_to\_paragraph(abacus)}\\ +\mathit{add\_word\_to\_paragraph(99)}\\ +\ldots +\end{array} +\] +along one path, and +%@ID @OneRow lines @Break @Eq { +\[ +\begin{array}{l} +\ldots\\ +\mathit{add\_word\_to\_paragraph(abacus)}\\ +\mathit{add\_word\_to\_paragraph(100)}\\ +\ldots +\end{array} +\] +along the other. However, forward references create cyclic dependencies +which cannot be handled in this way. For them, it seems to be necessary to +add operations which change the value of words that have already been +laid out, and to propagate the resulting changes until they die out. In +rare cases this method will cycle forever, but in practice it is probably +not difficult to avoid this problem using tricks such as refusing to +allow a revision to reduce the number of lines allocated to a paragraph. + +The algorithm as expressed has exponential time complexity. In practice, +however, the number of different layouts of a document that are close +enough to optimal to deserve examination is likely to be quite small. The +challenge, then, is to find ways to prune the layout tree severely while +retaining enough of it to discover, for example, that setting a sequence +of paragraphs tight or loose will avoid a bad page break further on. This +is an area needing detailed research; we can only glance at a few obvious +possibilities here. + +If the badness function is monotone increasing along every operation +sequence, then a bad node can only have worse successors, and this +justifies pruning its entire subtree. Monotonicity is not guaranteed +(for example, adding one word to a paragraph which has a widow word will +reduce its badness) but it is probable that tricks such as ignoring +widow words in incomplete paragraphs can bring us near enough to +monotonicity to justify pruning bad nodes. + +One immediate application is to prune nodes whose layouts are obviously +terrible, such as nodes containing clearly premature line endings or +page endings. Indeed, it should be possible to avoid even generating +such nodes. + +When it can be established that two nodes are equivalent, in the sense +that they lay out the same subsequence and their layouts occupy the same +space, their future careers must be identical and the worst of the two +may be pruned. The tree structure becomes a graph, and the optimal +layout algorithm may be viewed as a shortest path algorithm, as described +by Knuth~\cite {knuth1984tex}. + +Establishing the equivalence of two nodes may not be easy. There certainly +is not time for complex comparisons of all pairs of layouts +of a given subsequence. Knuth and Plass's +algorithm recognises that two nodes are equivalent when they lay out +the same subsequence and the most recent choice on the path to each was +to start a new line. This same idea may be used to equivalence all +paths into one at the new-page operation preceding a new chapter. + +Another useful idea is to group operations together, find optimal layouts +for the group separately, then introduce an atomic operation at a higher level +which represents the entire group. Grouping the operations that define +one paragraph in this way is very beneficial, for example. In +isolation, optimal pragraph breaking explores many options, but in the +end it is likely to return only at most two reasonable distinct results, +of~$n$ and ${ n+1}$ lines respectively for some~${ n}$, and +these become the only choices for the atomic $\mathit{add\_paragraph}$ +operation that represents the whole group at the higher level. Furthermore, +these two results may be cached and used without recalculation on every +path containing that particular \emph{ add\_paragraph} operation whenever +the margins have the same width. + +With care, suppressing tiny variations introduced by ascenders and descenders +on letters, the layout tree might be induced to contain only as many paths as +the difference in the total number of lines between the loosest and +tightest settings of the paragraphs inserted so far, and over the course of one +chapter this might be a manageable number. For safety, a fixed upper limit +could be placed on the number of nodes kept, producing a beam +search~\cite {winston1992} which would definitely bound the time complexity +to a fixed multiple of the cost of non-optimal layout, while sacrificing +guaranteed optimality. + +There do not seem to be any extra problems in incorporating optimality +into an extensible system. Users would certainly welcome options to +user-level features such as `insert this figure either following the +current line, or at the top of the next page, whichever looks +best.' Whether an editable system can offer optimal layout without +exceeding response time bounds is a matter for further research. There +should be time to maintain optimality of the current paragraph at least, +and if the current chapter is set within constant-width margins, it should +be no more time-consuming to maintain optimal layout in a twenty page chapter +than it is in a twenty line paragraph, provided the two alternative paragraph +breaks of each non-current paragraph of the chapter are cached. If the +cost does prove too great, optimality could be relegated to a button that +the user can press just before going for coffee. + + + + +\section{Conclusion} + + +This paper has demonstrated that a next-generation document formatting +system, incorporating the best features of current systems in full +generality, is neither logically inconsistent nor likely to be +infeasibily slow. + +The major design problem is the identification of a suitable kernel +of primitive features. Given the massive superstructure that this +kernel will support, its design quality must be of the highest. This +design was not attempted in this paper, but the author believes that the +kernel of the Lout document formatting system would make a good starting +point, although it is too incomplete, insufficiently general, too +large, and occasionally too imprecisely defined to serve as the kernel +of a next-generation system as it stands. + +The major implementation problem is to find optimizations that preserve +generality yet achieve the required response time. This paper has +pointed out optimizations that seem quite likely to be adequate on +hardware that will be widely available in a few years. + +It is also to be hoped that next-generation systems will finally lay to +rest the language issues that bedevil systems created within an English +or European language framework. Given sufficiently general primitives, +this should be an easy matter. + +\section{Acknowledgements} +The author gratefully acknowledges comments on +the first draft of this paper received from +Mike Dowling, +Ted Harding, +Robert Marsa, +and +Basile Starynkevitch. + +%\bibliographystyle{plain} +%\bibliography{lout} + +\begin{thebibliography}{10} + +\bibitem{adobe1990ps} +{Adobe Systems, Inc}. +\newblock {\em PostScript Language Reference Manual, Second Edition}. +\newblock Addison-Wesley, 1990. + +\bibitem{adobe1995frame} +{Adobe Systems, Inc}. +\newblock {\em Using FrameMaker+SGML}. +\newblock Adobe Systems, Inc., 1995. + +\bibitem{apple1996quickdraw} +{Apple Computer, Inc}. +\newblock {\em Quickdraw GX}. +\newblock 1996. +\newblock Available as \url{http://support.info.apple.com/gx/gx.html} + +\bibitem{brooks1991lilac} +Kenneth~P. Brooks. +\newblock Lilac: a two-view document editor. +\newblock {\em IEEE Computer}, pages 7--19, 1991. + +%\bibitem{ettrich1996lyx} +%Matthias Ettrich. +%\newblock {\em Lyx}. +%\newblock 1996. +%\newblock available as +% \url{http://www-ti.informatik.uni-tuebingen.de/~ettrich/}. + +\bibitem{foxley1987music} +Eric Foxley. +\newblock Music --- a language for typesetting music scores. +\newblock {\em Software---Practice and Experience}, 17:485--502, 1987. + +\bibitem{furuta1982survey} +Richard Furuta, Jeffrey Scofield, and Alan Shaw. +\newblock Document formatting systems: survey, concepts, and issues. +\newblock {\em Computing Surveys}, 14:417--472, 1982. + +\bibitem{goldfarb1990sgml} +Charles~F. Goldfarb. +\newblock {\em The SGML Handbook}. +\newblock Oxford University Press, 1990. +\newblock ISBN 0-19-853737-9. + +\bibitem{goldfarb1991hytime} +Charles~F. Goldfarb. +\newblock Hytime: a standard for structured hypermedia interchange. +\newblock {\em IEEE Computer}, 24:81--84, 1991. + +\bibitem{interleaf1996} +{Interleaf, Inc}. +\newblock {\em Interleaf 6 for Motif: next generation document creation, + composition and assembly}. +\newblock 1996. +\newblock Available as \url{http://www.interleaf.com/i6motifds.html} + +\bibitem{kernighan1982pic} +Brian~W. Kernighan. +\newblock Pic --- a language for typesetting graphics. +\newblock {\em Software--Practice and Experience}, 12:1--21, 1982. + +\bibitem{kernighan1989retro} +Brian~W. Kernighan. +\newblock The unix system document preparation tools: a retrospective. +\newblock {\em AT\&T Technical Journal}, 68:5--20, 1989. + +\bibitem{kingston1993lout.design} +Jeffrey~H. Kingston. +\newblock The design and implementation of the lout document formatting + language. +\newblock {\em Software--Practice and Experience}, 23:1001--1041, 1993. + +\bibitem{kingston1995lout.program} +Jeffrey~H. Kingston. +\newblock {\em The Lout Document Formatting System (Version 3)}. +\newblock 1995. +\newblock Available as \url{ftp://ftp.cs.usyd.edu.au/jeff/lout/} + +\bibitem{knuth1981bpl} +D.~E. Knuth and M.~E. Plass. +\newblock Breaking paragraphs into lines. +\newblock {\em Software--Practice and Experience}, 11:1119--1184, 1981. + +\bibitem{knuth1984tex} +Donald~E. Knuth. +\newblock {\em The {\TeX}Book}. +\newblock Addison-Wesley, 1984. + +\bibitem{krishnamurthy1995unix} +Balachander Krishnamurthy, editor. +\newblock {\em Practical Reusable UNIX Software}. +\newblock John Wiley, 1995. + +\bibitem{lamport1986latex} +Leslie Lamport. +\newblock {\em \LaTeX\ User's Guide and Reference Manual}. +\newblock Addison-Wesley, 1986. + +\bibitem{microsoft1996word} +{Microsoft, Inc.} +\newblock {\em Microsoft Word}. +\newblock Microsoft, Inc., 1996. +\newblock Available as \url{http://www.microsoft.com/msword/} + +\bibitem{ossanna1976troff} +Joseph~F. Ossanna. +\newblock ``nroff/troff'' user's manual. +\newblock Technical Report~54, Bell Laboratories, Murray Hill, NJ 07974, 1976. + +\bibitem{plass1981} +Michael~F. Plass. +\newblock {\em Optimal pagination techniques for automatic typesetting + systems}. +\newblock PhD thesis, Stanford, CA, 1981. + +\bibitem{reid1980scribe} +Brian~K. Reid. +\newblock A high-level approach to computer document production. +\newblock In {\em Proceedings of the 7th Symposium on the Principles of + Programming Languages (POPL), Las Vegas NV}, pages 24--31, 1980. + +\bibitem{winston1992} +P.~H. Winston. +\newblock {\em Artificial Intelligence}. +\newblock Addison-Wesley, third edition edition, 1992. + +\bibitem{vanwyk1980} +Christopher J.~Van Wyk. +\newblock {\em A language for typesetting graphics}. +\newblock PhD thesis, Stanford, CA, 1980. + +\end{thebibliography} + +\author{Jeffrey H. Kingston\\ + \texttt{jeff@cs.usyd.edu.au}} +%\email{jeff@cs.usyd.edu.au } +%\address{Basser Department of Computer Science\\ +% The University of Sydney 2006\\ +% Australia} + +\end{Article}
\ No newline at end of file |