The Foundation for Responsible Info Stuffing

Inventions The HHFrisTi styles

Herman Haverkort

                  hermanh@cistron.nl

March 1999

Contents

1 Introduction 3

2 Files 3

3 Development and stability 3

4 Conditions of use 4

5 hhfrform – Page Lay-Out 5

6 hhfrtype– Stuffed Typesetting 6 6.1 Chosing the Font Family . . . . . . . . . . . . . . . . . . . . . 6 6.2 Chosing the Font Size and Line Skip . . . . . . . . . . . . . . 8

6.2.1 \hhfrsizes . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.2 Using Small Sizes . . . . . . . . . . . . . . . . . . . . . 8 6.2.3 Stretching the Base Line Skip . . . . . . . . . . . . . . 8 6.2.4 Using fristiform Options . . . . . . . . . . . . . . . 8

6.3 Typesetting Address Data Efficiently . . . . . . . . . . . . . . 9 6.3.1 Phone Numbers . . . . . . . . . . . . . . . . . . . . . . 9 6.3.2 Postcodes . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3.3 Residences . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3.4 Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3.5 Building Lists . . . . . . . . . . . . . . . . . . . . . . . 10

6.4 Adding Rules at Regular Intervals . . . . . . . . . . . . . . . 11 6.5 Stuffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.6 Duo typesetting . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7 hhfrdata– Data Processing 13 7.1 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2 Subrecords . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.3 Processing by Pattern Matching . . . . . . . . . . . . . . . . 14

7.3.1 Simple Patterns . . . . . . . . . . . . . . . . . . . . . . 14 7.3.2 Subrecords and subpatterns . . . . . . . . . . . . . . . 16 7.3.3 Flattening . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3.4 Using Record Data . . . . . . . . . . . . . . . . . . . . 17

7.4 Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.4.1 Ignoring Specials . . . . . . . . . . . . . . . . . . . . . 17 7.4.2 Setting the Ordering . . . . . . . . . . . . . . . . . . . 17

7.5 Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.5.1 Initialisation . . . . . . . . . . . . . . . . . . . . . . . 18 7.5.2 Recording Date Information . . . . . . . . . . . . . . . 18 7.5.3 Typesetting Date Information . . . . . . . . . . . . . . 18

8 hhfrlist– Some Standard FrisTi Lists 20 8.1 The Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2 Additional Stuffers . . . . . . . . . . . . . . . . . . . . . . . . 22 8.3 Language Option . . . . . . . . . . . . . . . . . . . . . . . . . 22

9 Examples 22

1 Introduction

hhfristi is a set of macros designed for typesetting address lists etc. with varying content, size, purpose, ordering etc. It is particularly suited for stuffing lots of information in a typographically responsible (readable) manner on relatively small lists.

2 Files

The hhfristi macros are provided in the following files:

hhfrbase.sty basic initialisations for the FrisTi system (is loaded automatically by the other FrisTi files; it needs hhutils0.sty);

hhfrform.sty macros for constructing FrisTi list pages; needs epic.sty

     and curves.sty;

hhfrtype.sty macros for responsible stuffed typesetting;

hhfrdata.sty macros for processing data records (sorting, pattern recognition), typically stored in a separate file;

hhfristi.sty ‘shorthand’ for loading all files mentioned above;

hhfrlist.sty some generalised FrisTi products (loads all files mentioned above).

epic.sty and curves.sty can be found on ctan. All other files are available from ctan or from the author’s website library at http://come.to/hh.

3 Development and stability

The FrisTi files emerged from practical applications. During its development the first goal was to get good results quickly. I gave attention to making macros and environments parameterised and reusable only when I discovered that I had to do things in nearly but not exactly the same way more than once. The FrisTi macros can be considered stable now in the sense that current documented functionality will remain available in future updates, in such a way that you will not have to change your own TEX code much. At most you will have to insert some switch setting or the like to enforce functionality which is default now but will be parameterised ‘out’ later. Such changes will be listed in update reports. If you run into applications where you want to adjust the FrisTi way of doing things to your own needs, but feel or suspect that sufficient switches, options, parameters and other specification tools are not there, please contact me and I will try to generalise the macros a bit further.

