Page Design in LATEX3
Total Page:16
File Type:pdf, Size:1020Kb
Page design in LATEX3 Morten Høgholm LATEX3 Project morten dot hoegholm (at) latex dash project dot org Abstract Choosing a page layout in LATEX is easy for the user with the help of packages like geometry and typearea. However, users face various problems when wishing to change the layout parameters mid-document — something which happens quite often: title pages, rotated pages (with rotated header and footer), special pages or spreads including large images, and other situations where manual fiddling is a difficult and error prone process. This article describes an interface for defining, storing, and retrieving com- plete page layouts. It will take a look under the hood to see how the data structures and programming constructs provided by the LATEX3 kernel ease the programming task. 1 Introduction Using the “raw” LATEX commands like this is not Setting and understanding the page layout param- an ideal interface for a designer. The layout package from the tools bundle alleviates this a bit by drawing eters in standard LATEX is not the easiest of tasks. There is no interface at all so it must be done by the layout for you so that you can check if it looks as setting all parameters manually and then hope you intended. This way you may also discover conflicting got them right. The packages geometry and typearea settings, as the kernel does not check this itself. both provide an interface for changing the parame- Should one wish to change some parameters ters for the entire document but there are situations temporarily mid-document their values must either where one may wish to use a different layout for just be stored or the changes done locally. However, the a few pages of the document: parameters are global (in the sense that they are set at the top level in the document preamble) and it • Title and back pages, where content is often is bad practice to do local changes to global param- centered on the physical page. eters. In short: there are no technical hindrances • Rotated pages, where some users want to also for the adventurous user to change the parameters rotate header and footer. at will but it is at best a tedious and error prone • Page spreads containing material crossing page procedure. borders. Another problem is that recto and verso pages Additionally, the ubiquitousness of PDF documents are exactly the same except for \evensidemargin on the Internet has opened up a new window of op- and \oddsidemargin. As a consequence, certain portunity: changing page size mid-document. types of designs become much harder to do in LATEX 2 The current solutions than you’d expect. For example, defining a page layout where every odd page is six lines shorter (be- Before trying to figure out a way to deal with page cause, say, this is reserved for supplementary text) is layout in LATEX3, it is probably a good idea to take slightly difficult because one has to manually change a closer look at the existing solutions within the the text height from page to page. LATEX 2ε framework. 2.1 The base distribution 2.2 The geometry and typearea packages The LATEX kernel doesn’t really have much of an in- The most popular package for changing the page terface when it comes to modifying the layout. The layout is the geometry package [4]. It provides an only way to change anything is to set the dimensions easier interface, one using a hkeyi = hvaluei syntax by hand by means of commands such as whereby the designer/user is shielded from the di- \setlength\paperheight{29.7cm} rect form of the LATEX parameters. The syntax is \setlength\paperwidth{21cm} almost self-explanatory: TUGboat, Volume 27 (2006), No. 2 — Proceedings of the 2006 Annual Meeting 213 Morten Høgholm \usepackage{geometry} These relationships are similar to what can be found \geometry{ in geometry and ease the task of autocompletion and paper = a4paper , error checking. textwidth = 6in , The output routine will have to know which lines = 42 values to use and the easiest way is probably to use } a set of global parameters with names such as Not surprisingly this makes the textwidth 6 in and \g_page_std_textheight_dim puts 42 lines of text on A4 paper. geometry does \g_page_std_textwidth_dim not try to enforce typographic rules of thumb on etc. For those unfamiliar with the LATEX3 naming the user except for choosing margin ratios suitable conventions, these are global dimension registers be- for printed books. Other than that, the user is re- longing to the page module and going by the name sponsible for everything. std_hparameteri. In a similar manner we will make A different approach is taken by the typearea each page type have an identical set of parameters, package from the koma-script bundle [3]. Based on except these go by names like the document font, it tries to produce a textwidth \l_page_htype i_textheight_dim of about 60–70 characters and then defines the lay- \l_page_htype i_textwidth_dim out in accordance with good typographic practice, etc., i.e., they are local parameters and then the such as a 1:2 relationship between top and bottom shipout routine can handle setting the global pa- margin. rameters to the value of the local ones. Defining For a more in-depth discussion of both geom- a complete set of parameters for each page type etry and typearea, see [2]. Common to both pack- uses quite a number of dimension registers but since ages is that they work only for the entire document: LAT X3 uses ε-T X (or better) we are not tied to so- All settings must be done in the preamble and thus E E lutions working within the tightly confined space of we have not yet solved one of our initial problems: the Knuthian T X engine. changing the parameters mid-document. E Since we have decided that all page types share 3 A new solution the same parameters, we must also solve the prob- lem of storing and retrieving parameter values since In order to come up with a solution to the problems, they must change between, for instance, recto and let’s take a step back and look at what sort of areas verso pages. For this task we turn our attention to may appear on a page. some of the tools provided by the LATEX3 kernel. 3.1 The parts of a page 3.2 Tools Instead of defining recto and verso pages we will de- TEX comes with only a few kinds of registers and fine one standard page description so that all differ- anything dealing with lists must be done in macros. ent page types have the same set of parameters, each The tools for list processing in the LATEX 2ε kernel parameter corresponding to a letter as shown in Fig- are restricted to token lists and comma separated ure 1. The indices w, h, and s denote width, height, lists, and even then there are only mapping func- and separation respectively. The central thing on tions. The LATEX3 kernel alleviates this by both ex- the page is the textblock T itself. The textblock tending the list of data structures with sequences is surrounded on all sides by header, footer, left and property lists as well as providing a complete area and right area. The left and right areas are set of tools for each data type: mapping, push/pop where margin notes may be positioned or as seen operations, etc. For the problem at hand we will use in some designs where the designer uses the right property lists. margin to place captions, section headings etc. and outside these areas are the actual margins. Finally 3.2.1 Property lists the final paper size is often different from the stock A property list is a list structure consisting of a series size so we must take this into account too. We can of keys, each with its own information field, of the notice several relationships: form Sw = tL + tR + pw \hkey 1 i{hinfo 1 i} \hkey 2 i{hinfo 2 i} ... Sh = tT + tB + ph For example, a small test file for the cross refer- pw = mL + Lw + Ls + Tw + Rw + Rs + mR encing module of LATEX3 contains a property list ph = mT + Hh + Hs + Th + Fs + Fh + mB \g_xref_mylabel_plist which expands to 214 TUGboat, Volume 27 (2006), No. 2 — Proceedings of the 2006 Annual Meeting Page design in LATEX3 6tT 6 ? 6 6 mT ? 6 Hh Header ? 6Hs ? tL- - 6 - - 6 - - 6 - -tR- mL Lw Ls Tw Rs Rw mR Lh L Rh R ? ? Th Sh ph - Sw - pw ? 6Fs ? 6 Fh Footer ? 6 mB ? ? 6tB ? ? Figure 1: The parts of a page: S is stock size, p is paper size, t are trims, m is margin, T is the text block, L and R are marginal note areas, and F and H are footer and header resp. TUGboat, Volume 27 (2006), No. 2 — Proceedings of the 2006 Annual Meeting 215 Morten Høgholm \xref_name_key {This is a name} Note that all of this does not touch the original prop- \xref_valuepage_key {1} erty list, so a number of operations can be performed \xref_page_key {i} by mapping functions onto it. For example, one Property lists are a natural way to store series/col- could reset all parameters to some special value (typ- lections of information. One such application could ically negative) and then a second mapping function be the babel language strings or, as we shall see, an could check if all parameters have indeed been set. array of length registers with saved values.