@Section @Title { Multi-page tables } @Tag { tbl_mult } @Begin @PP The tables produced by @Code "@Tbl" permit page breaks (including breaking tables. @RawIndex { tables } tables.multipage @SubIndex { multi-page } multi.page.tables @Index { multi-page tables } to a new column) between every two rows, except rows that have a vertically spanning cell in common. Page breaks cannot occur within rows. The choice of page breaks can either be left to Lout, or it can be forced by placing the new page symbol @Code "@NP" between two tables. @RawIndex { tables } tables.np @SubIndex { @Code "@NP" (new page) in } np. @RawIndex { @Code "@NP" (new page) } np.in.tables @SubIndex { in tables } rows. @PP To prevent page breaks within a table, precede the @Code "@Tbl" symbol by {@Code "@OneRow"}: @ID @Code "@CD @OneRow @Tbl ..." @Code "@OneRow" is a general Lout symbol which binds the following object into a single, unbreakable row. Make sure your table is small enough to fit on one page when you do this, otherwise an error message will be printed and it will be scaled to fit. Display symbols like @Code "@CD" often have this effect anyway. @PP To prevent a page break between two particular rows, but not in general, replace the @Code "@Row" symbol of the second row with tables. @RawIndex { tables } tables.nobreakrow @SubIndex { @Code "@NoBreakRow" symbols } nobreakrow.tables @Index { @Code "@NoBreakRow" symbols (tables) } the corresponding @Code "@NoBreakRow" symbol (@Code "@NoBreakRowa" instead of {@Code "@Rowa"}, @Code "@NoBreakRowb" instead of {@Code "@Rowb"}, and so on). @PP Some care is needed over where to put multi-page tables. They can't go within any of the display symbols, because display symbols are not clever enough to break tables between rows, even though they are sometimes able to break simpler displays. (A display symbol will scale a very high table to fit on one page, and it will go wrong on a table containing {@Code "@NP"}.) Multi-page tables can go inside @Code "@Figure" or @Code "@Table" symbols, because these symbols have been set up to accept multi-page objects. Or they can go into the body text of the document at full width with a paragraph symbol before and after, like this: @ID @Code @Verbatim { @DP @Tbl ... @DP } An example of this kind of multi-page table appears in Section {@NumberOf tbl_summ}. You can simulate an indent by means of an empty cell at the left of each row format, although in the author's opinion a multi-page table looks better at full width anyway. Lout will expand the rightmost column to the full page width; one way to prevent this is to add a @Code "|" after the last cell within each {@Code format} option, creating an empty extra column. @PP One practical problem in multi-page tables is getting the rules right. The simplest way to do this is to set @Code "rulehorizontal" to {@Code yes}. This places a rule above every row including the first on each page, and a rule below every row including the last on each page. There is nothing equivalent to running headers (described below) at the bottom of the page -- nothing that would allow you to insert a rule after the last line of each page, but not elsewhere. (However, if you are using the @Code "@Table" symbol, its @Code "@Format" option can be used to do this.) @PP Another practical problem with multi-page tables is that of getting a heading over every page after the first. This is easy if you know where the page breaks are going to fall (if you are using {@Code "@NP"}, for example), but you usually don't. To solve this problem, @Code {"@Tbl"} offers the @Code "@HeaderRowa" ... @Code "@HeaderRowh" and tables. @RawIndex { tables } tables.headerrow @SubIndex { @Code "@HeaderRow" symbols } headerrow.tables @Index { @Code "@HeaderRow" symbols (tables) } @Code "@EndHeaderRow" symbols. For example, the multi-page table in Section {@NumberOf tbl_summ} is arranged like this: @ID -1px @Break @OneRow @Code @Verbatim { @Tbl ... { @Rowd A { Option names } B { Default in PS, PDF } C { Default in plain text } D { Allowed values } rulebelow { yes } @HeaderRowd A { Option names (ctd.) } B { Default in PS, PDF } C { Default in plain text } D { Allowed values } rulebelow { yes } @Rowa A { paint p } B { none } D { any colour from Section {@NumberOf colour} } ... @Rowa A { ruleplainchar rpc } C { . } D { any simple word e.g. @Code + } rulebelow { yes } @EndHeaderRow } } @Code "@HeaderRowd" is exactly like {@Code "@Rowd"}, except that the row is not printed at all where it occurs; instead, it is saved up and used as a running header on subsequent pages. @PP The @Code "@EndHeaderRow" symbol goes where a @Code "@Row" symbol might go. Notice that it does not end with a letter between {@Code a} and {@Code h}, and that it has no options. Its effect is to cancel the closest preceding @Code "@HeaderRowa" ... @Code "@HeaderRowh" symbol. If you forget it, the result is bizarre: the header row will remain in effect, and then every page from this point on will have the running header, even though the table ended long before. @PP There may be any number of header rows saved up at any moment, all to be printed at the top of subsequent pages. Having @Code "@EndHeaderRow" allows them to be `nested.' For example, @ID -1px @Break @OneRow @Code @Verbatim { @HeaderRowa ... @HeaderRowb ... @EndHeaderRow @HeaderRowb ... @EndHeaderRow @EndHeaderRow } could be used in a table to say that the entire table has the first header row; and that the first part also has the second header row, but that subsequent parts of the table have their own, different second header row, but still the same first header row. @PP Certain kinds of objects are not allowed in header rows, and Lout will complain and quit if you try to put them there. Galleys (e.g. {@Code "@FootNote"} and {@Code "@Index"}) are not allowed, nor are cross references (e.g. {@Code "@NumberOf"} and {@Code "@PageOf"}), nor are {@Code "@HExpand"}, {@Code "@VExpand"}, or {@Code "@Scale"} in the form that works out its own scale factor. Spanning symbols ({@Code "@StartHSpan"}, {@Code "@StartVSpan"} etc.) work well in header row formats, however. @PP Header rows have some other peculiarities, not likely to trouble the ordinary user but worth pointing out. Header rows are taken account of by Lout when deciding column widths, whether they are actually printed or not. Basser Lout copies running header rows into the table after each page break, with no check on whether the next page has enough space to accommodate them, so if your running headers are so high that there is no room for ordinary rows on the page after they are inserted, then the document will never end. @End @Section