I wrote this manual a few years after writings the macros, so I might have made a few mistakes. I do not want to spend time on testing everything thoroughly while I am not sure anybody will ever need it, but if you notice any mistakes, please e-mail me and I will try to correct them.

This manual is more like a reference guide than a tutorial. It describes a lot of tools; it is the user’s task to figure out how the tools can be combined to a powerful system that suits your purposes. A more tutorial-like manual with step-by-step examples may be written later, but to be honest... I do not really plan on actually doing this for the time being.

4 Conditions of use

The hh packages are distributed in the hope that they will be useful, but without any warranty. The author does not accept any responsability for any damage, loss, injury, psychosis, annoyance, marital problems, murders etc. which are caused by these files.

If you use all or some of the hh packages and find them useful, please report it to me. I will not charge you anything; I just would like to get some idea of the use of my packages. Are they used heavily or hardly at all? This will also influence compatibility with future releases: if nobody uses my style files I will not mind turning the whole interface upside down, but if I know that someone out there depends on the stability of my packages, I will keep that in mind when changing things.

You are not allowed to take money for the distribution or use of either this file or a changed version, except for a nominal charge for copying etc. You are allowed to change the files to suit your needs if and only if you mention this in the descriptions in the \ProvidesPackage and \typeout lines. Changed versions may be distributed only with permission of the original author and if the file name has been changed. The line referring to the conditions of use may not be altered or removed.

Commercial use of the packages is not allowed without permission of the original author. It is therefore not allowed to manufacture anything which is typeset using FrisTi macros, and sell it for profit (even if it is sold to finance a non-profit organisation). If you want to make money out of FrisTi lists, contact me for an arrangement which depends of my sympathy for your purposes.

5 hhfrform – Page Lay-Out

The hhfristi list sizes and shapes can be selected using the fristiform environment. Text inside this environment is formatted to fit the specified shape and size, and consequently output in one or two boxes (for one and two sided lists). These boxes can be printed next to each other by including the fristiform environment in a \hbox, or on top of each other by using a

\vbox.

The fristiform environment requires one argument which is a list of options separated by commas. Simple options consist of a single keyword; value options consist of a keyword followed by the ‘=’ character and some kind of value. The options supported are listed in the tables that are floating somewhere in this document.

A simple example is:

\begin{fristiform}{size=A6,portrait}
  some interesting information
\end{fristiform}

Possible values for the size option are for example:

C credit card size (85.5mm × 53.8mm);

A6 A0 size, halved six times by shortening its longest side (148.7mm × 105.2mm);

A5/2 A5 size, halved by shortening its shortest side (210.5mm × 74.3mm);

A4/2/3 A4 size, with its shortest side divided by two and its longest side divided by three (105.2mm × 99.1mm);

Simple options

keyword keyword description
(default)  (alternative)

landscape portrait to be used after size or width and height options; landscape has no effect; portrait switches width and height values

row stack arrange pages as a row (vertical folds and turn-over axis) or as a stack (horizontal folds and turn-over axis)

noeye specifies that no space for a perforation is to be

created

nooutline outline wether or not an outline of the list shape is drawn vertices novertices wether or not corners outlines are drawn at rounded

corners

Table 1: Simple options for the fristiform environment

Any positive integers can be used instead of the values used above; any basic size identifier can be used instead of the ‘A’ and ‘C’ used above. Size identifiers ‘A’, ‘B’, ‘C’, ‘E’ (executive paper) and ‘L’ (letter paper) are predefined

with macro calls like \hhfr@basicsize{A}{1189.21mm}{841.90mm}; other

identifiers can be defined similarly.

The size options always sets width and height so that the width is the longest side. Use the portrait option afterwards to swap the sides.

6 hhfrtype– Stuffed Typesetting

