LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Tue, 18 Dec 2007 00:19:57 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset=us-ascii
From:
Frank Mittelbach <[log in to unmask]>
Parts/Attachments:
text/plain (204 lines)
Benjamin BAYART writes:
 > Le Fri, Dec 07, 2007 at 12:45:56PM +0100, Frank Mittelbach:
 > > 
 > > layout is called "ftnrightspread" and you can review the results in the pdf
 > 
 > I see one interesting case, about footnotes and multicolumn. The usual
 > layout is to have N cols, with the footnotes of each columns at the
 > bottom of it. It might be interesting to have a layout with different
 > numbers of cols for the text and the notes.
 > 
 > Something like a 2 columns text with a 3 columns footnote area, when there
 > is a quite large difference in text size between text and notes, it
 > avoid having too long lines in the notes.

I have now implemented a first "proof-of concept" version of multicolumn
footnotes.

the xo-pfloat.pdf file is now using "single-column" footnotes, ie pagewide
notes below double column text, which is just one variation in the whole
scheme, e.g., replacing

   footnote-setup = \UseTemplate{footnotesetup}{multicolumn}{column-num=1}, 

with

   footnote-setup = \UseTemplate{footnotesetup}{multicolumn}{column-num=3}, 

in xo-pfloat.tex would then give you 3 column notes, etc.

Turned out that the whole thing was more tricky than I first imagined, but it
is obvious once you think about it. In fact, I don't think that there is any
footnote package around that handles footnotes that are not tied to the column
width right now. The problem is, of course, that the size of the columns depend
on material from later columns (while ftnright was nicely waiting with
typesetting the footnotes so that only the last column was affected). Thus one
needs a multipass algorithm to handle that and that is not necessarily
converging to a single value easily.


