texk 1

git-svn-id: svn://tug.org/texlive/trunk@1485 c570f23f-e606-0410-a88d-b1316a301751

1 files changed, 1727 insertions, 0 deletions

diff --git a/Build/source/texk/web2c/pktogf.web b/Build/source/texk/web2c/pktogf.web
new file mode 100644
index 00000000000..8fc8a0256f6
--- /dev/null
+++ b/Build/source/texk/web2c/pktogf.web
@@ -0,0 +1,1727 @@
+% PKtoGF.web
+%
+%  PKtoGF creates a generic font file from a packed pixel file.
+%
+% Preliminary 0.0 version:  January, 1988
+% Fixed bug to include specials in character (1.0): January 1988
+% Cleaned up description (bitweight errors) no version change:  July 1990
+% Fixed bug with empty character setting min_n to 1 (1.1): 19 October 1990
+\def\versiondate{19 October 1990}
+%
+\font\ninerm=cmr9
+\let\mc=\ninerm % medium caps for names like PASCAL
+\font\logo=logo10 % font used for the METAFONT logo
+\def\MF{{\logo META}\-{\logo FONT}}
+\def\PASCAL{{\mc Pascal}}
+\def\tamu{Texas A\char38 M}
+\def\(#1){} % this is used to make section names sort themselves better
+\def\9#1{} % this is used for sort keys in the index
+\def\title{PKtoGF}
+\def\contentspagenumber{0}
+\def\topofcontents{\null
+  \def\titlepage{F} % include headline on the contents page
+  \def\rheader{\mainfont\hfil \contentspagenumber}
+  \vfill
+  \centerline{\titlefont The {\ttitlefont PKtoGF} processor}
+  \vskip 15pt
+  \centerline{(Version 1.1, \versiondate)}
+  \vfill}
+\def\botofcontents{\vfill
+  \centerline{\hsize 5in\baselineskip9pt
+    \vbox{\ninerm\noindent
+    The preparation of this report
+    was supported in part by the National Science
+    Foundation under grants IST-8201926 and MCS-8300984,
+    and by the System Development Foundation. `\TeX' is a
+    trademark of the American Mathematical Society.}}}
+\pageno=\contentspagenumber \advance\pageno by 1
+
+@* Introduction.
+This program takes a packed, or \.{PK} file, and converts it into the
+standard \.{GF} format.  The resulting \.{GF} file is standard in
+every way, and is essentially identical to the \.{GF} file from which
+the \.{PK} file was produced in the first place.  Note that, however,
+\.{GF} to \.{PK} to \.{GF} is not an exact identity transformation, as
+the new \.{GF} file will have a different preamble string and the actual
+minimum bounding box will be used, instead of a possibly larger bounding
+box in the original \.{GF} file.
+
+@ The |banner| string defined here should be changed whenever \.{PKtoGF}
+gets modified.  You should update the preamble comment as well.
+
+@d banner=='This is PKtoGF, Version 1.1'
+         {printed when the program starts}
+@d preamble_comment=='PKtoGF 1.1 output'
+@d comm_length==17
+
+@ This program is written in standard \PASCAL, except where it is necessary
+to use extensions; for example, \.{PKtoGF} must read files whose names
+are dynamically specified, and that would be impossible in pure \PASCAL.
+
+@d othercases == others: {default for cases not listed explicitly}
+@d endcases == @+end {follows the default case in an extended |case| statement}
+@f othercases == else
+@f endcases == end
+
+@ Both the input and output come from binary files.  On line interaction
+is handled through \PASCAL's standard |input| and |output| files.
+
+@d print_ln(#)==write_ln(output,#)
+@d print(#)==write(output,#)
+
+@p program PKtoGF(input, output);
+label @<Labels in the outer block@>@/
+const @<Constants in the outer block@>@/
+type @<Types in the outer block@>@/
+var @<Globals in the outer block@>@/
+procedure initialize; {this procedure gets things started properly}
+  var i:integer; {loop index for initializations}
+  begin print_ln(banner);@/
+  @<Set initial values@>@/
+  end;
+
+@ If the program has to stop prematurely, it goes to the
+`|final_end|'.
+
+@d final_end=9999 {label for the end of it all}
+
+@<Labels...@>=final_end;
+
+@ These constants determine the maximum length of a file name and the length
+of the terminal line, as well as the maximum number of run counts allowed
+per line of the \.{GF} file.  (We need this to implement repeat counts.)
+@^system dependancies@>
+
+@<Constants...@>=
+@!name_length=80; {maximum length of a file name}
+@!terminal_line_length=132; {maximum length of an input line}
+@!max_counts=400; {maximum number of run counts in a raster line}
+
+@ Here are some macros for common programming idioms.
+
+@d incr(#) == #:=#+1 {increase a variable by unity}
+@d decr(#) == #:=#-1 {decrease a variable by unity}
+@d do_nothing == {empty statement}
+
+@ It is possible that a malformed packed file (heaven forbid!) or some other
+error might be detected by this program.  Such errors might occur in a deeply
+nested procedure, so the procedure called |jump_out| has been added to transfer
+to the very end of the program with an error message.
+
+@d abort(#)==begin print_ln(' ',#); jump_out; end
+
+@p procedure jump_out;
+begin goto final_end;
+end;
+
+@* The character set.
+Like all programs written with the  \.{WEB} system, \.{PKtoGF} can be
+used with any character set. But it uses ASCII code internally, because
+the programming for portable input-output is easier when a fixed internal
+code is used.
+
+The next few sections of \.{PKtoGF} have therefore been copied from the
+analogous ones in the \.{WEB} system routines. They have been considerably
+simplified, since \.{PKtoGF} need not deal with the controversial
+ASCII codes less than @'40.
+
+@<Types...@>=
+@!ASCII_code=" ".."~"; {a subrange of the integers}
+
+@ The original \PASCAL\ compiler was designed in the late 60s, when six-bit
+character sets were common, so it did not make provision for lower case
+letters. Nowadays, of course, we need to deal with both upper and lower case
+alphabets in a convenient way, especially in a program like \.{GFtoPK}.
+So we shall assume that the \PASCAL\ system being used for \.{GFtoPK}
+has a character set containing at least the standard visible characters
+of ASCII code (|"!"| through |"~"|).
+
+Some \PASCAL\ compilers use the original name |char| for the data type
+associated with the characters in text files, while other \PASCAL s
+consider |char| to be a 64-element subrange of a larger data type that has
+some other name.  In order to accommodate this difference, we shall use
+the name |text_char| to stand for the data type of the characters in the
+output file.  We shall also assume that |text_char| consists of
+the elements |chr(first_text_char)| through |chr(last_text_char)|,
+inclusive. The following definitions should be adjusted if necessary.
+@^system dependencies@>
+
+@d text_char == char {the data type of characters in text files}
+@d first_text_char=0 {ordinal number of the smallest element of |text_char|}
+@d last_text_char=127 {ordinal number of the largest element of |text_char|}
+
+@<Types...@>=
+@!text_file=packed file of text_char;
+
+@ The \.{GFtoPK} processor converts between ASCII code and
+the user's external character set by means of arrays |xord| and |xchr|
+that are analogous to \PASCAL's |ord| and |chr| functions.
+
+@<Globals...@>=
+@!xord: array [text_char] of ASCII_code;
+  {specifies conversion of input characters}
+@!xchr: array [0..255] of text_char;
+  {specifies conversion of output characters}
+
+@ Under our assumption that the visible characters of standard ASCII are
+all present, the following assignment statements initialize the
+|xchr| array properly, without needing any system-dependent changes.
+
+@<Set init...@>=
+for i:=0 to @'37 do xchr[i]:='?';
+xchr[@'40]:=' ';
+xchr[@'41]:='!';
+xchr[@'42]:='"';
+xchr[@'43]:='#';
+xchr[@'44]:='$';
+xchr[@'45]:='%';
+xchr[@'46]:='&';
+xchr[@'47]:='''';@/
+xchr[@'50]:='(';
+xchr[@'51]:=')';
+xchr[@'52]:='*';
+xchr[@'53]:='+';
+xchr[@'54]:=',';
+xchr[@'55]:='-';
+xchr[@'56]:='.';
+xchr[@'57]:='/';@/
+xchr[@'60]:='0';
+xchr[@'61]:='1';
+xchr[@'62]:='2';
+xchr[@'63]:='3';
+xchr[@'64]:='4';
+xchr[@'65]:='5';
+xchr[@'66]:='6';
+xchr[@'67]:='7';@/
+xchr[@'70]:='8';
+xchr[@'71]:='9';
+xchr[@'72]:=':';
+xchr[@'73]:=';';
+xchr[@'74]:='<';
+xchr[@'75]:='=';
+xchr[@'76]:='>';
+xchr[@'77]:='?';@/
+xchr[@'100]:='@@';
+xchr[@'101]:='A';
+xchr[@'102]:='B';
+xchr[@'103]:='C';
+xchr[@'104]:='D';
+xchr[@'105]:='E';
+xchr[@'106]:='F';
+xchr[@'107]:='G';@/
+xchr[@'110]:='H';
+xchr[@'111]:='I';
+xchr[@'112]:='J';
+xchr[@'113]:='K';
+xchr[@'114]:='L';
+xchr[@'115]:='M';
+xchr[@'116]:='N';
+xchr[@'117]:='O';@/
+xchr[@'120]:='P';
+xchr[@'121]:='Q';
+xchr[@'122]:='R';
+xchr[@'123]:='S';
+xchr[@'124]:='T';
+xchr[@'125]:='U';
+xchr[@'126]:='V';
+xchr[@'127]:='W';@/
+xchr[@'130]:='X';
+xchr[@'131]:='Y';
+xchr[@'132]:='Z';
+xchr[@'133]:='[';
+xchr[@'134]:='\';
+xchr[@'135]:=']';
+xchr[@'136]:='^';
+xchr[@'137]:='_';@/
+xchr[@'140]:='`';
+xchr[@'141]:='a';
+xchr[@'142]:='b';
+xchr[@'143]:='c';
+xchr[@'144]:='d';
+xchr[@'145]:='e';
+xchr[@'146]:='f';
+xchr[@'147]:='g';@/
+xchr[@'150]:='h';
+xchr[@'151]:='i';
+xchr[@'152]:='j';
+xchr[@'153]:='k';
+xchr[@'154]:='l';
+xchr[@'155]:='m';
+xchr[@'156]:='n';
+xchr[@'157]:='o';@/
+xchr[@'160]:='p';
+xchr[@'161]:='q';
+xchr[@'162]:='r';
+xchr[@'163]:='s';
+xchr[@'164]:='t';
+xchr[@'165]:='u';
+xchr[@'166]:='v';
+xchr[@'167]:='w';@/
+xchr[@'170]:='x';
+xchr[@'171]:='y';
+xchr[@'172]:='z';
+xchr[@'173]:='{';
+xchr[@'174]:='|';
+xchr[@'175]:='}';
+xchr[@'176]:='~';
+for i:=@'177 to 255 do xchr[i]:='?';
+
+@ The following system-independent code makes the |xord| array contain a
+suitable inverse to the information in |xchr|.
+
+@<Set init...@>=
+for i:=first_text_char to last_text_char do xord[chr(i)]:=@'40;
+for i:=" " to "~" do xord[xchr[i]]:=i;
+
+@* Generic font file format.
+The most important output produced by a typical run of \MF\ is the
+``generic font'' (\.{GF}) file that specifies the bit patterns of the
+characters that have been drawn. The term {\sl generic\/} indicates that
+this file format doesn't match the conventions of any name-brand manufacturer;
+but it is easy to convert \.{GF} files to the special format required by
+almost all digital phototypesetting equipment. There's a strong analogy
+between the \.{DVI} files written by \TeX\ and the \.{GF} files written
+by \MF; and, in fact, the file formats have a lot in common.
+
+A \.{GF} file is a stream of 8-bit bytes that may be
+regarded as a series of commands in a machine-like language. The first
+byte of each command is the operation code, and this code is followed by
+zero or more bytes that provide parameters to the command. The parameters
+themselves may consist of several consecutive bytes; for example, the
+`|boc|' (beginning of character) command has six parameters, each of
+which is four bytes long. Parameters are usually regarded as nonnegative
+integers; but four-byte-long parameters can be either positive or
+negative, hence they range in value from $-2^{31}$ to $2^{31}-1$.
+As in \.{TFM} files, numbers that occupy
+more than one byte position appear in BigEndian order,
+and negative numbers appear in two's complement notation.
+
+A \.{GF} file consists of a ``preamble,'' followed by a sequence of one or
+more ``characters,'' followed by a ``postamble.'' The preamble is simply a
+|pre| command, with its parameters that introduce the file; this must come
+first.  Each ``character'' consists of a |boc| command, followed by any
+number of other commands that specify ``black'' pixels,
+followed by an |eoc| command. The characters appear in the order that \MF\
+generated them. If we ignore no-op commands (which are allowed between any
+two commands in the file), each |eoc| command is immediately followed by a
+|boc| command, or by a |post| command; in the latter case, there are no
+more characters in the file, and the remaining bytes form the postamble.
+Further details about the postamble will be explained later.
+
+Some parameters in \.{GF} commands are ``pointers.'' These are four-byte
+quantities that give the location number of some other byte in the file;
+the first file byte is number~0, then comes number~1, and so on.
+
+@ The \.{GF} format is intended to be both compact and easily interpreted
+by a machine. Compactness is achieved by making most of the information
+relative instead of absolute. When a \.{GF}-reading program reads the
+commands for a character, it keeps track of two quantities: (a)~the current
+column number,~|m|; and (b)~the current row number,~|n|.  These are 32-bit
+signed integers, although most actual font formats produced from \.{GF}
+files will need to curtail this vast range because of practical
+limitations. (\MF\ output will never allow $\vert m\vert$ or $\vert
+n\vert$ to get extremely large, but the \.{GF} format tries to be more
+general.)
+
+How do \.{GF}'s row and column numbers correspond to the conventions
+of \TeX\ and \MF? Well, the ``reference point'' of a character, in \TeX's
+view, is considered to be at the lower left corner of the pixel in row~0
+and column~0. This point is the intersection of the baseline with the left
+edge of the type; it corresponds to location $(0,0)$ in \MF\ programs.
+Thus the pixel in \.{GF} row~0 and column~0 is \MF's unit square, comprising
+the region of the plane whose coordinates both lie between 0 and~1. The
+pixel in \.{GF} row~|n| and column~|m| consists of the points whose \MF\
+coordinates |(x,y)| satisfy |m<=x<=m+1| and |n<=y<=n+1|.  Negative values of
+|m| and~|x| correspond to columns of pixels {\sl left\/} of the reference
+point; negative values of |n| and~|y| correspond to rows of pixels {\sl
+below\/} the baseline.
+
+Besides |m| and |n|, there's also a third aspect of the current
+state, namely the @!|paint_switch|, which is always either \\{black} or
+\\{white}. Each \\{paint} command advances |m| by a specified amount~|d|,
+and blackens the intervening pixels if |paint_switch=black|; then
+the |paint_switch| changes to the opposite state. \.{GF}'s commands are
+designed so that |m| will never decrease within a row, and |n| will never
+increase within a character; hence there is no way to whiten a pixel that
+has been blackened.
+
+@ Here is a list of all the commands that may appear in a \.{GF} file. Each
+command is specified by its symbolic name (e.g., |boc|), its opcode byte
+(e.g., 67), and its parameters (if any). The parameters are followed
+by a bracketed number telling how many bytes they occupy; for example,
+`|d[2]|' means that parameter |d| is two bytes long.
+
+\yskip\hang|paint_0| 0. This is a \\{paint} command with |d=0|; it does
+nothing but change the |paint_switch| from \\{black} to \\{white} or
+vice~versa.
+
+\yskip\hang\\{paint\_1} through \\{paint\_63} (opcodes 1 to 63).
+These are \\{paint} commands with |d=1| to~63, defined as follows: If
+|paint_switch=black|, blacken |d|~pixels of the current row~|n|,
+in columns |m| through |m+d-1| inclusive. Then, in any case,
+complement the |paint_switch| and advance |m| by~|d|.
+
+\yskip\hang|paint1| 64 |d[1]|. This is a \\{paint} command with a specified
+value of~|d|; \MF\ uses it to paint when |64<=d<256|.
+
+\yskip\hang|@!paint2| 65 |d[2]|. Same as |paint1|, but |d|~can be as high
+as~65535.
+
+\yskip\hang|@!paint3| 66 |d[3]|. Same as |paint1|, but |d|~can be as high
+as $2^{24}-1$. \MF\ never needs this command, and it is hard to imagine
+anybody making practical use of it; surely a more compact encoding will be
+desirable when characters can be this large. But the command is there,
+anyway, just in case.
+
+\yskip\hang|boc| 67 |c[4]| |p[4]| |min_m[4]| |max_m[4]| |min_n[4]|
+|max_n[4]|. Beginning of a character:  Here |c| is the character code, and
+|p| points to the previous character beginning (if any) for characters having
+this code number modulo 256.  (The pointer |p| is |-1| if there was no
+prior character with an equivalent code.) The values of registers |m| and |n|
+defined by the instructions that follow for this character must
+satisfy |min_m<=m<=max_m| and |min_n<=n<=max_n|.  (The values of |max_m| and
+|min_n| need not be the tightest bounds possible.)  When a \.{GF}-reading
+program sees a |boc|, it can use |min_m|, |max_m|, |min_n|, and |max_n| to
+initialize the bounds of an array. Then it sets |m:=min_m|, |n:=max_n|, and
+|paint_switch:=white|.
+
+\yskip\hang|boc1| 68 |c[1]| |@!del_m[1]| |max_m[1]| |@!del_n[1]| |max_n[1]|.
+Same as |boc|, but |p| is assumed to be~$-1$; also |del_m=max_m-min_m|
+and |del_n=max_n-min_n| are given instead of |min_m| and |min_n|.
+The one-byte parameters must be between 0 and 255, inclusive.
+\ (This abbreviated |boc| saves 19~bytes per character, in common cases.)
+
+\yskip\hang|eoc| 69. End of character: All pixels blackened so far
+constitute the pattern for this character. In particular, a completely
+blank character might have |eoc| immediately following |boc|.
+
+\yskip\hang|skip0| 70. Decrease |n| by 1 and set |m:=min_m|,
+|paint_switch:=white|. \ (This finishes one row and begins another,
+ready to whiten the leftmost pixel in the new row.)
+
+\yskip\hang|skip1| 71 |d[1]|. Decrease |n| by |d+1|, set |m:=min_m|, and set
+|paint_switch:=white|. This is a way to produce |d| all-white rows.
+
+\yskip\hang|@!skip2| 72 |d[2]|. Same as |skip1|, but |d| can be as large
+as 65535.
+
+\yskip\hang|@!skip3| 73 |d[3]|. Same as |skip1|, but |d| can be as large
+as $2^{24}-1$. \MF\ obviously never needs this command.
+
+\yskip\hang|new_row_0| 74. Decrease |n| by 1 and set |m:=min_m|,
+|paint_switch:=black|. \ (This finishes one row and begins another,
+ready to {\sl blacken\/} the leftmost pixel in the new row.)
+
+\yskip\hang|@!new_row_1| through |@!new_row_164| (opcodes 75 to 238). Same as
+|new_row_0|, but with |m:=min_m+1| through |min_m+164|, respectively.
+
+\yskip\hang|xxx1| 239 |k[1]| |x[k]|. This command is undefined in
+general; it functions as a $(k+2)$-byte |no_op| unless special \.{GF}-reading
+programs are being used. \MF\ generates \\{xxx} commands when encountering
+a \&{special} string; this occurs in the \.{GF} file only between
+characters, after the preamble, and before the postamble. However,
+\\{xxx} commands might appear anywhere in \.{GF} files generated by other
+processors. It is recommended that |x| be a string having the form of a
+keyword followed by possible parameters relevant to that keyword.
+
+\yskip\hang|@!xxx2| 240 |k[2]| |x[k]|. Like |xxx1|, but |0<=k<65536|.
+
+\yskip\hang|xxx3| 241 |k[3]| |x[k]|. Like |xxx1|, but |0<=k<@t$2^{24}$@>|.
+\MF\ uses this when sending a \&{special} string whose length exceeds~255.
+
+\yskip\hang|@!xxx4| 242 |k[4]| |x[k]|. Like |xxx1|, but |k| can be
+ridiculously large; |k| mustn't be negative.
+
+\yskip\hang|yyy| 243 |y[4]|. This command is undefined in general;
+it functions as a 5-byte |no_op| unless special \.{GF}-reading programs
+are being used. \MF\ puts |scaled| numbers into |yyy|'s, as a
+result of \&{numspecial} commands; the intent is to provide numeric
+parameters to \\{xxx} commands that immediately precede.
+
+\yskip\hang|no_op| 244. No operation, do nothing. Any number of |no_op|'s
+may occur between \.{GF} commands, but a |no_op| cannot be inserted between
+a command and its parameters or between two parameters.
+
+\yskip\hang|char_loc| 245 |c[1]| |dx[4]| |dy[4]| |w[4]| |p[4]|.
+This command will appear only in the postamble, which will be explained
+shortly.
+
+\yskip\hang|@!char_loc0| 246 |c[1]| |@!dm[1]| |w[4]| |p[4]|.
+Same as |char_loc|, except that |dy| is assumed to be zero, and the value
+of~|dx| is taken to be |65536*dm|, where |0<=dm<256|.
+
+\yskip\hang|pre| 247 |i[1]| |k[1]| |x[k]|.
+Beginning of the preamble; this must come at the very beginning of the
+file. Parameter |i| is an identifying number for \.{GF} format, currently
+131. The other information is merely commentary; it is not given
+special interpretation like \\{xxx} commands are. (Note that \\{xxx}
+commands may immediately follow the preamble, before the first |boc|.)
+
+\yskip\hang|post| 248. Beginning of the postamble, see below.
+
+\yskip\hang|post_post| 249. Ending of the postamble, see below.
+
+\yskip\noindent Commands 250--255 are undefined at the present time.
+
+@d gf_id_byte=131 {identifies the kind of \.{GF} files described here}
+
+@ Here are the opcodes that \.{GFtoPK} actually refers to.
+
+@d paint_0=0 {beginning of the \\{paint} commands}
+@d paint1=64 {move right a given number of columns, then
+  black${}\leftrightarrow{}$white}
+@d boc=67 {beginning of a character}
+@d boc1=68 {abbreviated |boc|}
+@d eoc=69 {end of a character}
+@d skip0=70 {skip no blank rows}
+@d skip1=71 {skip over blank rows}
+@d new_row_0=74 {move down one row and then right}
+@d max_new_row=238 {move down one row and then right}
+@d no_op=247 {noop}
+@d xxx1=239 {for \&{special} strings}
+@d yyy=243 {for \&{numspecial} numbers}
+@d nop=244 {no operation}
+@d char_loc=245 {character locators in the postamble}
+@d char_loc0=246 {character locators in the postamble}
+@d pre=247 {preamble}
+@d post=248 {postamble beginning}
+@d post_post=249 {postamble ending}
+@d undefined_commands==250,251,252,253,254,255
+
+@ The last character in a \.{GF} file is followed by `|post|'; this command
+introduces the postamble, which summarizes important facts that \MF\ has
+accumulated. The postamble has the form
+$$\vbox{\halign{\hbox{#\hfil}\cr
+  |post| |p[4]| |@!ds[4]| |@!cs[4]| |@!hppp[4]| |@!vppp[4]|
+   |@!min_m[4]| |@!max_m[4]| |@!min_n[4]| |@!max_n[4]|\cr
+  $\langle\,$character locators$\,\rangle$\cr
+  |post_post| |q[4]| |i[1]| 223's$[{\G}4]$\cr}}$$
+Here |p| is a pointer to the byte following the final |eoc| in the file
+(or to the byte following the preamble, if there are no characters);
+it can be used to locate the beginning of \\{xxx} commands
+that might have preceded the postamble. The |ds| and |cs| parameters
+@^design size@> @^check sum@>
+give the design size and check sum, respectively, which are exactly the
+values put into the header of any \.{TFM} file that shares information with
+this \.{GF} file. Parameters |hppp| and |vppp| are the ratios of
+pixels per point, horizontally and vertically, expressed as |scaled| integers
+(i.e., multiplied by $2^{16}$); they can be used to correlate the font
+with specific device resolutions, magnifications, and ``at sizes.''  Then
+come |min_m|, |max_m|, |min_n|, and |max_n|, which bound the values that
+registers |m| and~|n| assume in all characters in this \.{GF} file.
+(These bounds need not be the best possible; |max_m| and |min_n| may, on the
+other hand, be tighter than the similar bounds in |boc| commands. For
+example, some character may have |min_n=-100| in its |boc|, but it might
+turn out that |n| never gets lower than |-50| in any character; then
+|min_n| can have any value |<=-50|. If there are no characters in the file,
+it's possible to have |min_m>max_m| and/or |min_n>max_n|.)
+
+@ Character locators are introduced by |char_loc| commands,
+which specify a character residue~|c|, character escapements (|dx,dy|),
+a character width~|w|, and a pointer~|p|
+to the beginning of that character. (If two or more characters have the
+same code~|c| modulo 256, only the last will be indicated; the others can be
+located by following backpointers. Characters whose codes differ by a
+multiple of 256 are assumed to share the same font metric information,
+hence the \.{TFM} file contains only residues of character codes modulo~256.
+This convention is intended for oriental languages, when there are many
+character shapes but few distinct widths.)
+@^oriental characters@>@^Chinese characters@>@^Japanese characters@>
+
+The character escapements (|dx,dy|) are the values of \MF's \&{chardx}
+and \&{chardy} parameters; they are in units of |scaled| pixels;
+i.e., |dx| is in horizontal pixel units times $2^{16}$, and |dy| is in
+vertical pixel units times $2^{16}$.  This is the intended amount of
+displacement after typesetting the character; for \.{DVI} files, |dy|
+should be zero, but other document file formats allow nonzero vertical
+escapement.
+
+The character width~|w| duplicates the information in the \.{TFM} file; it
+is $2^{24}$ times the ratio of the true width to the font's design size.
+
+The backpointer |p| points to the character's |boc|, or to the first of
+a sequence of consecutive \\{xxx} or |yyy| or |no_op| commands that
+immediately precede the |boc|, if such commands exist; such ``special''
+commands essentially belong to the characters, while the special commands
+after the final character belong to the postamble (i.e., to the font
+as a whole). This convention about |p| applies also to the backpointers
+in |boc| commands, even though it wasn't explained in the description
+of~|boc|. @^backpointers@>
+
+Pointer |p| might be |-1| if the character exists in the \.{TFM} file
+but not in the \.{GF} file. This unusual situation can arise in \MF\ output
+if the user had |proofing<0| when the character was being shipped out,
+but then made |proofing>=0| in order to get a \.{GF} file.
+
+@ The last part of the postamble, following the |post_post| byte that
+signifies the end of the character locators, contains |q|, a pointer to the
+|post| command that started the postamble.  An identification byte, |i|,
+comes next; this currently equals~131, as in the preamble.
+
+The |i| byte is followed by four or more bytes that are all equal to
+the decimal number 223 (i.e., @'337 in octal). \MF\ puts out four to seven of
+these trailing bytes, until the total length of the file is a multiple of
+four bytes, since this works out best on machines that pack four bytes per
+word; but any number of 223's is allowed, as long as there are at least four
+of them. In effect, 223 is a sort of signature that is added at the very end.
+@^Fuchs, David Raymond@>
+
+This curious way to finish off a \.{GF} file makes it feasible for
+\.{GF}-reading programs to find the postamble first, on most computers,
+even though \MF\ wants to write the postamble last. Most operating
+systems permit random access to individual words or bytes of a file, so
+the \.{GF} reader can start at the end and skip backwards over the 223's
+until finding the identification byte. Then it can back up four bytes, read
+|q|, and move to byte |q| of the file. This byte should, of course,
+contain the value 248 (|post|); now the postamble can be read, so the
+\.{GF} reader can discover all the information needed for individual
+characters.
+
+Unfortunately, however, standard \PASCAL\ does not include the ability to
+@^system dependencies@>
+access a random position in a file, or even to determine the length of a file.
+Almost all systems nowadays provide the necessary capabilities, so \.{GF}
+format has been designed to work most efficiently with modern operating
+systems.  \.{GFtoPK} first reads the postamble, and then scans the file from
+front to back.
+
+@* Packed file format.
+The packed file format is a compact representation of the data contained in a
+\.{GF} file.  The information content is the same, but packed (\.{PK}) files
+are almost always less than half the size of their \.{GF} counterparts.  They
+are also easier to convert into a raster representation because they do not
+have a profusion of \\{paint}, \\{skip}, and \\{new\_row} commands to be
+separately interpreted.  In addition, the \.{PK} format expressedly forbids
+\&{special} commands within a character.  The minimum bounding box for each
+character is explicit in the format, and does not need to be scanned for as in
+the \.{GF} format.  Finally, the width and escapement values are combined with
+the raster information into character ``packets'', making it simpler in many
+cases to process a character.
+
+A \.{PK} file is organized as a stream of 8-bit bytes.  At times, these bytes
+might be split into 4-bit nybbles or single bits, or combined into multiple
+byte parameters.  When bytes are split into smaller pieces, the `first' piece
+is always the most significant of the byte.  For instance, the first bit of
+a byte is the bit with value 128; the first nybble can be found by dividing
+a byte by 16.  Similarly, when bytes are combined into multiple byte
+parameters, the first byte is the most significant of the parameter.  If the
+parameter is signed, it is represented by two's-complement notation.
+
+The set of possible eight-bit values are separated into two sets, those that
+introduce a character definition, and those that do not.  The values that
+introduce a character definition comprise the range from 0 to 239; byte values
+above 239 are interpreted commands.  Bytes which introduce character
+definitions are called flag bytes, and various fields within the byte indicate
+various things about how the character definition is encoded.  Command bytes
+have zero or more parameters, and can never appear within a character
+definition or between parameters of another command, where they would be
+interpeted as data.
+
+A \.{PK} file consists of a preamble, followed by a sequence of one or more
+character definitions, followed by a postamble.  The preamble command must
+be the first byte in the file, followed immediately by its parameters.
+Any number of character definitions may follow, and any command but the
+preamble command and the postamble command may occur between character
+definitions.  The very last command in the file must be the postamble.
+
+@ The packed file format is intended to be easy to read and interpret by
+device drivers.  The small size of the file reduces the input/output overhead
+each time a font is defined.  For those drivers that load and save each font
+file into memory, the small size also helps reduce the memory requirements.
+The length of each character packet is specified, allowing the character raster
+data to be loaded into memory by simply counting bytes, rather than
+interpreting each command; then, each character can be interpreted on a demand
+basis.  This also makes it possible for a driver to skip a particular
+character quickly if it knows that the character is unused.
+
+@ First, the command bytes shall be presented; then the format of the
+character definitions will be defined.  Eight of the possible sixteen
+commands (values 240 through 255) are currently defined; the others are
+reserved for future extensions.  The commands are listed below.  Each command
+is specified by its symbolic name (e.g., \\{pk\_no\_op}), its opcode byte,
+and any parameters.  The parameters are followed by a bracketed number
+telling how many bytes they occupy, with the number preceded by a plus sign if
+it is a signed quantity.  (Four byte quantities are always signed, however.)
+
+\yskip\hang|pk_xxx1| 240 |k[1]| |x[k]|.  This command is undefined in general;
+it functions as a $(k+2)$-byte \\{no\_op} unless special \.{PK}-reading
+programs are being used.  \MF\ generates \\{xxx} commands when encountering
+a \&{special} string.  It is recommended that |x| be a string having the form
+of a keyword followed by possible parameters relevant to that keyword.
+
+\yskip\hang\\{pk\_xxx2} 241 |k[2]| |x[k]|.  Like |pk_xxx1|, but |0<=k<65536|.
+
+\yskip\hang\\{pk\_xxx3} 242 |k[3]| |x[k]|.  Like |pk_xxx1|, but
+|0<=k<@t$2^{24}$@>|.  \MF\ uses this when sending a \&{special} string whose
+length exceeds~255.
+
+\yskip\hang\\{pk\_xxx4} 243 |k[4]| |x[k]|.  Like |pk_xxx1|, but |k| can be
+ridiculously large; |k| musn't be negative.
+
+\yskip\hang|pk_yyy| 244 |y[4]|.  This command is undefined in general; it
+functions as a five-byte \\{no\_op} unless special \.{PK} reading programs
+are being used.  \MF\ puts |scaled| numbers into |yyy|'s, as a result of
+\&{numspecial} commands; the intent is to provide numeric parameters to
+\\{xxx} commands that immediately precede.
+
+\yskip\hang|pk_post| 245.  Beginning of the postamble.  This command is
+followed by enough |pk_no_op| commands to make the file a multiple
+of four bytes long.  Zero through three bytes are usual, but any number
+is allowed.
+This should make the file easy to read on machines which pack four bytes to
+a word.
+
+\yskip\hang|pk_no_op| 246.  No operation, do nothing.  Any number of
+|pk_no_op|'s may appear between \.{PK} commands, but a |pk_no_op| cannot be
+inserted between a command and its parameters, between two parameters, or
+inside a character definition.
+
+\yskip\hang|pk_pre| 247 |i[1]| |k[1]| |x[k]| |ds[4]| |cs[4]| |hppp[4]|
+|vppp[4]|.  Preamble command.  Here, |i| is the identification byte of the
+file, currently equal to 89.  The string |x| is merely a comment, usually
+indicating the source of the \.{PK} file.  The parameters |ds| and |cs| are
+the design size of the file in $1/2^{20}$ points, and the checksum of the
+file, respectively.  The checksum should match the \.{TFM} file and the
+\.{GF} files for this font.  Parameters |hppp| and |vppp| are the ratios
+of pixels per point, horizontally and vertically, multiplied by $2^{16}$; they
+can be used to correlate the font with specific device resolutions,
+magnifications, and ``at sizes''.  Usually, the name of the \.{PK} file is
+formed by concatenating the font name (e.g., cmr10) with the resolution at
+which the font is prepared in pixels per inch multiplied by the magnification
+factor, and the letters \.{PK}.  For instance, cmr10 at 300 dots per inch
+should be named CMR10.300PK; at one thousand dots per inch and magstephalf,
+it should be named CMR10.1095PK.
+
+@ We put a few of the above opcodes into definitions for symbolic use by
+this program.
+
+@d pk_id = 89 {the version of \.{PK} file described}
+@d pk_xxx1 = 240 {\&{special} commands}
+@d pk_yyy = 244 {\&{numspecial} commands}
+@d pk_post = 245 {postamble}
+@d pk_no_op = 246 {no operation}
+@d pk_pre = 247 {preamble}
+
+@ The \.{PK} format has two conflicting goals; to pack character raster and
+size information as compactly as possible, while retaining ease of translation
+into raster and other forms.  A suitable compromise was found in the use of
+run-encoding of the raster information.  Instead of packing the individual
+bits of the character, we instead count the number of consecutive `black' or
+`white' pixels in a horizontal raster row, and then encode this number.  Run
+counts are found for each row, from the top of the character to the bottom.
+This is essentially the way the \.{GF} format works.
+Instead of presenting each row individually, however, let us concatenate all
+of the horizontal raster rows into one long string of pixels, and encode this
+row.  With knowledge of the width of the bit-map, the original character glyph
+can be easily reconstructed.  In addition, we do not need special commands to
+mark the end of one row and the beginning of the next.
+
+Next, let us put the burden of finding the minimum bounding box on the part
+of the font generator, since the characters will usually be used much more
+often than they are generated.  The minimum bounding box is the smallest
+rectangle which encloses all `black' pixels of a character.  Let us also
+eliminate the need for a special end of character marker, by supplying
+exactly as many bits as are required to fill the minimum bounding box, from
+which the end of the character is implicit.
+
+Let us next consider the distribution of the run counts.  Analysis of several
+dozen pixel files at 300 dots per inch yields a distribution peaking at four,
+falling off slowly until ten, then a bit more steeply until twenty, and then
+asymptotically approaching the horizontal.  Thus, the great majority of our
+run counts will fit in a four-bit nybble.  The eight-bit byte is attractive for
+our run-counts, as it is the standard on many systems; however, the wasted four
+bits in the majority of cases seems a high price to pay.  Another possibility
+is to use a Huffman-type encoding scheme with a variable number of bits for
+each run-count; this was rejected because of the overhead in fetching and
+examining individual bits in the file.  Thus, the character raster definitions
+in the \.{PK} file format are based on the four-bit nybble.
+
+@ The analysis of the pixel files yielded another interesting statistic: fully
+37\char`\%\
+of the raster rows were duplicates of the previous row.  Thus, the \.{PK}
+format allows the specification of repeat counts, which indicate how many times
+a horizontal raster row is to be repeated.  These repeated rows are taken out
+of the character glyph before individual rows are concatenated into the long
+string of pixels.
+
+For elegance, we disallow a run count of zero.  The case of a null raster
+description should be gleaned from the character width and height being equal
+to zero, and no raster data should be read.  No other zero counts are ever
+necessary.  Also, in the absence of repeat counts, the repeat value is set to
+be zero (only the original row is sent.)  If a repeat count is seen, it takes
+effect on the current row.  The current row is defined as the row on which the
+first pixel of the next run count will lie.  The repeat count is set back to
+zero when the last pixel in the current row is seen, and the row is sent out.
+
+This poses a problem for entirely black and entirely white rows, however.  Let
+us say that the current row ends with four white pixels, and then we have five
+entirely empty rows, followed by a black pixel at the beginning of the next
+row, and the character width is ten pixels.  We would like to use a repeat
+count, but there is no legal place to put it.  If we put it before the white
+run count, it will apply to the current row.  If we put it after, it applies
+to the row with the black pixel at the beginning.  Thus, entirely white or
+entirely black repeated rows are always packed as large run counts (in this
+case, a white run count of 54) rather than repeat counts.
+
+@ Now let us turn our attention to the actual packing of the run counts and
+repeat counts into nybbles.  There are only sixteen possible nybble values.
+We need to indicate run counts and repeat counts.  Since the run counts are
+much more common, we will devote the majority of the nybble values to them.
+We therefore indicate a repeat count by a nybble of 14 followed by a packed
+number, where a packed number will be explained later.  Since the repeat
+count value of one is so common, we indicate a repeat one command by a single
+nybble of 15.  A 14 followed by the packed number 1 is still legal for a
+repeat one count, however.  The run counts are coded directly as packed
+numbers.
+
+For packed numbers, therefore, we have the nybble values 0 through 13.  We
+need to represent the positive integers up to, say, $2^{31}-1$.  We would
+like the more common smaller numbers to take only one or two nybbles, and
+the infrequent large numbers to take three or more.  We could therefore
+allocate one nybble value to indicate a large run count taking three or more
+nybbles.  We do this with the value 0.
+
+@ We are left with the values 1 through 13.  We can allocate some of these, say
+|dyn_f|, to be one-nybble run counts.
+These will work for the run counts |1..dyn_f|.  For subsequent run
+counts, we will use a nybble greater than |dyn_f|, followed by a second nybble,
+whose value can run from 0 through 15.  Thus, the two-byte nybble values will
+run from |dyn_f+1..(13-dyn_f)*16+dyn_f|.  We have our definition of large run
+count values now, being all counts greater than |(13-dyn_f)*16+dyn_f|.
+
+We can analyze our several dozen pixel files and determine an optimal value of
+|dyn_f|, and use this value for all of the characters.  Unfortunately, values
+of |dyn_f| that pack small characters well tend to pack the large characters
+poorly, and values that pack large characters well are not efficient for the
+smaller characters.  Thus, we choose the optimal |dyn_f| on a character basis,
+picking the value which will pack each individual character in the smallest
+number of nybbles.  Legal values of |dyn_f| run from 0 (with no one-byte run
+counts) to 13 (with no two-byte run counts).
+
+@ Our only remaining task in the coding of packed numbers is the large run
+counts.  We use a scheme suggested by D.~E.~Knuth
+@^Knuth, D.~E.@>
+which will simply and elegantly represent arbitrarily large values.  The
+general scheme to represent an integer |i| is to write its hexadecimal
+representation, with leading zeros removed.  Then we count the number of
+digits, and prepend one less than that many zeros before the hexadecimal
+representation.  Thus, the values from one to fifteen occupy one nybble;
+the values sixteen through 255 occupy three, the values 256 through 4095
+require five, etc.
+
+For our purposes, however, we have already represented the numbers one
+through |(13-dyn_f)*16+dyn_f|.  In addition, the one-nybble values have
+already been taken by our other commands, which means that only the values
+from sixteen up are available to us for long run counts.  Thus, we simply
+normalize our long run counts, by subtracting |(13-dyn_f)*16+dyn_f+1| and
+adding 16, and then representing the result according to the scheme above.
+
+@ The final algorithm for decoding the run counts based on the above scheme
+might look like this, assuming a procedure called \\{pk\_nyb} is available
+to get the next nybble from the file, and assuming that the global
+|repeat_count| indicates whether a row needs to be repeated.  Note that this
+routine is recursive, but since a repeat count can never directly follow
+another repeat count, it can only be recursive to one level.
+
+@<Packed number procedure@>=
+function pk_packed_num : integer ;
+var i, j, k : integer ;
+begin
+   i := get_nyb ;
+   if i = 0 then begin
+      repeat j := get_nyb ; incr(i) ; until j <> 0 ;
+      while i > 0 do begin j := j * 16 + get_nyb ; decr(i) ; end ;
+      pk_packed_num := j - 15 + (13-dyn_f)*16 + dyn_f ;
+   end else if i <= dyn_f then
+      pk_packed_num := i
+   else if i < 14 then
+      pk_packed_num := (i-dyn_f-1)*16+get_nyb+dyn_f+1
+   else begin
+      if i = 14 then
+         repeat_count := pk_packed_num
+      else
+         repeat_count := 1 ;
+      pk_packed_num := pk_packed_num ;
+   end ;
+end ;
+
+@ For low resolution fonts, or characters with `gray' areas, run encoding can
+often make the character many times larger.  Therefore, for those characters
+that cannot be encoded efficiently with run counts, the \.{PK} format allows
+bit-mapping of the characters.  This is indicated by a |dyn_f| value of
+14.  The bits are packed tightly, by concatenating all of the horizontal raster
+rows into one long string, and then packing this string eight bits to a byte.
+The number of bytes required can be calculated by |(width*height+7) div 8|.
+This format should only be used when packing the character by run counts takes
+more bytes than this, although, of course, it is legal for any character.
+Any extra bits in the last byte should be set to zero.
+
+@ At this point, we are ready to introduce the format for a character
+descripter.  It consists of three parts: a flag byte, a character preamble,
+and the raster data.  The most significant four bits of the flag byte
+yield the |dyn_f| value for that character.  (Notice that only values of
+0 through 14 are legal for |dyn_f|, with 14 indicating a bit mapped character;
+thus, the flag bytes do not conflict with the command bytes, whose upper nybble
+is always 15.)  The next bit (with weight 8) indicates whether the first run
+count is a black count or a white count, with a one indicating a black count.
+For bit-mapped characters, this bit should be set to a zero.  The next bit
+(with weight 4) indicates whether certain later parameters (referred to as size
+parameters) are given in one-byte or two-byte quantities, with a one indicating
+that they are in two-byte quantities.  The last two bits are concatenated on to
+the beginning of the length parameter in the character preamble, which will be
+explained below.
+
+However, if the last three bits of the flag byte are all set (normally
+indicating that the size parameters are two-byte values and that a 3 should be
+prepended to the length parameter), then a long format of the character
+preamble should be used instead of one of the short forms.
+
+Therefore, there are three formats for the character preamble, and which one
+is used depends on the least significant three bits of the flag byte.  If the
+least significant three bits are in the range zero through three, the short
+format is used.  If they are in the range four through six, the extended short
+format is used.  Otherwise, if the least significant bits are all set, then
+the long form of the character preamble is used.  The preamble formats are
+explained below.
+
+\yskip\hang Short form: |flag[1]| |pl[1]| |cc[1]| |tfm[3]| |dm[1]| |w[1]|
+|h[1]| |hoff[+1]| |voff[+1]|.
+If this format of the character preamble is used, the above
+parameters must all fit in the indicated number of bytes, signed or unsigned
+as indicated.  Almost all of the standard \TeX\ font characters fit; the few
+exceptions are fonts such as \.{aminch}.
+
+\yskip\hang Extended short form: |flag[1]| |pl[2]| |cc[1]| |tfm[3]| |dm[2]|
+|w[2]| |h[2]| |hoff[+2]| |voff[+2]|.  Larger characters use this extended
+format.
+
+\yskip\hang Long form: |flag[1]| |pl[4]| |cc[4]| |tfm[4]| |dx[4]| |dy[4]|
+|w[4]| |h[4]| |hoff[4]| |voff[4]|.  This is the general format which
+allows all of the
+parameters of the \.{GF} file format, including vertical escapement.
+\vskip\baselineskip
+The |flag| parameter is the flag byte.  The parameter |pl| (packet length)
+contains the offset
+of the byte following this character descripter, with respect to the beginning
+of the |tfm| width parameter.  This is given so a \.{PK} reading program can,
+once it has read the flag byte, packet length, and character code (|cc|), skip
+over the character by simply reading this many more bytes.  For the two short
+forms of the character preamble, the last two bits of the flag byte should be
+considered the two most-significant bits of the packet length.  For the short
+format, the true packet length might be calculated as |(flag mod 4)*256+pl|;
+for the extended format, it might be calculated as |(flag mod 4)*65536+pl|.
+
+The |w| parameter is the width and the |h| parameter is the height in pixels
+of the minimum bounding box.  The |dx| and |dy| parameters are the horizontal
+and vertical escapements, respectively.  In the short formats, |dy| is assumed
+to be zero and |dm| is |dy| but in pixels;
+in the long format, |dx| and |dy| are both
+in pixels multiplied by $2^{16}$.  The |hoff| is the horizontal offset from the
+upper left pixel to the reference pixel; the |voff| is the vertical offset.
+They are both given in pixels, with right and down being positive.  The
+reference pixel is the pixel which occupies the unit square in \MF; the
+\MF\ reference point is the lower left hand corner of this pixel.  (See the
+example below.)
+
+@ \TeX\ requires that all characters which have the same character codes
+modulo 256 also have the same |tfm| widths, and escapement values.  The \.{PK}
+format does not itself make this a requirement, but in order for the font to
+work correctly with the \TeX\ software, this constraint should be observed.
+
+
+Following the character preamble is the raster information for the
+character, packed by run counts or by bits, as indicated by the flag byte.
+If the character is packed by run counts and the required number of nybbles
+is odd, then the last byte of the raster description should have a zero
+for its least significant nybble.
+
+@ As an illustration of the \.{PK} format, the character \char4\ from the font
+amr10 at 300 dots per inch will be encoded.  (Note: amr fonts are obsolete,
+and the reference to this character is retained from an older version of
+the Computer Modern fonts solely for illustration.) This character was chosen
+because it illustrates some
+of the borderline cases.  The raster for the character looks like this (the
+row numbers are chosen for convenience, and are not \MF's row numbers.)
+
+\vskip\baselineskip
+\centerline{\vbox{\baselineskip=10pt
+\halign{\hfil#\quad&&\hfil#\hfil\cr
+0& & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M\cr
+1& & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M\cr
+2& & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M\cr
+3& & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M\cr
+4& & &M&M& & & & & & & & & & & & & & & & &M&M\cr
+5& & &M&M& & & & & & & & & & & & & & & & &M&M\cr
+6& & &M&M& & & & & & & & & & & & & & & & &M&M\cr
+7\cr
+8\cr
+9& & & & &M&M& & & & & & & & & & & & &M&M& & \cr
+10& & & & &M&M& & & & & & & & & & & & &M&M& & \cr
+11& & & & &M&M& & & & & & & & & & & & &M&M& & \cr
+12& & & & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M& & \cr
+13& & & & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M& & \cr
+14& & & & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M& & \cr
+15& & & & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M& & \cr
+16& & & & &M&M& & & & & & & & & & & & &M&M& & \cr
+17& & & & &M&M& & & & & & & & & & & & &M&M& & \cr
+18& & & & &M&M& & & & & & & & & & & & &M&M& & \cr
+19\cr
+20\cr
+21\cr
+22& & &M&M& & & & & & & & & & & & & & & & &M&M\cr
+23& & &M&M& & & & & & & & & & & & & & & & &M&M\cr
+24& & &M&M& & & & & & & & & & & & & & & & &M&M\cr
+25& & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M\cr
+26& & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M\cr
+27& & &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M\cr
+28&*& &M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M&M\cr
+&\hphantom{M}&\hphantom{M}\cr
+}}}
+The width of the minimum bounding box for this character is 20; its height
+is 29.  The `*' represents the reference pixel; notice how it lies outside the
+minimum bounding box.  The |hoff| value is $-2$, and the |voff| is~28.
+
+The first task is to calculate the run counts and repeat counts.  The repeat
+counts are placed at the first transition (black to white or white to black)
+in a row, and are enclosed in brackets.  White counts are enclosed in
+parentheses.  It is relatively easy to generate the counts list:
+\vskip\baselineskip
+\centerline{82 [2] (16) 2 (42) [2] 2 (12) 2 (4) [3]}
+\centerline{16 (4) [2] 2 (12) 2 (62) [2] 2 (16) 82}
+\vskip\baselineskip
+Note that any duplicated rows that are not all white or all black are removed
+before the repeat counts are calculated.  The rows thus removed are rows 5, 6,
+10, 11, 13, 14, 15, 17, 18, 23, and 24.
+
+@ The next step in the encoding of this character is to calculate the optimal
+value of |dyn_f|.  The details of how this calculation is done are not
+important here; suffice it to say that there is a simple algorithm which in one
+pass over the count list can determine the best value of |dyn_f|.  For this
+character, the optimal value turns out to be 8 (atypically low).  Thus, all
+count values less than or equal to 8 are packed in one nybble; those from
+nine to $(13-8)*16+8$ or 88 are packed in two nybbles.  The run encoded values
+now become (in hex, separated according to the above list):
+\vskip\baselineskip
+\centerline{\tt D9 E2 97 2 B1 E2 2 93 2 4 E3}
+\centerline{\tt 97 4 E2 2 93 2 C5 E2 2 97 D9}
+\vskip\baselineskip\noindent
+which comes to 36 nybbles, or 18 bytes.  This is shorter than the 73 bytes
+required for the bit map, so we use the run count packing.
+
+@ The short form of the character preamble is used because all of the
+parameters fit in their respective lengths.  The packet length is therefore
+18 bytes for the raster, plus
+eight bytes for the character preamble parameters following the character
+code, or 26.  The |tfm| width for this character is 640796, or {\tt 9C71C} in
+hexadecimal.  The horizontal escapement is 25 pixels.  The flag byte is
+88 hex, indicating the short preamble, the black first count, and the
+|dyn_f| value of 8.  The final total character packet, in hexadecimal, is:
+\vskip\baselineskip
+$$\vbox{\halign{\hfil #\quad&&{\tt #\ }\cr
+Flag byte&88\cr
+Packet length&1A\cr
+Character code&04\cr
+|tfm| width&09&C7&1C\cr
+Horizontal escapement (pixels)&19\cr
+Width of bit map&14\cr
+Height of bit map&1D\cr
+Horizontal offset (signed)&FE\cr
+Vertical offset&1C\cr
+Raster data&D9&E2&97\cr
+&2B&1E&22\cr
+&93&24&E3\cr
+&97&4E&22\cr
+&93&2C&5E\cr
+&22&97&D9\cr}}$$
+
+@ This format was written by Tomas Rokicki in August, 1985.
+
+@* Input and output.
+There are two types of files that this program must deal with---standard
+text files and files of bytes (packed files and generic font files.)
+For our purposes, we shall consider an eight-bit byte to consist of the
+values |0..255|.  If your system does not pack these values to a byte, it is
+no major difficulty; you must only insure that the input function
+|pk_byte| can read packed bytes, and that the output fuunction |gf_byte|
+packs the bytes to be shipped.
+
+@<Types...@>=
+@!eight_bits=0..255; {packed file byte}
+@!byte_file=packed file of eight_bits ; {for packed file words}
+@^system dependancies@>
+
+@ @<Glob...@>=
+@!gf_file,@!pk_file:byte_file;  {the I/O streams}
+@^system dependencies@>
+
+@ To prepare these files for input, we |reset| them. An extension of
+\PASCAL\ is needed in the case of |gf_file|, since we want to associate
+it with external files whose names are specified dynamically (i.e., not
+known at compile time). The following code assumes that `|reset(f,s)|'
+does this, when |f| is a file variable and |s| is a string variable that
+specifies the file name. If |eof(f)| is true immediately after
+|reset(f,s)| has acted, we assume that no file named |s| is accessible.
+@^system dependencies@>
+
+@p procedure open_gf_file; {prepares to write packed bytes in a |gf_file|}
+begin rewrite(gf_file,gf_name);
+gf_loc := 0 ;
+end;
+@#
+procedure open_pk_file; {prepares the input for reading}
+begin reset(pk_file,pk_name);
+pk_loc := 0 ;
+end;
+
+@ We need a place to store the names of the input and output files, as well
+as a byte counter for the output file.
+
+@<Glob...@>=
+@!gf_name,@!pk_name:packed array[1..name_length] of char; {names of input
+    and output files}
+@!gf_loc, @!pk_loc:integer; {how many bytes have we sent?}
+
+@ We need a procedure that will write a byte to the \.{GF} file.  If the
+particular system
+@^system dependencies@>
+requires buffering, here is the place to do it.
+
+@p procedure gf_byte (i : integer) ;
+begin gf_file^ := i ;
+put(gf_file) ;
+incr(gf_loc) ;
+end;
+
+@ We also need a function that will get a single byte from the \.{PK} file.
+Again, buffering may be done in this procedure.
+
+@p function pk_byte : eight_bits ;
+var nybble, temp : eight_bits ;
+begin
+   temp := pk_file^ ;
+   get(pk_file) ;
+   pk_loc := pk_loc + 1 ;
+   pk_byte := temp ;
+end ;
+
+@ Now we are ready to open the files and write the identification of the
+pixel file.
+
+@<Open files@>=
+open_pk_file ;
+open_gf_file
+
+@ As we are reading the packed file, we often need to fetch 16 and 32 bit
+quantities.  Here we have two procedures to do this.
+
+@p function signed_byte : integer ;
+var a : integer ;
+begin
+   a := pk_byte ;
+   if a > 127 then
+      a := a - 256 ;
+   signed_byte := a ;
+end ;
+@#
+function get_16 : integer ;
+var a : integer ;
+begin
+   a := pk_byte ;
+   get_16 := a * 256 + pk_byte ; 
+end ;
+@#
+function signed_16 : integer ;
+var a : integer ;
+begin
+   a := signed_byte ;
+   signed_16 := a * 256 + pk_byte ;
+end ;
+@#
+function get_32 : integer ;
+var a : integer ;
+begin 
+   a := get_16 ; 
+   if a > 32767 then a := a - 65536 ;
+   get_32 := a * 65536 + get_16 ; 
+end ;
+
+@ As we are writing the \.{GF} file, we often need to write signed and
+unsigned, one, two, three, and four-byte values.  These routines give
+us that capability.
+
+@p procedure gf_sbyte(i : integer) ;
+begin
+   if i < 0 then
+      i := i + 256 ;
+   gf_byte(i) ;
+end ;
+@#
+procedure gf_16(i : integer) ;
+begin
+   gf_byte(i div 256) ;
+   gf_byte(i mod 256) ;
+end ;
+@#
+procedure  gf_24(i : integer) ;
+begin
+   gf_byte(i div 65536) ;
+   gf_16(i mod 65536) ;
+end ;
+@#
+procedure gf_quad(i : integer) ;
+begin
+   if i >= 0 then begin
+      gf_byte(i div 16777216) ;
+   end else begin
+      i := (i + 1073741824) + 1073741824 ;
+      gf_byte(128 + (i div 16777216)) ;
+   end ;
+   gf_24(i mod 16777216) ;
+end ;
+
+@* Character unpacking.
+Now we deal with unpacking characters into the \.{GF} representation.
+
+@<Unpack and write character@>=
+dyn_f := flag_byte div 16 ;
+flag_byte := flag_byte mod 16 ;
+turn_on := flag_byte >= 8 ;
+if turn_on then flag_byte := flag_byte - 8 ;
+if flag_byte = 7 then
+   @<Read long character preamble@>
+else if flag_byte > 3 then
+   @<Read extended short character preamble@>
+else
+   @<Read short character preamble@> ;
+@<Calculate and check |min_m|, |max_m|, |min_n|, and |max_n|@> ;
+@<Save character locator@> ;
+@<Write character preamble@> ;
+@<Read and translate raster description@> ;
+gf_byte(eoc) ;
+last_eoc := gf_loc ;
+if end_of_packet <> pk_loc then abort('Bad pk file!  Bad packet length.')
+
+@ We need a whole lot of globals used but not defined up there.
+
+@<Glob...@>=
+@!i, @!j : integer ; {index pointers}
+@!end_of_packet : integer ; {where we expect the end of the packet to be}
+@!dyn_f : integer ; {dynamic packing variable}
+@!car : integer ; {the character we are reading}
+@!tfm_width : integer ; {the TFM width of the current character}
+@!x_off, @!y_off : integer ; {the offsets for the character}
+
+@ Now we read and check the preamble of the \.{PK} file.  In the preamble, we
+find the |hppp|, |design_size|, |checksum|.  We write the relevant parameters
+to the \.{GF} file, including the preamble comment.
+
+@<Read preamble@>=
+if pk_byte <> pk_pre then abort('Bad pk file!  pre command missing.') ;
+gf_byte(pre) ;
+if pk_byte <> pk_id then abort('Wrong version of packed file!.') ;
+gf_byte(gf_id_byte) ;
+j := pk_byte ;
+for i := 1 to j do hppp := pk_byte ;
+gf_byte(comm_length) ;
+for i := 1 to comm_length do
+   gf_byte(xord[comment[i]]) ;
+design_size := get_32 ;
+checksum := get_32 ;
+hppp := get_32 ; vppp := get_32 ;
+if hppp <> vppp then print_ln('Warning:  aspect ratio not 1:1!') ;
+magnification := round(hppp * 72.27 * 5 / 65536) ;
+last_eoc := gf_loc
+
+@ Of course, we need to define the above variables.
+
+@<Glob...@>=
+@!comment : packed array[1..comm_length] of char ;
+@!magnification : integer ; {resolution at which pixel file is prepared}
+@!design_size : integer ; {design size in \.{FIXes}}
+@!checksum : integer ; {checksum of pixel file}
+@!hppp, @!vppp : integer ; {horizontal and vertical points per inch}
+
+@ @<Set init...@>=
+comment := preamble_comment ;
+
+@ Now, the character preamble reading modules.  First, we have the general
+case: the long character preamble format.
+
+@<Read long character preamble@>=
+begin
+   packet_length := get_32 ; car := get_32 ;
+   end_of_packet := packet_length + pk_loc ;
+   tfm_width := get_32 ;
+   hor_esc := get_32 ;
+   ver_esc := get_32 ;
+   c_width := get_32 ;
+   c_height := get_32 ;
+   word_width := (c_width + 31) div 32 ;
+   x_off := get_32 ;
+   y_off := get_32 ;
+end
+
+@ This module reads the character preamble with double byte parameters.
+
+@<Read extended short character preamble@>=
+begin
+   packet_length := (flag_byte - 4) * 65536 + get_16 ;
+   car := pk_byte ;
+   end_of_packet := packet_length + pk_loc ;
+   i := pk_byte ;
+   tfm_width := i * 65536 + get_16 ;
+   hor_esc := get_16 * 65536 ;
+   ver_esc := 0 ;
+   c_width := get_16 ;
+   c_height := get_16 ;
+   word_width := (c_width + 31) div 32 ;
+   x_off := signed_16 ;
+   y_off := signed_16 ;
+end
+
+@ Here we read the most common character preamble, that with single byte
+parameters.
+
+@<Read short character preamble@>=
+begin
+   packet_length := flag_byte * 256 + pk_byte ;
+   car := pk_byte ;
+   end_of_packet := packet_length + pk_loc ;
+   i := pk_byte ;
+   tfm_width := i * 65536 + get_16 ;
+   hor_esc := pk_byte * 65536 ;
+   ver_esc := 0 ;
+   c_width := pk_byte ;
+   c_height := pk_byte ;
+   word_width := (c_width + 31) div 32 ;
+   x_off := signed_byte ;
+   y_off := signed_byte ;
+end
+
+@ Some more globals:
+
+@<Glob...@>=
+@!c_height, @!c_width : integer ; {sizes of the character glyphs}
+@!word_width : integer ; {width of character in raster words}
+@!hor_esc, @!ver_esc : integer ; {the character escapement}
+@!packet_length : integer ; {the length of the packet in bytes}
+@!last_eoc : integer ; {the last end of character}
+
+@ The \.{GF} format requires the minimum and maximum |m| and |n|
+values in the postamble, so we generate them here.  One thing
+that should be noted, here.  The value |max_n-min_n| will be the
+height of the character glyph, but for the width, you need to
+use |max_m-min_m-1|, because of the peculiarities of the \.{GF}
+format.
+
+@<Calculate and check |min_m|, |max_m|, |min_n|, and |max_n|@>=
+if (c_height = 0) or (c_width = 0) then begin
+   c_height := 0 ; c_width := 0 ; x_off := 0 ; y_off := 0 ;
+end ;
+min_m := - x_off ;
+if min_m < mmin_m then
+   mmin_m := min_m ;
+max_m := c_width + min_m ;
+if max_m > mmax_m then
+   mmax_m := max_m ;
+min_n := y_off - c_height + 1 ;
+max_n := y_off ;
+if min_n > max_n then
+   min_n := max_n ;
+if min_n < mmin_n then
+   mmin_n := min_n ;
+if max_n > mmax_n then
+   mmax_n := max_n
+
+@ We have to declare the variables which hold the bounding box.  We
+also need the arrays that hold the back pointers to the characters,
+the horizontal and vertical escapements, and the \.{TFM} widths.
+
+@<Glob...@>=
+@!min_m, @!max_m, @!min_n, @!max_n : integer ;
+@!mmin_m, @!mmax_m, @!mmin_n, @!mmax_n : integer ;
+@!char_pointer, @!s_tfm_width : array [0..255] of integer ;
+@!s_hor_esc, @!s_ver_esc : array [0..255] of integer ;
+@!this_char_ptr : integer ; 
+
+@ We initialize these bounding box values to be ridiculous, and say
+that there were no characters seen yet.
+
+@<Set init...@>=
+mmin_m := 999999 ;
+mmin_n := 999999 ;
+mmax_m := -999999 ;
+mmax_n := -999999 ;
+for i := 0 to 255 do
+   char_pointer[i] := -1 ;
+
+@ This module takes care of the simple job of writing the character
+preamble, after picking one to fit.
+
+@<Write character preamble@>=
+begin
+   if (char_pointer[car mod 256] = -1) and
+      (car >= 0) and (car < 256) and
+      (max_m >= 0) and (max_m < 256) and
+      (max_n >= 0) and (max_n < 256) and
+      (max_m >= min_m) and (max_n >= min_n) and
+      (max_m < min_m + 256) and (max_n < min_n + 256) then begin
+      char_pointer[car mod 256] := this_char_ptr ;
+      gf_byte(boc1) ;
+      gf_byte(car) ;
+      gf_byte(max_m - min_m) ;
+      gf_byte(max_m) ;
+      gf_byte(max_n - min_n) ;
+      gf_byte(max_n) ;
+   end else begin
+      gf_byte(boc) ;
+      gf_quad(car) ;
+      gf_quad(char_pointer[car mod 256]) ;
+      char_pointer[car mod 256] := this_char_ptr ;
+      gf_quad(min_m) ;
+      gf_quad(max_m) ;
+      gf_quad(min_n) ;
+      gf_quad(max_n) ;
+   end ;
+end
+
+@ In this routine we either save or check the current character
+parameters.
+
+@<Save character locator@>=
+begin
+   i := car mod 256 ;
+   if (char_pointer[i] = -1) then begin
+      s_ver_esc[i] := ver_esc ;
+      s_hor_esc[i] := hor_esc ;
+      s_tfm_width[i] := tfm_width ;
+   end else begin
+      if (s_ver_esc[i] <> ver_esc) or
+         (s_hor_esc[i] <> hor_esc) or
+         (s_tfm_width[i] <> tfm_width) then
+         print_ln('Two characters mod ', i:1,' have mismatched parameters') ;
+   end ;
+end
+
+@ And another module to write out those character locators we have so
+carefully saved up the information for.
+
+@<Write character locators@>=
+for i := 0 to 255 do
+   if char_pointer[i] <> -1 then begin
+      if (s_ver_esc[i] = 0) and (s_hor_esc[i] >= 0) and
+         (s_hor_esc[i] < 16777216) and (s_hor_esc[i] mod 65536 = 0) then begin
+         gf_byte(char_loc0) ;
+         gf_byte(i) ;
+         gf_byte(s_hor_esc[i] div 65536) ;
+      end else begin
+         gf_byte(char_loc) ;
+         gf_byte(i) ;
+         gf_quad(s_hor_esc[i]) ;
+         gf_quad(s_ver_esc[i]) ;
+      end ;
+      gf_quad(s_tfm_width[i]) ;
+      gf_quad(char_pointer[i]) ;
+   end
+
+@ Now we have the most important part of the program, where we actually
+interpret the commands in the raster description.  First of all, we need
+a procedure to get a single nybble from the file, as well as one to get
+a single bit.  We also use the |pk_packed_num| procedure defined in the
+\.{PK} file description.
+
+@p function get_nyb : integer ;
+var temp : eight_bits ;
+begin
+   if bit_weight = 0 then begin
+      input_byte := pk_byte ;
+      bit_weight := 16 ;
+   end ;
+   temp := input_byte div bit_weight ;
+   input_byte := input_byte - temp * bit_weight ;
+   bit_weight := bit_weight div 16 ;
+   get_nyb := temp ;
+end ;
+@#
+function get_bit : boolean ;
+var temp : boolean ;
+begin
+   bit_weight := bit_weight div 2 ;
+   if bit_weight = 0 then begin
+      input_byte := pk_byte ;
+      bit_weight := 128 ;
+   end ;
+   temp := input_byte >= bit_weight ;
+   if temp then
+      input_byte := input_byte - bit_weight ;
+   get_bit := temp ;
+end ;
+@<Packed number procedure@>
+
+@ Now, the globals to help communication between these procedures, and a buffer
+for the raster row counts.
+
+@<Glob...@>=
+@!input_byte : eight_bits ; {the byte we are currently decimating}
+@!bit_weight : eight_bits ; {weight of the current bit}
+@!nybble : eight_bits ; {the current nybble}
+@!row_counts : array [0..max_counts] of integer ;
+     {where the row is constructed}
+@!rcp : integer ; { the row counts pointer }
+
+@ Actually, if the character is a bit mapped character, then we
+make it look like run counts by determining the appropriate
+values ourselves.  Thus, we have a routine which gets the next
+count value, below.
+
+@<Get next count value into |count|@>=
+begin
+   turn_on := not turn_on ;
+   if dyn_f = 14 then begin
+      count := 1 ;
+      done := false ;
+      while not done do begin
+         if count_down <= 0 then
+            done := true
+         else if (turn_on = get_bit) then
+            count := count + 1
+         else
+            done := true ;
+         count_down := count_down - 1 ;
+      end ;
+   end else
+      count := pk_packed_num ;
+end
+
+@ And the main procedure.
+
+@<Read and translate raster description@>=
+if (c_width > 0) and (c_height > 0) then begin
+   bit_weight := 0 ;
+   count_down := c_height * c_width - 1 ;
+   if dyn_f = 14 then
+      turn_on := get_bit ;
+   repeat_count := 0 ;
+   x_to_go := c_width ;
+   y_to_go := c_height ;
+   cur_n := c_height ;
+   count := 0 ;
+   first_on := turn_on ;
+   turn_on := not turn_on ;
+   rcp := 0 ;
+   while y_to_go > 0 do begin
+      if count = 0 then
+         @<Get next count...@> ;
+      if rcp = 0 then
+         first_on := turn_on ;
+      while count >= x_to_go do begin
+         row_counts[rcp] := x_to_go ;
+         count := count - x_to_go ;
+         for i := 0 to repeat_count do begin
+            @<Output row@> ;
+            y_to_go := y_to_go - 1 ;
+         end ;
+         repeat_count := 0 ;
+         x_to_go := c_width ;
+         rcp := 0 ;
+         if (count > 0) then
+            first_on := turn_on ;
+      end ;
+      if count > 0 then begin
+         row_counts[rcp] := count ;
+         if rcp = 0 then
+            first_on := turn_on ;
+         rcp := rcp + 1 ;
+         if rcp > max_counts then begin
+            print_ln('A character had too many run counts') ;
+            jump_out ;
+         end ;
+         x_to_go := x_to_go - count ;
+         count := 0 ;
+      end ;
+   end ;
+end
+
+@ This routine actually outputs a row to the \.{GF} file.
+
+@<Output row@>=
+if (rcp > 0) or first_on then begin
+   j := 0 ;
+   max := rcp ;
+   if not turn_on then
+      max := max - 1 ;
+   if cur_n - y_to_go = 1 then begin
+      if first_on then
+         gf_byte(new_row_0)
+      else if row_counts[0] < 165 then begin
+         gf_byte(new_row_0 + row_counts[0]) ;
+         j := j + 1 ;
+      end else
+         gf_byte(skip0) ;
+   end else if cur_n > y_to_go then begin
+      if cur_n - y_to_go < 257 then begin
+         gf_byte(skip1) ;
+         gf_byte(cur_n - y_to_go - 1) ;
+      end else begin
+         gf_byte(skip1+1) ;
+         gf_16(cur_n - y_to_go - 1) ;
+      end ;
+      if first_on then
+         gf_byte(paint_0) ;
+   end else if first_on then
+      gf_byte(paint_0) ;
+   cur_n := y_to_go ;
+   while j <= max do begin
+      if row_counts[j] < 64 then
+         gf_byte(paint_0 + row_counts[j])
+      else if row_counts[j] < 256 then begin
+         gf_byte(paint1) ;
+         gf_byte(row_counts[j]) ;
+      end else begin
+         gf_byte(paint1+1) ;
+         gf_16(row_counts[j]) ;
+      end ;
+      j := j + 1 ;
+   end ;
+end
+
+@ Here we need the array which counts down the number of bits, and
+the current state flag.
+
+@<Glob...@>=
+@!count_down : integer ; { have we run out of bits yet? }
+@!done : boolean ; { are we done yet? }
+@!max : integer ; { the maximum number of counts to output }
+@!repeat_count : integer ; {how many times to repeat the next row?}
+@!x_to_go, @!y_to_go : integer ; {how many columns/rows left?}
+@!turn_on, @!first_on : boolean ; {are we black here?}
+@!count : integer ; {how many bits of current color left?}
+@!cur_n : integer ; {what row are we at?}
+
+@ To finish the \.{GF} file, we write out a postamble, including the
+character locators that we stored away.
+
+@<Write \.{GF} postamble@>=
+j := gf_loc ;
+gf_byte(post) ;
+gf_quad(last_eoc) ;
+gf_quad(design_size) ;
+gf_quad(checksum) ;
+gf_quad(hppp) ;
+gf_quad(vppp) ;
+gf_quad(mmin_m) ;
+gf_quad(mmax_m) ;
+gf_quad(mmin_n) ;
+gf_quad(mmax_n) ;
+@<Write character locators@> ;
+gf_byte(post_post) ;
+gf_quad(j) ;
+gf_byte(gf_id_byte) ;
+for i := 0 to 3 do
+   gf_byte(223) ;
+while gf_loc mod 4 <> 0 do
+   gf_byte(223)
+
+@ We need the |flag_byte| variable.
+
+@<Glob...@>=
+@!flag_byte : integer ; {command or character flag byte}
+
+@ Another necessary procedure skips over any specials between characters
+and before and after the postamble.  (It echoes the specials exactly.)
+
+@p procedure skip_specials ;
+var i, j, k : integer ;
+begin
+   this_char_ptr := gf_loc ;
+   repeat
+      flag_byte := pk_byte ;
+      if flag_byte >= 240 then
+         case flag_byte of
+            240, 241, 242, 243 :
+begin
+   i := 0 ;
+   gf_byte(flag_byte-1) ;
+   for j := 240 to flag_byte do begin
+      k := pk_byte ;
+      gf_byte(k) ;
+      i := 256 * i + k ;
+   end ;
+   for j := 1 to i do gf_byte(pk_byte) ;
+end ;
+            244 :
+begin
+   gf_byte(243) ;
+   gf_quad(get_32) ;
+end ;
+            245 : begin end ;
+            246 : begin end ;
+            247, 248, 249, 250, 251, 252, 253, 254, 255 :
+              abort('Unexpected ', flag_byte:1,'!') ;
+         endcases ;
+   until (flag_byte < 240) or (flag_byte = pk_post) ;
+end ;
+
+@* Terminal communication.
+We must get the file names and determine whether input is to be in
+hexadecimal or binary.  To do this, we use the standard input path
+name.  We need a procedure to flush the input buffer.  For most systems,
+this will be an empty statement.  For other systems, a |print_ln| will
+provide a quick fix.  We also need a routine to get a line of input from
+the terminal.  On some systems, a simple |read_ln| will do.  Finally,
+a macro to print a string to the first blank is required.
+
+@d flush_buffer == begin end
+@d get_line(#) == if eoln(input) then read_ln(input) ;
+   i := 1 ;
+   while not (eoln(input) or eof(input)) do begin
+      #[i] := input^ ;
+      incr(i) ;
+      get(input) ;
+   end ;
+   #[i] := ' '
+
+@ @p procedure dialog ;
+var i : integer ; {index variable}
+buffer : packed array [1..name_length] of char; {input buffer}
+begin
+   for i := 1 to name_length do begin
+      gf_name[i] := ' ' ;
+      pk_name[i] := ' ' ;
+   end;
+   print('Input file name:  ') ;
+   flush_buffer ;
+   get_line(pk_name) ;
+   print('Output file name:  ') ;
+   flush_buffer ;
+   get_line(gf_name) ;
+end ;
+
+@* The main program.
+Now that we have all the pieces written, let us put them together.
+
+@p begin
+initialize ;
+dialog ;
+@<Open files@> ;
+@<Read preamble@> ;
+skip_specials ;
+while flag_byte <> pk_post do begin
+   @<Unpack and write character@> ;
+   skip_specials ;
+end ;
+while not eof(pk_file) do i := pk_byte ;
+@<Write \.{GF} postamble@> ;
+print_ln(pk_loc:1,' bytes unpacked to ',gf_loc:1,' bytes.');
+final_end :
+end .
+
+@* System-dependent changes.
+This section should be replaced, if necessary, by changes to the program
+that are necessary to make \.{PKtoGF} work at a particular installation.
+Any additional routines should be inserted here.
+@^system dependencies@>
+
+@* Index.
+Pointers to error messages appear here together with the section numbers
+where each ident\-i\-fier is used.