hhfrtype defines a number of macros that ease readable typesetting in small space.

6.1 Chosing the Font Family

\textnr and \nrfamily are used to typeset numbers in, for example, an extra wide font. The font that is used for this purpose, can be specified by defining \nrdefault, e.g. \def\nrdefault{cmssq} (which is the default).

Value options

keyword  values  default decription
size  see descr.  A6 see description in text

width dimensions 148.7mm total width of the list height dimensions 105.2mm total height of the list

columns  1, 2, …  1 number of columns per page
colsep  dimensions  4pt distance between columns

colseprule dimensions 0.4pt width of rule between columns

folds  0, 1, …  0 number of folds
fold  dimensions  15pt amount of unused space around folds
hem  dimensions  6pt if there is more than one fold, then

strips parallel to the folds are created at the ends of the list; the width of the strips is two times the hem value (the strips can be doubled up to provide a kind of ‘handles’ that can be gripped to unfold the list)

sides 1, 2 2 selects one or two sided list outerhmar dimensions 6pt horizontal distance between border and

text (outer left and right margin)

innerhmar dimensions 6pt horizontal distance between fold space and text (left and right margin around folds; the total horizontal distance between two pages equals the fold plus two times the innerhmar)

outervmar dimensions 3pt anologous to outerhmar innervmar dimensions 3pt anologous to innerhmar eyepos l, r, t, b not set determines where space for a perfora-

tion should be created

eye dimensions 20pt diameter of the space taken by the perforation (this space is independent of the perforation outline that is drawn)

eyemar dimensions 0pt extra margin between the perforation space and the text (this margin is added

                                 to the outerhmar or outervmar used)

corner  dimensions  10pt radius of the rounded corners
seal  dimensions  0pt extra margin for sealing the laminate; it

is subtracted twice from the total width

                                 and height

line  dimensions  L^{A}TEX line thickness for outlines
stretch  positive v.  not set sets the baselinestretch

Table 2: Value options for the fristiform environment

6.2 Chosing the Font Size and Line Skip

6.2.1 \hhfrsizes

\hhfrsizes{size}{stretch} selects the font size and base line stretch. The \normalsize is set to size, all other standard font size macros (\scriptsize, \small, \large etc.) are set to appropriate values releative to size, and the base line stretch is set to stretch (use 1 for standard lines). All font sizes that are calculated by this macro, are rounded to standard values between 5pt and 24.88pt.

6.2.2 Using Small Sizes

To use sizes smaller than 5pt, you probably need to adjust the font definition files. If the font definition files are ok, add, for example, the following to your input file:

\makeatletter
\def\hhfr@tinysizes{{3.00pt}{3.50pt}{4.00pt}{4.50pt}}
\makeatother

This would enable use of 3pt and 4pt fonts, where calculated sizes below 3.5pt are rounded down to 3pt, values between are 3.5pt and 4.5pt are rounded to 4pt, and values between 4.5pt and 5pt are rounded up to 5pt.

6.2.3 Stretching the Base Line Skip

\hhfrlineflex{flex} sets the relative rubber stretch of the base line skip to flex. That is how far the base line skip may be stretched to make optimal use of the page. A zero value means no stretch at all; a value of .2 would mean that the base line skip may be enlarged by 20%. \hhfrlineflex has no effect until \hhfrsizes is used.

6.2.4 Using fristiform Options

If both hhfrform and hhfrtype are loaded, two additional options are available for the fristiform environment. These are fontsize=size and flex=flex. These options act as shorthands for calling the macros described above.

6.3 Typesetting Address Data Efficiently

6.3.1 Phone Numbers

\hhfrtel{\macro}{prefix}{postfix}{area code.number} typesets telephone numbers. The \macro takes one argument and is used to typeset the number: it is typically a font selection macro like \textbf or \textnr. The area code prefix is typically “(0”, the area code postfix is typically “) ”. The phone number is specified by digits, separated by dots. The first dot indicates the end of the area code. The rest of the phone number may contain aditional dots to mark places where thin spaces should be inserted to group the digits. The area code, including prefix and postfix, is omitted if it equals the default area code defined by \hhfr@telarea.

