summaryrefslogtreecommitdiff
path: root/Build/source/texk/web2c/pktogf.web
diff options
context:
space:
mode:
authorDenis Bitouzé <dbitouze@wanadoo.fr>2021-02-25 18:23:07 +0000
committerDenis Bitouzé <dbitouze@wanadoo.fr>2021-02-25 18:23:07 +0000
commitc6101f91d071883b48b1b4b51e5eba0f36d9a78d (patch)
tree1bf7f5a881d7a4f5c5bf59d0b2821943dd822372 /Build/source/texk/web2c/pktogf.web
parent07ee7222e389b0777456b427a55c22d0e6ffd267 (diff)
French translation for tlmgr updated
git-svn-id: svn://tug.org/texlive/trunk@57912 c570f23f-e606-0410-a88d-b1316a301751
Diffstat (limited to 'Build/source/texk/web2c/pktogf.web')
-rw-r--r--Build/source/texk/web2c/pktogf.web1729
1 files changed, 0 insertions, 1729 deletions
diff --git a/Build/source/texk/web2c/pktogf.web b/Build/source/texk/web2c/pktogf.web
deleted file mode 100644
index eadd46c093b..00000000000
--- a/Build/source/texk/web2c/pktogf.web
+++ /dev/null
@@ -1,1729 +0,0 @@
-% This program is not copyrighted and can be used freely.
-% 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
-% A few typos, no version change: 22 April 2020, 27 October 2020
-\def\versiondate{22 April 2020}
-%
-\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{1}
-\def\topofcontents{\null
- \titlefalse % 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^{20}$ 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 expressly 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
-interpreted 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| mustn'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
-descriptor. 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 descriptor, 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 function |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.