Anyway, I think it works in principle and would offer a lot of playground for
extensions and customization possibilities (not to speak about something like
bigfoot which could and should run on top of it eventually (though not with
the existing codebase as that uses its own OR manipulations)

good night
frank

ps for those interested here is a sketch of the algorithm used right now
(comments/ideas certainly welcome ... dito if somebody wants to attempt going
after one or the other deficiency)

--------------------------------------------------

 Footnote placement algorithms

multicolumn footnotes

Running footnotes in multiple columns (and typically in different number of
columns compared to the number of columns in the main text area) turns out to
be far more complicated than I originally thought. Since footnotes are
collected while cutting the columns one doesn't know how much space will be
needed (if the footnotes aren't taking space just from the current column (or
in case of ftnright only from the last column). Thus one needs a multi-pass
algorithm (2 as a minimum - if one doesn't mind a certain "incorrectness")
running as a sub-process within the float placement trials. 

-- FrankMittelbach - 13 Dec 2007

Algorithm for multicolumn footnotes

This is a first draft of an algorithm and I'm not too happy with some of its
aspects. But at least it finally seems to work to some extent. 

Controls

\g_xor_trial_rerun_requested_bool 	Boolean used to signal that a rerun is required
\g_xor_footins_multicolumn_final_run_bool 	Boolean used to signal that we
                                                are finally trying to producing footnotes 
\g_xor_extrains_box 	Special insertion class used to control column size
\g_xor_saved_footins_box 	Box to store prepared page footnotes when generating the columns
\g_xor_saved_footins_dim 	Vertical size of page footnotes. That's the
                                only quantity kept between different reruns! 

Method

When starting a new page (or doing a new trial with an additional float) the following is assumed:

    * \g_xor_trial_rerun_requested_bool is false
    * \g_xor_footins_multicolumn_final_run_bool is false

\xor_initialize_page_footins_multicolumn:

The task of the \xor_initialize_page_footins_multicolumn: code is to set up
how footnote insertions will affect the vertical size of the columns being
built. 

In all cases we start out with clearing the boxes that may hold data from a
previous run, i.e., \g_xor_footins_box, \g_xor_saved_footins_box, and
\g_xor_extrains_box. 

Depending on the status of \g_xor_footins_multicolumn_final_run_bool different setups are used:

    * In the initial run (\g_xor_footins_multicolumn_final_run_bool false) we
      don't know how many footnotes we will see and how much space to reserve
      for them, so we attempt to approximate the space by letting each
      footnote take of space from column currently built.

          o The formula used is times 1000 divided by

          o A different formula would be needed if we run all the footnotes in
          a big paragraph rather than in multiple columns.

          o We also set \g_xor_footins_skip to the amount of space used
          between columns and the footnote block. This means that on each
          column where there is at least one footnote we account for this
          space. However, on columns without any footnote we will assemble too
          much material since in the final run those footnotes need to be
          shortend too. Note however, that we can't substract that amount
          automatically on all columns, unless we first do a run to determine
          if there are any footnotes at all on this page.


    * In the final run (\g_xor_footins_multicolumn_final_run_bool true) we
      assume that we know how much space is needed for footnote, thus we make
      the footnote insertions take up no space whatsoever and instead reduce
      the column heights by other means.


\xor_initialize_column_footins_multicolumn:

The task of \xor_initialize_column_footins_multicolumn: is to prepare the
collection of an individual column. 

We always clear out \g_xor_extrains_box if that received any material (needed?)

Then we do the following: if \g_xor_saved_footins_dim is greater than zero
(i.e., we have a target size for the page footnotes) we output an insertion
for \g_xor_extrains_box with some invisible material that makes this insert
the same height as \g_xor_saved_footins_dim. This has the following effect:


    * The next column (that we are about to built) will contain this insertion
      and thus the column height is reduced by \g_xor_saved_footins_dim plus
      the value of \g_xor_extrains_skip.


\xor_deal_with_footins_multicolumn:

The main work is done in \xor_deal_with_footins_multicolumn: which is called
when a column has been assmbled. Again we have to distingiush between a trial
run and the final run and in addition different actions are necessary
depending on whether or not we are in the last column of the page. 

In any case we move any accumulated footnotes from \g_xor_footins_box to
\g_xor_saved_footins_box. Thus \g_xor_saved_footins_box will contain the
foonotes from all columns when we have reached the last column and
\g_xor_footins_box will be void at the beginning of a new column thus a
footnote in that column will trigger \g_xor_footins_skip again. 

That's all we have to do until we deal with the final column. Here some more work is necessary:

    * First thing we do is to take the accumulated footnotes in
      \g_xor_saved_footins_box and reformat them as desired, putting the
      result back into that box and recording the vertical size of the result
      in \g_xor_saved_footins_dim.

    * If we are in trial mode (\g_xor_footins_multicolumn_final_run_bool
      false) we switch to final mode and request a rerun
      (\g_xor_trial_rerun_requested_bool true).

    * If we are in final mode we assume that the space calulated last time
      works out well and we use that. Of course, once could and should do some
      more elaborate checking here and if it turns out that we have too much
      or too little material now we could run another time (right now I only
      check for a need for more space to ensure that the footnotes will fit).


And that's about it. Right now the reformatting is a straight copy of the code
from the \TeX book appendix D, but eventually that would have to go and be
replaced with something more flexible. 

-- FrankMittelbach - 16 Dec 2007

Known or suspected bugs and limitations

    * The code for balancing the footnotes is not up to the job (not
      surprising really and no this has nothing to do with the fact that it is
      out of the TeXbook?). It should be replaced and clearly when there are
      only a few footnotes it should change its behavior and use a different
      approach. 

    * The way the space for footnotes is determined has its flaws. In case
      there is a footnote on the last line in the last column one might end up
      with a lot of space while the footnote is still pushed out to the next
      page. 

    * Page-wide footnotes and bottom floats aren't synced, so that they will
      overprint each other if the combination is not forbidden. This has to
      wait until the page layout is finally tackled I guess. 

    * anything else? ... probably

-- FrankMittelbach - 17 Dec 2007

ATOM RSS1 RSS2