\hhfrdefaulttel{text} typesets text only if \hhfr@telarea has been defined. In text, each occurrence of \default is replaced by \hhfr@telarea.

6.3.2 Postcodes

\hhfrlocalpostcode{\digit-style}{\letter-style}{postcode} typesets postcode, using \digit-style (e.g. \textnr) to typeset the digits and \letter-style (e.g. \textsc) to typeset the letters. The macro does not check which characters are digits and which are letters. The standard version in the hhfrtype package assumes that the postcode actually consists of digits only. If the package is loaded with the dutch option, the macro expects a code of four digits followed by two letters.

\hhfrlocalpostcode checks if the first characters of the postcode to be typeset, are the same as in the expansion of \hhfr@postarea. If so, the first characters are encapsulated in \default{ and }. That \default must be de-

fined when \hhfrlocalpostcode is expanded. Using \let\default\relax

or \def\default#1{}, one can choose whether default leading characters should be typeset or not. \hhfr@postarea is initialised empty.

\hhfrdefaultpost{text} typesets text only if \hhfr@postarea is non-empty. In text, each occurrence of \default is replaced by \hhfr@postarea.

6.3.3 Residences

Residences are often known by heart, and if not, can be deduced from the postcodes. So one can save a lot of space on a list by omitting the residences, and typesetting a postcode-residence directory above or below the list instead. hhfrtype provides three macros to facilitate this.

\hhfrrecordpostcodes{residence}{lowest}{highest} inserts the residence name with its lowest and highest postcodes in an internal postcode list, if it is not already there. Instead of the full postcodes, you may use just enough digits to distinguish the postcodes from those of other places.

\hhfrpostcodes{title}{\style} typesets the postcode list which was filled using \hhfrrecordpostcodes. It uses title as a run-in heading and \style

for typesetting the codes (e.g. \hhfrlocalpostcode{\textnr}{\textsc}).

\hhfrinitpostcodes empties the postcode list.

6.3.4 Dates

\hhfrgobblecentury{digit}{digit}{replacement}{year} can be useful to typeset years efficiently. year should be a sequence of digits or a macro expanding directly to such a sequence. If the first digits of year are the same as the digits after \hhfrgobblecentury, they are replaced by replace-

