diff options
Diffstat (limited to 'Master/texmf-dist/doc/latex3/xor/xo-pfloat.tex')
-rw-r--r-- | Master/texmf-dist/doc/latex3/xor/xo-pfloat.tex | 1623 |
1 files changed, 1623 insertions, 0 deletions
diff --git a/Master/texmf-dist/doc/latex3/xor/xo-pfloat.tex b/Master/texmf-dist/doc/latex3/xor/xo-pfloat.tex new file mode 100644 index 00000000000..2835b0ed017 --- /dev/null +++ b/Master/texmf-dist/doc/latex3/xor/xo-pfloat.tex @@ -0,0 +1,1623 @@ +% Copyright 2000 Frank Mittelbach +% All rights reserved +% +% +% NOTE: the text contains reference to the fact that it is typeset +% using the new OR! +% +\def\rcsdata$#1: #2,v #3${ + \def\rcsdata{#2 #3}} +\rcsdata$Id: xo-pfloat.tex,v 1.19 2000/08/11 07:08:04 latex3 Exp $ + +% next lines needs pdflatex 0.14f+ !!!! +\ifx\rpcode\undefinedcsname +\else + \input protcode.tex + \pdfprotrudechars=2 +% \pdfoutput=0 +\fi + +\tolerance=6000 +\emergencystretch=1cm + +%\tracingonline=1 +%\tracingpages=1 +%\showoutput + +\newcount\ProcessControl + +% 0 means std LaTeX, 1 new OR, 2 new OR + galley2 (not functional) + +\ProcessControl=1 + +\typein[\ProcessControl] + {^^J^^J0 means std LaTeX, 1 new OR +%, 2 new OR + galley2 (needs *new* LaTeX) + } + + +\newcommand\ORspecial[1]{\ifnum\ProcessControl>0\relax#1\fi} + + + +\ifnum\ProcessControl=0 + \documentclass[twocolumn]{article} +% \documentclass[preprint]{ltugproc} + \renewcommand\floatpagefraction{0.9} + \setlength\belowcaptionskip{10pt} +\else + \documentclass{article} +\fi + +\parskip=0pt +\widowpenalty=5000 + + +\usepackage{array,url,varioref} +\usepackage{times} + +\ifcase\ProcessControl +% \usepackage{hyperref} + \usepackage{calc} +\or +% \usepackage{trace} + \usepackage{xoutput} + \usepackage{xo-grid} + \ShowGridfalse +\else + \usepackage{trace, + galley2,xcontents,xlists-samples, + xoutput} + \usepackage{xo-grid} + \ShowGridfalse + + \let\thetable\thefigure % needed to be able to use old xcontents.sty +\fi + + + + +\ifnum\ProcessControl=2 + +\makeatletter +\def\l@v@lalgorithms{0} +\makeatother + +\DeclareInstance{contentsobject}{section}{std}{ + pre-v-action = \DelayEvaluation{\addpenalty{10000} + \addvspace{1em plus 1pt}}, + right-margin-sep = 15pt, + title-format = \textbf{#1}, + number-format = \textbf{#1\hfil}, + pnum-format = \textbf{\hfil#1}, + leaders-action = ~, + number-width = \DelayEvaluation{1.5em}} + +\DeclareInstance{contentsobject}{subsection}{std}{ + object-indent = \DelayEvaluation{1.5em}, + number-width = \DelayEvaluation{2.3em}} + +\DeclareInstance{contentsobject}{subsubsection}{std}{ + object-indent = \DelayEvaluation{3.8em}, + number-width = \DelayEvaluation{3.2em}} + + +\DeclareInstance{contentsobject}{figure}{std}{ + pre-v-action = , + right-margin-sep = 20pt, + title-format = \textit{#1}, + number-format = \textrm{\hfil#1}, + pnum-format = \textbf{\hfil#1}, + leaders-action = ~, + number-width = \DelayEvaluation{1.5em}} + + +\DeclareInstance{contentsobject}{table}{std}{ + pre-v-action = , + right-margin-sep = 15pt, + title-format = \textrm{#1}, + number-format = \textbf{#1\hfil}, + pnum-format = \textbf{\hfil#1}, + leaders-action = ~, + number-width = \DelayEvaluation{1.5em}} + +\fi + + + +\ifnum\ProcessControl> 0 + + +\DeclareFloatSequenceClass{floats} % this will vanish again + +\DeclareFloatType{figure} + { + sequence-class-id = floats, + toc-extension = lof, + caption-text = \figurename, + numbered-boolean = true, + numbered-id = figure, + numbered-within-id = , + numbered-action = \arabic{figure}, + body-decls = + } + + +\DeclareFloatType{table} + { + sequence-class-id = floats, + toc-extension = lot, + caption-text = \tablename, + numbered-boolean = true, + numbered-id = figure, + body-decls = \footnotesize, + } + +\DeclareFloatArea {t12} + { + class-close-list = , + all-close-list = , + max-float-num = 1, + } + + +\DeclareFloatArea {b12} + { + class-close-list = {t12,t11,b11}, + all-close-list = , + max-float-num = 1, + } + + +\DeclareFloatArea {t11} + { + class-close-list = , + all-close-list = {b11}, + max-float-num = 1, + } + + +\DeclareFloatArea {b11} + { + class-close-list = {t12,t11}, + all-close-list = , + max-float-num = 1, + } + + +\DeclareFloatArea {t21} + { + class-close-list = {t12,t11,b11}, + all-close-list = , + max-float-num = 1, + } + + +\DeclareFloatArea {b21} + { + class-close-list = {t12,t11,b11}, + all-close-list = , + max-float-num = 1, + } + + +\topskip=12pt + +\DeclareInstance{pagesetup2}{twocol}{std}{ + column-num = 2, + column-width = 229.5pt, % this strange value is what LaTeX2e + % uses for two column article + column-height = \DelayEvaluation 50\baselineskip + \topskip, + column-sep = 20pt, +% + float-callout-constraint = after, + float-callout-span-constraint = flexible, + bottom-float-footnote-constraint=forbidden, +% bottom-float-footnote-constraint=none, + max-float-num =2, +% + area-list = {t12,t11,b11,b12,t21}, + area-list = {b12,b11,b21}, +% +% footnote-setup = \UseTemplate{footnotesetup}{ftnright}{}, +% footnote-setup = \UseTemplate{footnotesetup}{margin}{}, + footnote-setup = \UseTemplate{footnotesetup}{std}{}, +% + float-text-sep = 36pt minus 8pt, + float-area-sep = 20pt, + float-float-sep = 20pt, +% + grid-point-sep = 12pt, + } + +\fi + + +\newcommand\meta[1]{\mbox{$\langle$\textit{#1}$\rangle$}} +\usepackage{shortvrb} +\MakeShortVerb\| + +\title{Formatting documents with floats\\ + A new algorithm for \LaTeXe$^*$} +\author{\copyright{} Frank Mittelbach} +\date{\rcsdata} + + + +\begin{document} + +\ORspecial{\UseInstance{pagesetup2}{twocol}} + + +\maketitle + +\tableofcontents + +\ORspecial\vfill + +\begin{abstract} +This paper describes an approach to placement of floats in +multicolumn documents. + +The current version of \LaTeX{} was originally written for +single-column documents and extended to support two-column documents by +essentially building each column independently from the other. As a +result the current system shows severe limitations in two column mode, +such as the fact that spanning floats are always deferred to at least the +next page or that numbering between column floats and spanning floats +can get out of sequence. + +The new algorithm is intended to overcome these limitations and at the +same time extend the supported class of document layouts to multiple +columns with floats spanning an arbitrary number of columns. +\end{abstract} + +%\ORspecial\vfill +\ORspecial\newpage + +\section{Introduction} + +One problem with formatting documents containing floats is the number +of potential formatting solutions that need to be checked out. The +number of trials grows combinatorially in the number of floats and +areas which can receive them. If we have $n$ floats waiting to be +placed and $m$ areas in which we can place them on the current page +being built (not counting the ``deferred area'') then the number of +different placements is given by +\begin{equation} + \#\mbox{trials} = + { n+m \atopwithdelims() m} = + \frac{(n+m)!}{n! \, m!} + \label{eq:binom} +\end{equation} +assuming that the order of floats has to be preserved, i.e., if the +call-out of float $f_i$ is before the call-out of $f_j$ in the text +stream then the float $f_i$ will be placed in earlier than float $f_j$ +where ``earlier'' is a defined relation of float areas. + + +For example, if we have 8 floats waiting to be distributed among 12 +areas (which corresponds to a three column page with float areas at the +top and bottom allowing for partial spans) then we have to check +125970 possible distributions; if two additional floats appear we end +up with 646646 trials. + +Even though a large number of these distributions would be +unacceptable and discardable straight away, after some initial test, +the resulting running time of the algorithm would clearly be beyond +any acceptable speed. (Assuming we could do 1000 trials per second, +which is ridiculous high since many of them would require +trial-typesetting the whole page, then the case of 646646 trials would +still take roughly 10 minutes to form a decision.) + + Thus it is important to find algorithms with +complexity that is at worst linear in both the number of floats on the +trial list and the number of possible float areas, even if this means +that in a few cases a relatively good layout will not be found. +It is even better if they have minimal redundancy. + + +Note that assessing the actual running time of \TeX{} code is not +straightforward since some activities are very much faster than +others. For example, performing a test by using a reasonable number +of macro expansions and register assignments may be very much slower +than running through a long typeset list and then doing a simple test. + + +The algorithm we have implemented fulfills the requirement of being +(essentially) linear in the number of floats and the number of float +areas. + + +\section{The document source model} + +The document source is a single stream of continuous text containing +call-outs to floating objects. (At the moment the call-outs are marked +by placing the objects into the stream but it would be possible to +provide them as separate objects.) +Floating objects (as of today) come in three incarnations: +\begin{itemize} +\item Objects where the call-out and the placement requires a strict +spatial relationship, e.g., same line in the margin. An example would +be marginal notes as implemented by |\marginpar| in \LaTeXe. +\item Objects where the call-out and the placement are required to fall +onto the same column/\allowbreak page/\allowbreak spread, e.g., +footnotes. +\item Objects where there is a defined relation between call-out and +object placement, e.g., ``not in an earlier column'', or ``on the same +page or later'', etc. These are the traditional floats. +\end{itemize} +Float objects in the last group are typed where the type is defined by +the logical content of the object, e.g., ``figure'', ``table'', and so on. + + +The document formatting is achieved using a minimal but customizable +lookahead (typically the considered galley material is the equivalent +of one page/\allowbreak spread of textual material ignoring the +additional size taken up by embedded float objects). + +While making up pages the main ``quality'' guidance for the algorithm +is to try to place each float as early as possible without violating +defined constraints. + + +\ORspecial\ShowGridtrue + + +\section{The document layout model} + +\subsection{Page layout grid} + +The algorithm supports the specification of a page grid on which it +will align text columns and other elements. This will allow (if +suitable parameters for various elements are chosen) to have text +lines of different columns all lying on grid points.\footnote{On the +current page lines are drawn to highlight the grid. Note that +headings, lists, and other ``display'' objects are not aligned.} + +\subsection{Columns} + +The page layouts which are supported by the new algorithm support +an arbitrary number of text columns of equal width. + +The number of columns per page as well as their width can be changed +at forced page breaks such as the start of chapters. + +\subsection{Balanced columns} + +Balancing columns (as done by the \texttt{multicol} package) is planned +but not implemented. The major problem in that area is the handling of +column floats during the balancing process. + + +\subsection{Float areas}\label{overlap} + +Float objects are distributed into float areas which are +rectangular in shape. Float areas span one or more text columns, their +horizontal size is therefore given by the following formula (where +$c$ is the number of columns spanned): +\[ + \meta{area-width} = c \times + \bigl( \meta{col-width} + \meta{col-sep}\bigr) + - \meta{col-sep} +\] +The naming conventions for float areas is as follows: +\[ +\meta{identifier}\meta{start-column}\meta{span-count}. +\] +The \meta{identifier} is a single letter denoting the type of area, +e.g., |t| for top, |b| for bottom. The \meta{span-count} is a single +digit denoting the number of columns to span. The +\meta{start-column} is a single digit\footnote{With a bit of care in +the code this could be extended to allow more than one digit.} +denoting the start column of the area. Thus |t23| is a top area +starting at column two and spanning three columns, i.e., two, three +and four. +A restriction due to the naming scheme is that currently no more than +9 columns are possible.\footnote{The scheme is different from the +original one used, where \texttt{t23} would have denoted an area +starting at column two and spanning until column three.} + +Only a subset of the float areas is allowed to be populated on a +page. In essence the new algorithm does not support placements +that result in ``splitting'' the text of a column due to a float (other +than column `here' floats).\footnote{Perhaps this restriction will be +lifted one day.} This means that population of some float areas +must be prevented, namely those satisfying these conditions +when $pcs$ (where $p=\textrm{pos}$, +$c=\textrm{column}$, $s=\textrm{span}$) has just been populated: +\[ + pij \textrm{ with } i < c \leq i+j < c+s +\] +or +\[ + pij \textrm{ with } i \leq c+s < i+j \leq + \mbox{\meta{number-of-columns}} +\] +The first formula describes the areas which partly overlap from the +left, the second formula describes those that partly overlap from +the right. Areas which are sub- or super-areas, e.g., \texttt{t13} +and \texttt{t22} do not affect each other. The above restriction is +necessary to prevent situations like the one shown in +figure~\vref{fig:overlap} +% +\begin{figure} +\footnotesize +\caption{Overlapping float areas}\label{fig:overlap} +\begin{minipage}{.6\columnwidth} +\begin{verbatim} + aaaaaaaaaaa 444 + aaaaaaaaaaa 444 + aaaaaaaaaaa 444 + 111 222 + 111 222 bbbbbbb + 111 222 bbbbbbb + 111 222 bbbbbbb + 111 222 + 111 222 333 444 + 111 222 333 444 + 111 222 333 444 +\end{verbatim} +\end{minipage} +\end{figure} +% +i.e., where the float area \texttt{t32} (represented as b's) would +result in splitting the fourth column into two independent text areas. + +The possibilities, as well as the restrictions, are equal for both top +and bottom areas. This means that the new scheme in particular +supports spanning bottom areas. + +\ORspecial\ShowGridfalse + +\subsection{Float pages and columns} + +Float pages, i.e., pages consisting only of floats, will be supported +as well as float columns. + + +\subsection{Float types} + +The type of float influences the formatting, e.g., where the caption +is placed in relation to the float body, how it is formatted, what +kind of fixed strings are added, etc. It also restricts the placement +algorithm in respect to which float areas can be populated as +explained below. + + +\subsection{Margins} + +The marginal areas can receive marginal notes which are aligned with +the corresponding text line. In documents with more than two columns +marginal notes are currently not supported though one could envision +allowing them even there. If marginals have to compete for space the +later marginal will be moved downwards if there is enough space on the +page, otherwise the line containing the marginal will be moved to the +next column/\allowbreak page.\footnote{This is not yet implemented --- +right now they overprint each other.} + +An alternative usage of the margin is to place footnotes into it. A +prototype version of this is provided already, see +section~\vref{footnotes}. + +Another potential use of the margin areas is to use them (or parts +thereof) as float areas in their own right. The problem with this +would be that these float areas would have a horizontal width which is +different from the column width, thus allowing only a limited class of +floats to appear therein. + +Another potential extension would be to allow float areas that border +on a margin to use the marginal space as part of the float area, +thereby allowing the filling of such an area with floats which are +wider than the nominal float area. A special case of this, the +placement of the caption in the margin beside the float body, is +already provided by choosing a suitable caption formatting instance. + + + + +\subsection{Footnotes}\label{footnotes} + +Footnotes can be regarded as a special type of floats. They are objects +which are associated with lines of text (their call-out) but in +contrast to normal floats such as ``figures'' or ``tables'' their placement +constraints are stronger, e.g., they typically have to appear at the +bottom of the column which contains their call-outs, or at least they +have to appear on the same page as their call-outs. + +In its current version, the model supports footnotes beneath the +call-out column (normal behavior); all footnotes in the last column +(as with the \texttt{ftnright} package for two-column mode); all +footnotes in the outer (or inner) margin. + +Without an extension to the page makeup algorithm (but instead with a +suitable redefinition of the footnote commands) they could be processed +as marginal notes or alternatively as ``end-notes''. + + +\subsection{Headers and footers} + +The header and footer areas may use data received from individual +columns. An extended version of \TeX's mark mechanism is made +available which allows the definition of arbitrarily many independent +classes of marks. Within each mark class information about the top +mark (i.e., the mark active at the top of the column) the first mark +and the last mark is made available for retrieval. + +This allows the production of correct running headers and footers for +various types of applications such as dictionaries, manuals, etc. + + + + +\section{The processing model} + +\subsection{Float placement concepts}\label{sec:float-place} + +To build a page(-spread) the algorithm first assembles enough textual +material to be able to fill the page without placing any floats. +During this process all floats that have their call-outs within the +assembled galley are collected. They form, together with unplaced +floats from previous pages, an ordered trial list of floats. + +The allowed float areas on the page under construction are totally +ordered as well. + +The algorithm proceeds by taking the first float from the trial list +and trying to place it into the first float area from the area +list. It then checks if all constraints (see below) are met and if not +the algorithm +will try to place the float into the next area until either all +constraints are met or the areas in the float area list are exhausted. +A trial that does not fail means that +this distribution of floats becomes the best solution so far and all +further trials will be based on adding to this solution (no +backtracking). If the algorithm fails to place the float into any +area it means that the float will be deferred to a later page. + +As floats are added to areas, the constraints for further trials +are changed. There are several reasons for this: +on one hand, the call-out positions of +various floats move +since the float will occupy space on the page; on the other hand, +placing a float in some area might result in disallowing the placement +of other floats in the same or in other areas. + + +\subsection{Float pages and columns} + +At the moment there is only rudimentary support for float pages +available: at the start of each page the algorithm will try to form a +float page out of all floats that have been deferred from previous +pages. However there is no layout control available to define the +conditions under which such a trial will succeed. + + +\subsection{Float storage} + +Float bodies are typeset into boxes at the point of `call-out', as +with the \texttt{figure} and \texttt{table} environments in the standard +\LaTeX; it may also be possible to specify at the call-out point a +logical pointer to a float whose typesetting is specified elsewhere +(e.g., an external file). + +However, text sub-elements such as the caption, etc., (e.g., from +|\caption|) are not typeset at this stage but are stored as token +lists; this allows for trying different possible layout specifications, +e.g., for its measure, during the float-positioning trials. At present +this is confined to at most a single caption element per float. + +\subsection{Caption processing} + +When a float is placed into an area the caption is trial formatted and +mounted onto the float body. This process can take into account +various information about the float positioning trial, such as the +area to format it into, the fact that it formats onto a verso or recto +page, etc. It might try several possibilities before making a decision, +e.g., if one formatting of the float results in violating some +constraint(s) it might try a different formatting at this point. + + + +\subsection{Flushing floats} + +It is possible to mark points in the source document as boundaries beyond +which floats whose call-outs are prior to the boundary cannot pass. In +other words a ``flush point'' directs the algorithm to place all +affected floats into areas which are ``before'' the flush point. + +If due to other constraints the float could not be placed in such an +area the algorithm first retries all potential areas using a less +rigid set of constraints (for example, restrictions on the number of +allowed floats per area are dropped) and if this still doesn't enable +the algorithm to place the float properly it will as a last resort +move the flush point to a later column, which means breaking the +column text before the flush point. + +Flushing of floats can be done either for all floats or on a +per float type basis, e.g., it is possible to flush only floats of +type ``figure''. + +A flush point can be given an additional attribute which controls the +``fuzziness'' used by the algorithm. By default the flush point +algorithm uses |strict| flushing as described above. The attribute +|column| modifies the algorithms behaviour by enabling a float to move +past the flush point as long as it will be placed on the same +column. Similarily the attribute values |page| and |spread| will +enforce that the float will not be deferred further than the current +page or the current spread. This way it can be guaranteed that a float +is always visible from its call-out. + + +\subsection{Float sequence classes} + +Float sequence classes are collections of float types; each float type +belongs to exactly one float sequence class. Within each sequence +class the call-out order in the document is always preserved by the +float placement algorithm, e.g., if $c_1,c_2,\ldots,c_n$ are the +call-outs of all floats of a float sequence class then the +corrsponding floats will be placed such that $f_i$ will be placed +before $f_j$ whenever $i<j$. Thus by putting all float types into a +single float sequence class all floats are placed in the order of +their call-outs. As the other extreme, if each float type has its own +sequence class\footnote{This is the \LaTeXe{} default.} then floats +from one type might move before floats of other types even though the +corresponding call-outs are in a different order. + + + +\subsection{Float and call-out relations} \label{fl-callout-relations} + +The algorithm also keeps track of the relation between an individual +float and its call-out. This allows one to define constraints which +guide the algorithm during the float placement phase. It is always +permissible to place a float ``after'' its call-out, e.g., in a later +column/\allowbreak page. At the moment the following constraints can +be specified: +\begin{description} +\item[none] which means that the relation between call-out and float +placement is not relevant for placing floats. +\item[page] which means that the float can be placed anywhere on the +page with the call-out (it is visible from the call-out). +\item[column] which means that the float can be placed before the +call-out as long as it is placed in the same column. +\item[after] which means that the float has to be placed strictly +after the call-out. +\end{description} +When extending the algorithm to directly support spreads the +above list is going to be extended by an option that allows floats to +move backwards on the whole spread. + + + + +\subsection{Spanning float and call-out relations} \label{fl-span-relation} + +For floats that span two or more columns there are several +possibilities to interpret the spatial relationship between call-out +and float areas. For example, if a float, whose call-out is in the +second column, has been placed into area |b12|, is this float +``before'' or ``after'' its call-out? The answer to this question +depends on whether we consider the float being placed into the first +or the second column, both of which are valid interpretations. + +At the moment the following behaviour can be specified: +\begin{description} +\item[strict] which means that the leftmost column spanned + by the float is being regarded as the column in which the float was placed. +\item[flexible] which means that the rightmost column spanned + by the float is being regarded as the column in which the float was placed. +\end{description} +These settings are only relevant if the main float/call-out relations +are set to |column| or |after|. + + +\subsection{Float and footnote relations} + +It is possible to direct the algorithm to check on each column if +there are footnotes, and if so to prevent it from placing floats in +the bottom +area. In theory it might be possible that a forbidden constellation +might resolve itself once the algorithm has added further floats, +e.g., it could be the case that by adding additional floats the +offending footnote gets moved to a different column. However, checking +for this would mean potentially large backtracking so the algorithm +uses a conservative approach and simply considers a trial as failed if +footnotes and bottom areas collide. + +It is planned to allow a designer the choice of specifying where the +footnotes should be placed in relation to any bottom floats (if the +combination is allowed). Right now this is not implemented and +column footnotes will always appear below the text column, i.e., above +any bottom floats. + + + + +\subsection{Area statuses} + +For each area the algorithm keeps track about whether or not it is +closed for individual float types, e.g., is not accepting any more +floats of type ``figure'' or closed for all types. The status of an +area can change due to floats being placed into other areas (this +might, for example, close earlier areas, or areas that overlap) or it +can change due to the fact that the area became too full in some way +(e.g., a size constraint or a number of floats constraint). + +Some of these constraints can be ``relaxed'' in certain situations, +e.g., if the algorithm is directed to flush out remaining floats prior +to a certain point in the galley it will drop constraints related to +number of floats per area or size restrictions. However, if an area +was closed due to a different float being placed into some other area, +this area will stay closed in all circumstances to ensure proper +sequential placement of floats and to ensure that overlapping areas +that are forbidden as explained in section~\vref{overlap} will not +receive floats at the same time. + + + + +\subsection{Area constraints} + +The algorithm offers several possibilities for the designer to +specify how and under what circumstances a float is allowed to be +added to a certain area on the page. + +As explained above all areas on a page are tried in a specific +order. This order can be specified and changed for specific parts of +the document. Areas that are closed for the current type will be +bypassed as well as areas which do not span the right number of +columns to fit the horizontal size of the float. If these initial +tests succeed the float may still fail to be placed into a certain +area if it doesn't fulfill the following set of constraints: +\begin{itemize} +\item There is an upper limit on the total number of floats that can +be placed on an individual page. +\item Each area has an upper limit of floats that can go into it. +\item After placing the float the remaining space in the text column +must be larger than a specified value. +\end{itemize} +All such constraints are customizable. + +Additional constraints will probably be implemented +once there has been some experience of what controls are actually +needed to allow the specification for a reasonable number of layouts. + +For example, \LaTeXe{} allows the designer to restrict the maximum size of +an area, but should one provide this or should there be a constraint +on the size of all stacked areas? Or should there be both? + + + +\subsection{To ``Here'' or not to ``Here''} + +\LaTeXe{} allows the user to control the placement of an individual float by +specifying one or more areas into which the float would be +allowed to move using single letters. As a special notation an +\texttt{h} would denote a so-called ``here'' float. Its advertised +semantics is to try placing the float ``at the position in the text +where the environment appears'' \cite[p.~197]{A-W:LLa94}. +If this is not feasible \LaTeXe{} would try the remaining +allowed possibilities on the next page, thus a float with a +\texttt{ht} specification would either appear within the text or +at the top of the next or a later +page.\footnote{\clubpenalty=100 In two-column mode +this can in fact result in a placement on the top of the second column +even though the call-out position finally falls into the middle of +that column.} + +In many cases people however prefer a ``here'' which always means +``here''. The latter form is implemented in some add-on packages for +\LaTeXe{}, however usually at the cost of allowing floats to appear out +of order. + +The new model supports only the absolute ``here'' form for floats; +however, correct ordering of floats in the output is guaranteed (if +the tag generating the here float issues flushing of floats for the +current type). If +there is not enough space to place the float in a column, the float +plus the preceding text line\footnote{More precisely the column is +broken at the last breakpoint preceding the current position which is +normally one line above but could be more (or less).} is moved to the +next column/\allowbreak page. + + +\subsection{Grid layout} + +To produce layouts with elements placed on an underlying grid +(typically with grid points vertically separated by |\baselineskip|) +the algorithm assumes that certain parts of the text column, e.g., +normal text will automatically align on the grid as long as the first +line is positioned on the grid. A further assumption is that such +parts of the column do not contain stretchable amounts of vertical +glue so that they are not subject to stretching or shrinking if the +material is adjusted to fit a given size. + +Given these assumptions, the algorithm proceeds by ensuring that the +space taking up by floats (including their separating white spaces) is +always of a size such that the remaining space for the text part of the +columns is allowing for an integral number of grid lines. This is +achieved by stretching or shrinking the space separating the areas +from the text appropriately while building the page as explained in +section\vref{sec:float-place}. + +Within the text column there are typically a number of ``display +objects'' such as headings, equations, quotations, lists, etc\@. which +should not be aligned on the grid. Instead, typically the text before +and after is supposed to lie on the grid\footnote{In some cases, +depending on the design, parts of the structure might be supposed to +aligned as well.} This is supported by allowing to mark lines of text +(or more generally points in the galley) to ``snap to the nearest grid +point''. One can think of the implementation working by taking the +column material up to the marked line and putting it into a vertical +box of the size of the nearest possible grid point. By this approach +stretchable glue around such a display object will allow the text line +that should snap to the grid move into the correct position. This box +is then given back to the page builder to assemble more material for +the column. Since this way the preceding part of the column becomes +rigid; thus a later request for snapping to the grid will only stretch +or shrink material further down the column. + +A prototype implementation that makes most standard \LaTeX{} objects, +like headings, displays, etc.\ support grid design is available with +the package \texttt{xo-grid}. It is used for typesetting this +document. + + +\section{User control} + + +\subsection{Column and page breaks} + +Breaking of columns and pages can be controlled from the source +document by placing special tags into it. The |\columnbreak| command +ends the current column after the current line (if used in horizontal +mode). Similarly the |\pagebreak| command ends the current +page.\footnote{At the moment these commands force a break; there is no +possibility, as in \LaTeXe{} to suggest only that the current point +is a good or bad break.} + + +\subsection{Manual float flushing} + +The flush float functionality is available within the source document +via the command |\flushfloats|. This command takes two optional arguments +which, if present, denote the float type to flush (by default all) and the +``fuzziness'' of the flush (by default |strict|). Other allowed values +for the fuzziness are |column|, |page|, or |spread|. If a type is +specified for flushing, effectively all types with the same float +sequence class are flushed to preserve the ordering. + + + +\subsection{Specifying preferred areas} + +At the time of writing the document source interface for specifying +the group of areas into which a float is allowed to move is not yet +decided. One could envision keeping the original \LaTeX{} interface to +float environments with optional argument. In that case something like +|[t]| could be internally interpreted as ``any top area that exists'' +and translated into a list such as |t12 t11 t21|. But other interfaces +are conceivable as well. + + + +\subsection{Manually position all floats} + +Any algorithm that automatically places all floats may fail to produce +adequate results in some situations. In \LaTeXe{} the user was offered +only the optional arguments of the float environments and by this +method and by moving floats slightly in the source document one was +finally able to change the formatting as needed. + +This was a time consuming and error prone manual task and any slight +change in the source document text was likely to result in making this +work obsolete. + +To improve on this situation the new algorithm can be directed to +write out a file containing all of its float\footnote{Floats in this +contect mean ``traditional'' floats, not footnotes or marginpars.} +selections (an example is +shown in table~\vref{fig:fpl}). +% +\begin{table} +\begin{minipage}{\columnwidth-24pt} +\footnotesize +\begin{verbatim} +Page: 1 (1) + Area: t13 + Float: 4 (figure 4) [] + Area: b21 + Float: 2 (figure 2) [mylab:fig1] + Area: t31 + Float: 3 (figure 3) [mylab:fig2] + + Area: hhh + Float: 11 (table 1) [] + +Page: 2 (2) + Area: t13 + Float: 8 (figure 8) [] + Area: t22 + Float: 5 (figure 5) [] + Area: b11 + Float: 6 (figure 6) [mylab:fig3] + Area: b31 + Float: 7 (figure 7) [mylab:fig4] +\end{verbatim} +\end{minipage} +\caption{An example \texttt{fpl} file}\label{fig:fpl} +\end{table} +% +By simple drag and drop the user can produce alterations to this +selection. If such a modified file is stored as |\jobname.fpc| then +the algorithm will use these selections without attempting to apply +any of its internal rules. Thus the formatting will happen exactly as +specified.\footnote{If the floats are stored within the source +document at the point of their call-outs, the algorithm will be able +to position a float only if it has already encountered the float in the +source document. This means that one can move a float arbitrarily +forward but only to a limited extent before its call-out position. If +the floats are stored externally to the source document this +restriction does not apply.} + +Beside moving floats between float areas it will be possible to move +floats in and out of the special area called |hhh| which represents a +list of all ``here'' floats on the page. If a float is moved into the +``here'' area it means that it will be positioned as a here float at +the point of its call-out. + + +As an extension to this method we are experimenting with restricting +the manual control only to parts of the document, e.g., allowing the +user to manually fix a single chapter but have the algorithm determine +the remainder. We also plan to integrate column length control in this +way, so that it becomes easily possible to run a page or double-spread +long or short by specifying this externally rather than via tags in +the source document. + + + +\subsection[Tracing the algorithm's behavior] + {Tracing the algorithm's\\ behavior} + +In contrast to the \LaTeXe{} output routine, which is a black box as far +as the user is concerned, the new algorithm tries hard to make its +decision process comprehensible. Table~\vref{tab:progress} shows +\ifnum\ProcessControl=0 + \begin{table*} + \caption{Progress output of the algorithm}\label{tab:progress} +\else +% +% FMi: people reading the source will notice that there isn't yet any +% interface for spanning floats ... so we have to do this by hand +% + \def\SPANCNT{2}% + \begin{table}[t12,b12] + \caption{Progress output of the algorithm}\label{tab:progress} + \begin{minipage}{1.3\columnwidth} +\fi +% +\footnotesize +\begin{verbatim} +======================================================================= + STATS: floats waiting = 2 on page 13 +======================================================================= +Float: \bx@E {5} {table} (floats) {5} {Statistics from the algorithm} + area trial: b12 -> failed: span count b12 /= 1 + area trial: b11 -> accepted +Float: \bx@F {6} {table} (floats) {6} {Running times of the algorithm} + area trial: b12 -> failed: span count b12 /= 1 + area trial: b11 -> failed: b11 float num reached (1) + area trial: b21 -> failed: area below flush point (2=2, b21) + -> failed: --> retry with relaxed conditions + + area trial: b12 -> failed: span count b12 /= 1 + area trial: b11 -> accepted + STATS: trials = 7 +\end{verbatim} +\ifnum\ProcessControl=0 + \end{table*} +\else + \end{minipage} + \end{table}\def\SPANCNT{}% +\fi +% +a sample output produced by it. It shows for each float which areas +have been tried, why they were rejected etc. There is also an option +which produces about 1000 times as much information but the latter is +probably useful only for debugging the system in case there are errors +in the code. + + + +\subsection{Manually aligning text in grid layout} + +If the algorithm produces grid layout it automatically aligns certain +text lines on the underlying grid. For manual control this +functionality is also provided with the command |\TextAlignGrid| which +will align the current text line on the grid. By issuing a +|\IgnoreAlignToGrid| command grid alignment will be temporarily +disabled, while |\ObeyAlignToGrid| will reestablish automatic grid +processing. + + +\section{Layout Specification} + +In the class file the designer is given control over the algorithm's +behavior in all the aspects described above (and several more). + +The layout specifications are done through the new template and +instance concept, see~\cite{tub:MCR99-3}. +Additional information such as experimental code, further +documentation, etc.\ can +be found on the \LaTeX{} project web site at: +\begin{quote} +\url{http://www.latex-project.org} +\end{quote} + +In contrast to the algorithm itself, which in its basic functionality +now seems to be stable and reliable, the design interface is far +more experimental. Thus the example declarations given below represent +only the current state of thought (or of implementation) +and are likely to be modified at any moment. + + +\subsection{Float type declarations} + +Float types are declared using the command |\DeclareFloatType| which +takes two arguments: the name of the type which is declared and in the +second argument a list of key value pair which describe the +properties of the float type, e.g., +\begin{verbatim} + \DeclareFloatType{figure} + { + sequence-class-id = floats, + toc-extension = lof, + caption-text = \figurename, + numbered-boolean = true, + numbered-id = figure, + numbered-within-id = section, + numbered-action = + \thesection.\arabic{figure}, + body-decls = , + } +\end{verbatim} +The \texttt{sequence-class-id} key defines to which float sequence +class the type belongs to. If it is absent a sequence class with the +same name as the type is assumed. The sequence class will be +automatically initialized if not referenced before. + +The \texttt{toc-extension} key defines the extension to be used to +write the caption to when generating ``List of floats'' listings. By +using the same extension with different types it is possible to +generate combined listings, such as ``List of table and figures''. + +The \texttt{caption-text} key defines the fixed text to be used as +part of the caption text together with the float number if present, +e.g., |Figure|. This information is passed to the caption formatting +template so the actual formatting is defined there. + +The \texttt{numbered-boolean} defines whether or not floats of this +type are numbered. + +The \texttt{numbered-id} key defines the name of the counter to use +when numbering floats. If absent a counter with the same name as the +type is assumed. By using the same counter with different types it is +possible to use a single numbering scheme---in that case the +\texttt{sequence-class-id} for these types should probably be +identical as well to avoid strange numbering sequences within the +document. + +The \texttt{numbered-within-id} key defines the name of the ``within'' +counter, i.e., the counter which if stepped resets the numbering. If +the value is empty or not set the float type is numbered in a single +sequence throughout the document. + +The \texttt{numbered-action} key defines the representation of the +float number, as used in the caption and by the |\ref|, |\label| +mechanism. The default is |\arabic{|\meta{counter}|}|. + +The \texttt{body-decls} key can hold formating instructions that +should apply to the float body. They can assume a normalized +formatting environment already set up by the algorithm. + +The declaration of a new float type automatically defines the +necessary user document environments. + + +\subsection{Float area declarations} + +Any float area that is going to be used at some stage by the algorithm +needs to be declared beforehand. This is done through the +|\DeclareFloatArea| command which takes two arguments: the name of the +area (which has to follow the conventions explained in +section~\vref{overlap}) and a list of key/value pairs describing the +characteristics of the area. +\begin{verbatim} + \DeclareFloatArea{t22} + { + class-close-list = {t11,b11}, + all-close-list = {t12,t32}, + max-float-num = 2, + } +\end{verbatim} + As of today an area is characterized through the maximum number of +floats it is allowed to receive (\texttt{max-float-num}) and through +two lists which tell the algorithm which other areas are affected by +adding a float to the current area. The list \texttt{class-close-list} +enumerates all areas which are not allowed to receive additional +floats of the same sequence class as the float that has been placed +into the current area, while +the list \texttt{all-close-list} contains the information about all +areas that are to be completely closed the moment a float is received +in the current area. + +The \texttt{class-close-list} key is primarily intended to specify a +partial order on the areas to ensure that floats are not getting out +of sequence in the output. For example, the above declaration says: if +a float is placed into area |t22|, i.e., a top area starting at column +two and spanning two columns, then the single column areas |t11| and +|b11| (i.e., those of the first column) are closed for floats of the +same class. However, assuming this example is part of a declaration for +a four column layout which could have areas like |t14| or |t13|, there +is nothing said about closing those areas. Thus in this particular +layout a float spanning three or four columns would still be allowed +to go on top. + +On the other hand the \texttt{all-close-list} key is available to +ensure more visual constraints, e.g, ``if |t12| gets filled we don't +want to have |b12| filled as well, we only want |b22| in this +case''. In addition it is needed to implement the restriction about +overlapping float areas as described in section~\vref{overlap}, e.g., +in the example declaration |t12| and |t32| are closed since they +partly overlap with |t22|.\footnote{As mentioned before, this +restriction might be lifted in a later version of the algorithm; as +long as it is required one could alternatively add those areas behind +the scenes to avoid runtime problems.} + + + + + +\subsection{Footnote formatting declarations} + +The formatting of footnotes is specified by declaring instance(s) of +type |footnotesetup|. At the moment three templates are available +though they should be considered only as prototypes: the template +|std| produces conventional footnotes below each column, the template +|ftnright| collects all footnotes and typesets them in the rightmost +column, and the |margin| template collects and typesets them in the +right outer margin. + +The keys of the above templates are providing only a rudimentary +flexibility (to say it positively), in a production version all of +them would need a large number of extensions. +As an example +\begin{verbatim} + \DeclareInstance{footnotesetup} + {mainmatter}{std} + { + text-sep = 14pt plus 3pt, + max-height = 8in, + } +\end{verbatim} +would declare the named instance |mainmatter| that provides footnotes +below columns with a separation of |14pt+| and a maximum height for +footnotes per column being |8in|. + +Instances like this can then be used in the declaration for a +particular page layout as explained below. Alternatively one could use +unnamed instances there using the |\UseTemplate| method. + + +\subsection{Page setup declarations} + +At the heart of the layout declaration are instances of the type +|pagesetup2.|\footnote{The number 2 has historical reasons and will +vanish again at some point in the future.} +An example setup showing all currently available keys is given in +% +\ifnum\ProcessControl=0 + \begin{table*} + \caption{Example declaration for the \texttt{pagesetup2} template + showing all currently available keys}\label{tab:pagesetup2} +\else + \def\SPANCNT{2}% + \begin{table}[t12,b12] + \caption{Example declaration for the \texttt{pagesetup2} template + showing all currently available keys}\label{tab:pagesetup2} + \begin{minipage}{1.3\columnwidth} +\fi +% +\footnotesize +\begin{verbatim} + \DeclareInstance{pagesetup2}{mainmatter}{std} + { +% column specification + column-num = 2, + column-width = 220pt, + column-height = 610pt, + column-sep = 20pt, +% float constraint specification + max-float-num = 3, + float-callout-constraint = after, + float-callout-span-constraint = strict, + bottom-float-footnote-constraint = forbidden, + flush-float-callout-constraint = page, + flush-float-callout-span-constraint = flexible, + flush-bottom-float-footnote-constraint = none, +% area specification + area-list = {t12,t11,b11,b12,t21,b21}, + defer-class-close-list = {t12,t11,b11,b12,t21,b21}, + defer-all-close-list = , + float-float-sep = 15pt, + float-text-sep = 30pt minus 8pt, + float-area-sep = 15pt, + float-inline-sep = 6pt minus 2pt, +% grid specification + grid-point-sep = 12pt, +% footnote etc specification + footnote-setup = mainmatter, + } +\end{verbatim} +\ifnum\ProcessControl=0 + \end{table*} +\else + \end{minipage} + \end{table}\def\SPANCNT{}% +\fi +% +table~\vref{tab:pagesetup2}. + + +\subsubsection{Column specification} + +The first four keys (|column-num|, |column-width|, |column-height|, +and |column-sep|) describe the column structure of the page layout +being defined, i.e., in this case a two-column layout. + +\subsubsection{Float constraint specification} + +The following four keys define the standard constraints for the +algorithm when placing floats: \texttt{max-\allowbreak +float-\allowbreak num} is the maximum number of floats that can go on +a normal page, +\texttt{float-\allowbreak callout-\allowbreak constraint} defines +what kind of relations between float and call-out are allowed, +possible values are explained on~\vpageref{fl-callout-relations}. + +\texttt{float-\allowbreak callout-\allowbreak span-\allowbreak +constraint} handles the interpretation of spanning floats and is +explained on~\vpageref{fl-span-relation}, and +\texttt{bottom-\allowbreak float-\allowbreak footnote-\allowbreak +constraint} defines whether or not bottom floats are allowed in case +of footnotes. + +The last three constraints are replaced by +\texttt{flush-\allowbreak float-\allowbreak callout-\allowbreak +constraint}, \texttt{flush-\allowbreak float-\allowbreak + callout-\allowbreak span-\allowbreak constraint}, and +\texttt{flush-\allowbreak bottom-\allowbreak float-\allowbreak +footnote-\allowbreak constraint} in case flushing can't be done +without relaxing the conditions (\texttt{max-\allowbreak +float-\allowbreak num} is disregarded in that case automatically). + +\subsubsection{Float area specification} + +The key |area-list| defines all float areas that are allowed in this +page layout as well as defining the order in which the areas are tried +when placing floats. +The keys \texttt{defer-class-close-list} and +\texttt{defer-all-close-list} define the ``closing actions'' for the +special area which receives the floats that could not be placed. E.g., +if a float of a certain class can't be placed then all areas listed in +\texttt{defer-class-close-list} will be closed for this class of +floats. In other +words the two keys are comparable to the ones available for area +declarations. + +Thus these keys together with the keys from the area +declarations are most important to guarantee a sensible order of +floats on the formatted page. + +In an earlier implementation of the algorithm a simpler scheme was +used: there was a single area list which was shortened whenever a +float couldn't be placed into it thereby confining the remaining +floats to this restricted selection. This works fine as long as there +are mainly single column floats since in this case the area can be +reasonably ordered into a single sequence. However the moment spanning +floats are supported the situation gets less straightforward. Is it +allowed to place a later float into |t12| if there is already a float +in the area |t11|? +%% bb -- that's easy! a wider float always takes precedence over a +%% narrower one in the same column span, so t21 wins. +%% FMi -- so if there is a t11 float t21 is always closed and a later +%% spanning float will always be deferred -> i doubt that all +%% designers/editors would like to see this as a forced rule +%% :-) + +It is quite likely that the current controls will turn out to be too +crude. This will be seen once a suitable number of layouts have been +produced under this scheme (or couldn't be produced because they +turned out to be unspecifiable). + +There needs to be space between floats in an area and areas need to be +separated from each other, as well as from the column text. For this we +have the following keys: +\texttt{float-float-sep} is the separation between two floats in an area, +\texttt{float-area-sep} is the separation between two vertically +adjacent areas, and \texttt{float-text-sep} finally is the separation +between a float area and the column text.\footnote{A possible +extension would be to allow ornamental material in place of white space.} +The separation between inline floats and surrounding text is given by +\texttt{float-inline-sep}. + +\subsubsection{Grid specification} + +To produce a grid based design the \texttt{grid-point-sep} needs to be +given a positive dimension. This defines the distance between grid +points on which the algorithm aligns column text, inline floats, +etc.\footnote{Setting this parameter is not sufficient: to make grid +setting possible several other parameters need to be set to suitable +values as well, e.g., the distance between baselines should be +compatible and the column height need to be a multiple of this value.} + +To align column text at a grid point the algorithm will extend the +\texttt{float-text-sep} space. Alternatively, if the nearest grid +point can be reached by shrinking that space (assuming its +specification contains a |minus| component) the algorithm will use +that grid point instead. In a similar fashion the space around an +inline float will be determined by the value of +\texttt{float-inline-sep}. + + + +\subsubsection{Footnote, etc.~specification} + +Finally the key \texttt{footnote-setup} receives an instance of a +\texttt{footnotesetup} template, therby defining how footnotes are +handled and presented. + +What is clearly missing here is handling of other page elements such +as running headers and footers, the folio, etc. This will be added +soon. + + +\subsection{Float formatting declarations} + +For the attachment of captions to floats there exists a prototype +interface using templates of the type |buildfloat|. At the time of +writing, available templates are |centeredbelow|, |centeredabove|, and +|bottomright|, which center the caption below or above the float body +or place it to the right of it, aligned with the bottom of the float +body. All of them would need to be generalized for a production +system to become more flexible. + +When trial-formatting a float the algorithm checks for the existence +of a number of |buildfloat| instances and uses the first one that +exists to build the float. More precisely it first checks if an +instance with the name \meta{area}|-|\meta{type} exists, then it looks +for \meta{area}, then for \meta{type}, and finally, if none of them +exists, for an instance with the name |default|. So at least the latter +instance has to be declared by the class. +\begin{verbatim} + \DeclareInstance{buildfloat}{default} + {centeredbelow}{} + \DeclareInstance{buildfloat}{table} + {centeredabove}{} + \DeclareInstance{buildfloat}{t31} + {bottomright}{} + \DeclareInstance{buildfloat}{t22} + {bottomright}{} +\end{verbatim} +The example declaration above defines the placement of captions above +tables and below for all other types, with the exception of the areas |t31| +and |t22| where the captions are set to the side. + + +\section[Performance of the algorithm] + {Performance of the\\algorithm} + +To test the performance of the algorithm we prepared a somewhat +ridiculous test file containing three types of floats (``figures'', +``tables'', and ``algorithms'') with a total number of 47 floats. +The chosen +layout had 3 columns and 11 potential float areas. Figure captions +have been placed below the float while with tables and algorithms the +caption was placed on top. The exception was the top areas adjacent to +the outer margin: floats placed there got their captions placed to +the right and partly into the margin. Footnotes were collected for all +columns and placed in the outer margin. + +Floats had to strictly follow their call-out and a maximum of +ten floats was allowed per page, i.e., roughly three per column. + +Since the document contained many floats early on (24 on page one) and +the first of these was especially constructed to be not placeable the +first time around, the algorithm had to work hard to place all the +dangling floats. Table~\vref{tab:stats} +% +\begin{table} +\footnotesize +\begin{minipage}{\columnwidth} +\begin{verbatim} + STATS: floats waiting = 24 on page 1 + STATS: trials = 286 + STATS: floats waiting = 19 on page 2 (float page) + STATS: trials = 159 + STATS: floats waiting = 37 on page 2 + STATS: trials = 397 + STATS: floats waiting = 19 on page 3 (float page) + STATS: trials = 166 + STATS: floats waiting = 7 on page 4 (float page) + STATS: trials = 41 + STATS: floats waiting = 20 on page 4 + STATS: trials = 204 + STATS: floats waiting = 5 on page 5 (float page) + STATS: trials = 27 + STATS: floats waiting = 12 on page 5 + STATS: trials = 108 + STATS: floats waiting = 0 on page 6 (float page) + STATS: trials = 0 + STATS: floats waiting = 6 on page 6 + STATS: trials = 57 + ... + STATS: floats waiting = 6 on page 12 (float page) + STATS: trials = 26 + STATS: floats waiting = 6 on page 12 + STATS: trials = 37 + STATS: floats waiting = 0 on page 13 + STATS: trials = 0 +\end{verbatim} +\end{minipage} +\caption{Statistics from the algorithm}\label{tab:stats} +\end{table} +% +shows some statistics as produced by the algorithm on the number of +trials necessary (the highest number was $397$ for $37$ floats; by +comparison, equation~(\ref{eq:binom})~\vpageref{eq:binom} would give +$22595200368$ which would probably take a bit longer to +evaluate). Note that on the third page the algorithm was able to +produce a float page, on all other pages the float page trial was +unsuccessful. + +Table~\vref{tab:runs} shows the running times +% +\begin{table} +\footnotesize +\begin{tabular}{rrr} + & \llap{P\textsc{iii}} (650MHz) & 486DX4 (75MHz)\\[6pt] +&\multicolumn2{c}{no tracing} \\[4pt] +real & 0m1.533s & 0m27.633s \\ +user & 0m1.460s & 0m26.940s \\ +sys & 0m0.050s & 0m0.690s \\[6pt] +&\multicolumn2{c}{progress information} \\[4pt] +real & 0m3.116s & 0m36.885s \\ +user & 0m1.740s & 0m34.470s \\ +sys & 0m0.080s & 0m2.420s \\[6pt] +&\multicolumn2{c}{full tracing} \\[4pt] +real & 0m7.833s & 1m22.480s \\ +user & 0m2.720s & 1m7.890s \\ +sys & 0m0.280s & 0m12.360s \\ +\end{tabular} +\caption{Running times of the algorithm}\label{tab:runs} +\end{table} +% +needed to produce the final document of 13 pages when the algorithm is +used with different tracing settings. The test machines were a Pentium +\textsc{iii} +650 machine and an older laptop with a 486 processor. In both cases +\TeX{} was run straight from a \TeX{} Live~4 CD. + +These times show that the algorithm has an acceptable time performance +since even on a 486 the average time to produce a page is roughly 2 +seconds. + + + +\section{Outlook} + +While the current algorithm performs well there are several areas in +which its functionality could and probably should be extended. The most +important points are given in the following list. +\begin{itemize} +\item + Balancing of partial pages, comparable to the way the + \texttt{multicol} package works, should be implemented to allow for + layouts where, for example, a heading should span across all + columns. +\item + We intend to provide more control over the marginal areas, allowing + for marginal floats as well as other objects in the margin, properly + interacting with each other. +\item + Without much effort the algorithm could be extended to properly + support double-spreads so this should be added some time soon. +\item + Once the algorithm has decided which floats to place onto a page one + could add a post-processing step in which the placement could be + reconsidered according to different rules. For example, if the + call-out relation is |page| then floats will tend to be placed in the + left-hand columns. This is fine as long as there are many floats to + process but on a page with only a few floats one might want to + redistribute them differently once it is clear which floats could go + onto the page. +\item + Since it is known beforehand how many floats are actively waiting to + be placed, one could use a different algorithm that tries all + possible combinations as long as there are only a limited number of + floats to be placed. The boundary at which the algorithm changes + behavior could be made customizable so that people with faster + machines (or more patience) could have the search for optimum running + for as many floats as they like. +\end{itemize} + + + + +\bibliographystyle{plain} +\bibliography{string,book,tub99} + +\vfill + +\end{document} + + +% $Log: xo-pfloat.tex,v $ +% Revision 1.19 2000/08/11 07:08:04 latex3 +% small updates +% +% Revision 1.18 2000/08/04 15:39:04 latex3 +% added documentation on grid layout +% +% Revision 1.17 2000/07/22 06:29:55 latex3 +% documentation float class sequence +% documentation float type options +% documentation new page setup options +% +% Revision 1.16 2000/07/02 19:33:15 latex3 +% as send off to TUG 2000 +% +% Revision 1.15 2000/06/29 17:13:56 latex3 +% corrections by David +% +% Revision 1.14 2000/06/22 20:41:58 latex3 +% made formatting possibilities interactive +% +% Revision 1.13 2000/06/16 10:10:30 latex3 +% added handling of spanning floats / call-out constraints +% +% Revision 1.12 2000/06/15 15:19:03 latex3 +% documented new syntax for area names +% +% Revision 1.11 2000/06/15 09:16:51 latex3 +% added documentation on fuzzy flushing +% +% Revision 1.10 2000/06/08 15:32:37 latex3 +% fixing typo in the math display +% +% Revision 1.9 2000/05/19 08:23:11 latex3 +% incorporated Barbara's and Phil's copy-editing suggestions +% +% Revision 1.8 2000/05/09 19:02:42 latex3 +% not integrated BB's edits yet +% +% Revision 1.7 2000/05/09 13:35:01 latex3 +% next version to BB +% +% Revision 1.6 2000/05/08 20:41:57 latex3 +% my additions before folding in Barbara's edits +% +% Revision 1.5 2000/05/08 15:33:25 latex3 +% as send to Barbara +% +% Revision 1.4 2000/05/08 11:22:37 latex3 +% *** empty log message *** +% +% Revision 1.3 2000/05/04 08:53:37 latex3 +% update title +% +% Revision 1.2 2000/05/04 08:51:12 latex3 +% first draft as send to David and Chris +% |