summaryrefslogtreecommitdiff
path: root/usergrps/uktug/baskervi/7_1/lout.tex
diff options
context:
space:
mode:
Diffstat (limited to 'usergrps/uktug/baskervi/7_1/lout.tex')
-rw-r--r--usergrps/uktug/baskervi/7_1/lout.tex696
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