ment. A typical use is \hhfrgobblecentury{1}{9}{'}{\year}, or just

\hhfrgobblecentury19'\year (recall that braces can be omitted around one-token arguments).

6.3.5 Building Lists

\hhfrqueue\macro{delimiter}{text} extends the definition of the \macro by appending the text. If the macro was not empty, the delimiter is used. For example, suppose that \names has been defined by \gdef\names{}. Then

\hhfrqueue\names{ and }{Frans} defines \names to expand to Frans, and
a following \hhfrqueue\names{ and }{Herman} redefines \names to Frans
and Herman.

6.4 Adding Rules at Regular Intervals

\hhfrafter{interval}{something} inserts something after every interval-th use of \hhfrafter. This can be used to add rules or white space after every interval-th line.

The line count is maintained in a counter hhfr@counter, which can be reset

by \setcounter{hhfr@counter}{0}.

6.5 Stuffing

hhfrtype provides ‘stuffers’, macros that can act differently depending on the ‘stuffing pressure’. An example of such a macro is \sml. The macro \sml is

defined by \defstuffer{sml}{3}{#1#2#3}[2]{{\small #2}}. This mean-

s, from left to right, that \sml gets 3 arguments, \sml normally typesets them all (#1#2#3), but if the level of stuffing pressure is 2 or less (the lower the number, the higher the pressure), \sml typesets {\small #2} instead, that is only the middle argument, in a small size.

Stuffers can have multiple levels, so another definition for \sml could have

been: \defstuffer{sml}{3}{#1#2#3}[2]{{\small #2}}[1]{{\tiny #2}}.

If this had been the definition, the middle argument would be typeset small if the stuffing pressure is 2, and it would be typeset tiny at if the pressure aggravates to 1.

In general stuffers are passive: they always act as if there were a lot of space. However, when using the macro \hhfrsqueeze, stuffers can be useful. \hhfrsqueeze{dimension}{text} tries to stuff text in a \hbox that is at most dimension wide. It does so by experimenting with different settings of the stuffing pressure, so that stuffers contained in the text can have their use if they can make text fit.

hhfrtype provides a few basic stuffers that can be used to have TEX try full typesetting or abbreviations, and in the case of residence names: typesetting the name, or entering it in the postcode table (see above). When hhfrtype is loaded with the dutch option, Dutch language equivalents for the basic stuffers are available, and some macros that enable automatic abbreviations of common parts of family and street names. These are \van, \vdn, \vdr,

\vd, \de, \et (’t), \straat, \weg, \laan, \steeg, \singel, \dreef and

\plein. One can always define more stuffers with \defstuffer.

The basic stuffers predefined in hhfrtype are given below (Dutch macro names are given in brackets).

\rsd{text} [\rsd] typesets text small raised 2pt.

\sml{prefix}{text}{postfix} [\kln] typesets prefix, text and postfix; if the stuffing pressure is 2 or less, it typesets text only, small.

\lng{text} [\lng] typesets text only if the stuffing pressure is above 3.

\sht{text} [\krt] typesets text only if the stuffing pressure is 3 or less.

\abb{shorthand}{full form} [\afk] typesets full form if the stuffing pressure is above 3; typesets shorthand if the stuffing pressure is 3 or less.

NB It is fine to have short, easy names for stuffers, but of course this makes conflicts with other packages more likely. Because of that, stuffer definitions are not activated when hhfrtype is loaded. The stuffers can be activated by using \hhfrtools, which is best done inside a group.

6.6 Duo typesetting

\hhfrduo is macro that facilitates efficient handling of two (or more) items sharing partly the same information, for example two persons having the same address. \hhfrduo facilitates trying to typeset them both (or all) on one line, and if that turns out to be impossible, typesetting them each on a separate line after all. \hhfrduo takes five arguments:

1. a macro that takes two arguments (a dimension register and a name) and typesets the name (if possible using less width than specified in the dimension register);

2. a dimension register that holds the available width for typesetting the name;

3. a macro that takes one argument (a box register containing a typeset name) and typesets a full address line, using the contents of the box register;

4. whatever you would like to use to separate names, e.g. {, };

5. a list of names in the following form {{first}{second}...etc...{last}}.

7 hhfrdata– Data Processing

hhfrdata enables you to enter the data to be listed in a way indepented of the lay-out. Thus you can use the same data file for different lists, which do not only differ in the selection of data and the order in which the fields have to presented, but also in the stuffing tricks used. Just put the data in a separate file, possibly using stuffers (see previous section) to indicate where abbreviations etc. may be used if necessary. Then you can input the data within various listsm, while each lists can use the data and the stuffing directions in its own way.

7.1 Records

The basic idea is that all data is entered in the form of records in the following form: \itm{record}. Each record consists of a number of tagvalue pairs. Tags and values are separated by colons; pairs are separated by semicolons and spaces. So a typical example of a record would be:

\itm{foa:Mr.; name:Herman; fam:Haverkort;
     eml:hermanh@cistron.nl}

Tags can be anything, except that colons and semicolons cannot be used without special measures. Values can be anything, but they must be enclosed in braces if they contain a ungrouped semicolon followed by a space.

When several records are listed directly after eachother it is allowed to omit the \itm-macros between them, like in:

\itm{name:Herman; fam:Haverkort}{name:Frans; fam:Goddijn}

7.2 Subrecords

If, for example, two or more persons share the same information, the shared information is specified as normal, while the person specific information is given in a list of embraced subrecords, one for each person. For example, suppose I were married to a Hanneke who uses my e-mail address, our joint record would look like:

\itm{{foa:Mrs.; name:Hanneke}{foa:Mr.; name:Herman};
     fam:Haverkort; eml:hermanh@cistron.nl}

The same approach can be taken if one person has multiple addresses, or telephone numbers, or whatever. Then the person’s name can be considered shared information for the phone numbers, and the phone numbers are put in a list of subrecords. Subsubrecords etc. are possible as well, e.g. if several people at the same address share last names in groups.

7.3 Processing by Pattern Matching

The fristidata environment processes record data in the above format. It does so by defining \itm to do something useful, namely trying to match the record data to a pattern that the fristidata knows how to handle.

The basic syntax of fristidata is:

\begin{fristidata}{initialisation}{patterns}

data

\end{fristidata}.

Patterns are given separated by semicolons and spaces (just like tag-value pairs in a record), where a single pattern looks like: requirements -> \action. The \action is what should be done with data that fulfills the requirements.

The data can be anything including \itm-records, which may be input from a file. The records are handled by the fristidata pattern recognition system; other stuff is typeset as usual. A record is processed by checking if it fulfills the requirements of one of the specified patterns, then executing the initialisation procedure (which can be anything), and then executing the action macro specified by the matching pattern. Only the first matching pattern is used.

7.3.1 Simple Patterns

Let me give you an example and try to explain it to you.

\begin{fristidata}{\noindent}{%
    +name +fam ?eml -> \usefirstname;
    ?foa +inits +fam ?eml -> \useinitials;

    -fam -> \MrX}
  \textbf{Example list}\par\medskip                         % 1
  \itm{foa:Mrs.; inits:B.C.E.; fam:Schilder}                % 2
  \itm{fam:Janssen; eml:janssen@star.sa}                    % 3
  \itm{foa:Mr.; name:Henk; fam:Zweers; eml:hz@inter.nl.net} % 4
  \itm{foa:Miss; name:Karin}                                % 5
  \itm{foa:Mr.; name:Koen; fam:Haverkort}                   % 6
\end{fristidata}

\noindent is the initialisation. On the next three lines, three patterns are given. Each pattern consists of a number of requirements and an action macro (\usefirstname, \useinitials or \MrX). For now, we assume that these action macros have been defined to do something useful with the record data (see section 7.3.4 on how to do this).

Within each pattern, the individual requirements are separated by spaces. Basic requirements, like in the example, consist of a plus sign, minus sign or question mark followed by a field tag. The plus sign indicates that a matching record should give a (single) value for the specified tag, the minus sign indicates that it should not, and the question mark indicates that it may specify a value for the tag concerned. For tags not mentioned in the pattern, values may be specified as well. Using explicite question mark requirements can be useful for clarity and they can be needed when using subrecords and subpatterns. These will be discussed later.

So what will be done with each record in the example?

1. The first line in the environment is typeset as usual.

2. The second is a record that does not fit the first pattern because the first pattern requires a value for name. Therefore the second pattern is succesfully tried and the record is typeset using the initialisation \noindent and the macro \useinitials mentioned by the pattern.

3. The third line does not fit the first pattern because it does not give a name, it does not fit the second pattern because of the missing inits (initials), and it does not fit the third pattern because it does specify a fam (family name), which the pattern forbids. So no matching pattern is found for the third line and hhfrdata will issue a warning message.

4. Matches the first pattern and will be typeset using \noindent and

     \usefirstname.

5. Matches the third pattern.

6. Matches the first pattern again.

7.3.2 Subrecords and subpatterns

Subpatterns are used in composite requirements. Composite requirements look like *number{requirements -> \action}. A record fulfills a composite requirement, if it contains at least number subrecords that fulfill the requirements of the subpattern. If the complete record matches the complete pattern, the initialisation macro is expanded first, then the action macro in the subpattern for each of the matching subrecords, and finally the action macro of the full pattern.

If the number is 1, a record matches the composite requirement also if it matches the requirements of the subpattern at top level, without subrecords.

A few examples:

+horse ?str ?hnr ?res +fam *1{+name -> \firstname} -> \total;
+horse ?str ?hnr ?res *2{+fam +name -> \fullname} -> \total

The first pattern matches each record about a horse owned by one or more persons who share the same family name and address (if known). For each person, the macro \firstname is used; the macro \total is used to handle the whole.

The second pattern matches each record about a horse owned by at least two persons with different family names, but living at the same address (if known). For each person, the macro \fullname is used; the macro \total handles the whole.

7.3.3 Flattening

If a record with subrecords does not match any pattern, it is automatically ‘flattened’: for each combination of subrecords and top-level data, a separate record without subrecords is constructed. The flattened records are then checked again.

7.3.4 Using Record Data

Recall that fristidata relies on action macros to handle records that match a pattern. To do something useful one needs to be able to address the data of the matching record. This can be done with \frat{tag}, which expands to the value paired with the tag in the record concerned.

Besides there is \withfrat{\tag}{text}, which expands to text only if there is some value attached to the tag. Otherwise it expands to nothing. For example: \withfrat{hnr}{~\frat{hnr}} is effective only if some value for hnr (house number) is known, and if so, the number is typeset prefaced by a tie.

7.4 Sorting

The fristisort environment processes record data in the same format as fristidata (it actually uses fristidata for this). The basic syntax of

fristisort is \begin{fristisort}{tag}data\end{fristidata}.

The data can be anything including \itm-records, which may be input from a file. The records are sorted according to the values for the tag fields and output after the fristisort environment. Non-record data is typeset as usual immediately.

NB Sorting this way is not exactly fast...

7.4.1 Ignoring Specials

The fristisort can have trouble sorting tag values containing macros. To make fristisort ignore certain macros (or characters), use \hhfrignore tokens to ignore\whensorting before you use the fristisort environment.

7.4.2 Setting the Ordering

\hhfr@order{first<second<...<last} defines the sorting order (define this macro in a style file or between \makeatletter and \makeatother). Between the braces, several equivalence classes may be given, separated by < signs. Each class consists of one or more tokens that will be considered equal for sorting purposes. Upper case equivalents are considered equal as well.

The default sorting order is defined by:

\hhfr@order{a<b<c<d<e<f<g<h<i<j<k<l<m<n<o<p<q<r<s<t<u<v<w<x<y<z}

Note that lower case characters are used. Thus \hhfr@order will handle both lower and upper case characters; if upper case characters were given, \hhfr@order would not handle the lower case characters.

7.5 Calendars

hhfrdata provides a few macros to ease the typesetting of, for example, birthday calendars.

7.5.1 Initialisation

\hhfrinitcalendar{id} initialises a calendar by the name id. Initialisation is necessary before any events can be stored.

7.5.2 Recording Date Information

\hhfrrecorddate{id}{description}{day/month/year} stores the event description (a name, for example) at the day-th day of the month-th month of the calendar identified by id. The year can be omitted; if specified, it is stored with the event.

7.5.3 Typesetting Date Information

\hhfrsetmonth{arg1 }{arg2 }...{arg9 } typesets one month of a calendar. The nine arguments are the following:

1. initalisation: this is expanded before anything else is typeset;

2. first of month: what should be typeset before the first event of the month;

3. following days: what should be typeset before the first event of the day, but not the first of the month; 4. following items: what should be typeset before second and following

events on the same day;

5. info: how to typeset event data;

6. termination: this is placed after the last event of the month;

7. index: a number from 1 to 12, indicating the month to be typeset;

8. month: a number or a word that can be typeset to identify the month;

9. calendar: the identification of the calendar that is typeset.

In the arguments of \hhfrsetmonth, the following macros may be used:

\month the number or the word that identifies the month (eight argument);

\date the number of the day of the event that is being handled;

\year the year stored with the event;

\subj the description of the event that is being handled.

Naturally, you will need to use \date at least in the second and third or in the fifth argument.

To typeset a complete calendar, \hhfrsetcalendar can be used. The syntax is \hhfrsetcalendar{how to set one month}{first}{id}{names}.

How to set one month must be something which takes three arguments (month number, month word and calendar identification) and typesets one month. This can be \hhfrmonth with only the first six arguments given, leaving the remaining three arguments to be supplied automatically by the

\hhfrsetcalendar mechanism.

First is a number from 1 to 12, indicating the month that is typeset first (meaning that the month before is typeset last).

Id is the calendar identification.

Names must be a list of month names or numbers, headed, separated and followed by spaces, e.g.:

{ Jan. Febr. March April May June July Aug. Sept. Oct. Nov. Dec. }

8 hhfrlist– Some Standard FrisTi Lists

8.1 The Lists

hhfrlist provides three standard types of ‘stuffed’ lists: a full address list, a phone list and a birthday calendar. To typeset such lists, open the list environment with \begin{list}{title}{options}, type or input the data records, and close the list with \end{list}.

In this construct, list is one out of:

• fristimax (for the address list);

• phonelist (for the phone list);

• cakelist (for the birthday calendar).

The title will be typeset above the list.

The options are meant for the fristiform environment handling the paper size, lay-out etc. (see the section about hhfrform). Besides, additional options are available as listed in the table on the next page.

The data records must be in the \itm-format as explained in the previous section. Within the records, tags will be recognized as listed in the table below. In this table, f means fristimax address list, p phonelist phone list; c cakelist birthday calendar).

Additional Options for All Lists

keyword  values  default decription
textshape  font macro  not set default text font
fontsize  dimension  not set normal font size
flex  posit. value  not set the relative rubber stretch of the

base line skip (see explanation of

                                      \hhfrlineflex

Additional Options for the fristimax Address List

keyword values default decription

numbershape font macro \bfseries phone number font postarea postcode not set sets the (leading part of the) post-

code that can be omitted in local postcodes

addresswidth dimension .5\hsize width reserved for postcode and address (leaving the rest for name and phone number)

doubleline no value not set puts addresses on separate lines

below names and phone numbers

telarea area code not set sets the area code that can be

omitted before local numbers

Additional Options for the phonelist Phone List

keyword values default decription

numbershape font macro \nrfamily phone number font telarea area code not set sets the area code that can be

omitted before local numbers

flush l, r, c or f l(eft) left, right, centered or filled justification. Filled justification puts names to the left, numbers to the right, and rules in between

Additional Options for the cakelist Birthday Calendar

keyword values default decription

numbershape font macro \nrfamily sets the date font

Table 3: Additional form options for the standard lists

tag  used by meaning
name F P C first name
ins  F  insertion
fam  F  family name

fni P C family name initial, used to distinguish people with the

same first name on the phone and cake lists

tel F P phone number, consisting of digits and dots; the first dot

marks the end of the area code; following dots group digits

telss F P phone Saturdays and Sundays; see tel for structure

fax  F  fax number; see tel for structure
eml  F  e-mail address
str  F  street
hnr  F  house number
pcd  F  postcode
res  F  residence

dob C day of birth (two-digit number) mob C month of birth (two-digit number)

yob  C year of birth

8.2 Additional Stuffers

To ease handling residence names in the fristimax lists, hhfrlist provides two additional stuffers.

\res{lowest postcode}{highest postcode}{short form}{full name} is meant to be used as a value for the res tag. fristimax will try to typeset the full residence name. If this cannot be done, fristimax will try to fit the short form, while the full name is listed in the postcode directory above the address list.

\preres{something} typesets something only if residence names are typeset (full or abbreviated).

8.3 Language Option

For Dutch explanations, months etc. on the lists, load hhfrlist with the dutch option.

9 Examples

For a few examples and some design guidelines, see the article published as gif-files in the library of my website at http://come.to/hh.