Imported Upstream version 2.2.2upstream/2.2.2

1 files changed, 1687 insertions, 0 deletions

diff --git a/figfont.txt b/figfont.txt
new file mode 100644
index 0000000..102707e
--- /dev/null
+++ b/figfont.txt
@@ -0,0 +1,1687 @@
+        _____  ___  ____   __                _
+       |  ___||_ _|/ ___| / _|  ___   _ __  | |_  ___  _
+       | |_    | || |  _ | |_  / _ \ | '_ \ | __|/ __|(_)
+       |  _|   | || |_| ||  _|| (_) || | | || |_ \__ \ _
+       |_|    |___|\____||_|   \___/ |_| |_| \__||___/(_)
+
+       The FIGfont Version 2 FIGfont and FIGdriver Standard
+       === ======= ======= = ======= === ========= ========
+              Draft 2.0 Copyright 1996, 1997
+                  by John Cowan and Paul Burton
+              Portions Copyright 1991, 1993, 1994
+                  by Glenn Chappell and Ian Chai
+              May be freely copied and distributed.
+
+             Figlet lives at: http://www.figlet.org/
+
+  _____          __           __
+ / ___/__  ___  / /____ ___  / /____
+/ /__/ _ \/ _ \/ __/ -_) _ \/ __(_-<
+\___/\___/_//_/\__/\__/_//_/\__/___/
+
+    INTRODUCTION
+    BASIC DEFINITIONS AND CONCEPTS
+        "FIGfont"
+        "FIGcharacters" and "Sub-characters"
+        "FIGdriver"
+        "FIGure"
+        "FIG"
+        "Layout Modes"
+        "Smushing Rules"
+        "Hardblanks"
+    CREATING FIGFONTS
+        The Header Line
+        Interpretation of Layout Parameters
+        Setting Layout Parameters Step-by-Step
+        FIGfont Comments
+        FIGcharacter Data
+           - Basic Data Structure
+           - Character Codes
+           - Required FIGcharacters
+           - Code Tagged FIGcharacters
+    NOTES - AVOIDING ERRORS AND GENERAL ADVICE
+    CONTROL FILES
+        Standard Format
+        Extended Commands
+    STANDARDIZED CAPABILITIES OF CURRENT AND FUTURE FIGDRIVERS
+    CHART OF CAPABILITIES OF FIGLET 2.2.2 AND FIGWIN 1.0
+
+
+INTRODUCTION
+============
+
+This document specifies the format of font files, and the associated control
+files, used by the FIGlet and FIGWin programs (FIGdrivers).  It is written
+for designers who wish to build fonts (FIGfonts) usable by either program,
+and also serves as a standard for development of future versions or similar
+FIGdrivers.  Some features explained here are not supported by both programs.
+See separate documentation to learn how to use FIGlet or FIGWin.
+
+NOTE: FIGWin 1.0 is packaged with a program called FIGfont Editor for Windows
+1.0, which is just that.  It does not require a complete understanding of
+this document to create FIGfonts.  However it is a good idea to become
+familiar with the "BASIC DEFINITIONS AND CONCEPTS" information before using
+it.
+
+If you design a FIGfont, please send an e-mail announcement to
+<figletfonts@figlet.org>, the FIGlet fonts mailing list, and email a copy
+to info@figlet.org for us to put it on the ftp site (ftp://ftp.figlet.org/)
+
+BASIC DEFINITIONS AND CONCEPTS
+===== =========== === ========
+
+"FIGfont"
+
+A FIGfont is a file which represents the graphical arrangement of characters
+representing larger characters.  Since a FIGfont file is a text file, it can
+be created with any text editing program on any platform.  The filename of a
+FIGfont file must end with ".flf", which stands for "<F>IG<L>ettering
+<F>ont".
+
+
+"FIGcharacters" and "Sub-characters"
+
+Because FIGfonts describe large characters which consist of smaller
+characters, confusion can result when descussing one or the other.
+Therefore, the terms "FIGcharacter" and "sub-character" are used,
+respectively.
+
+
+"FIGdriver"
+
+The term FIGdriver is used in this document to encompass FIGlet, FIGWin, and
+any future programs which use FIGfonts.
+
+
+"FIGure"
+
+A FIGure (thusly capitalized) is an image created by a FIGdriver.
+
+
+"FIG"
+
+A bit of history:
+
+In Spring 1991, inspired by the Email signature of a friend named Frank, and
+goaded on by Ian Chai, Glenn Chappell wrote a nifty little 170-line "C"
+program called "newban", which would create large letters out of ordinary
+text characters.  At the time, it was only compiled for UNIX.  In hindsight,
+we now call it "FIGlet 1.0".  FIGlet stands for <F>rank, <I>an, and <G>lenn's
+<let>ters.  In various incarnations, newban circulated around the net for a
+couple of years.  It had one font, which included only lowercase letters.
+
+In early 1993, Ian decided newban was due for a few changes, so together Ian
+and Glenn added the full ASCII character set, to start with.  First, though,
+Ian had to find a copy of the source, since Glenn had tossed it away as not
+worth the disk space.  Ian and Glenn discussed what could be done with it,
+decided on a general re-write, and, 7 months later, ended up with 888 lines
+of code, 13 FIGfonts and documentation.  This was FIGlet 2.0, the first real
+release.
+
+To their great surprise, FIGlet took the net by storm.  They received floods
+of "FIGlet is great!" messages and a new contributed FIGfont about once a
+week.  To handle all the traffic, Ian quickly set up a mailing list, Daniel
+Simmons kindly offered space for an FTP site, several people volunteered to
+port FIGlet to non-Unix operating systems, ...and bug reports poured in.
+
+Because of these, and the need to make FIGlet more "international", Ian and
+Glenn released a new version of FIGlet which could handle non-ASCII character
+sets and right-to-left printing.  This was FIGlet 2.1, which, in a couple of
+weeks, became figlet 2.1.1.  This weighed in at 1314 lines, and there were
+over 60 FIGfonts.
+
+By late 1996, FIGlet had quite a following of fans subscribing to its mailing
+list.  It had been ported to MS-DOS, Macintosh, Amiga, Apple II GS, Atari ST,
+Acorn and OS/2.  FIGlet had been further updated, and there were nearly 200
+FIGfonts.
+
+John Cowan and Paul Burton are two FIGlet fans who decided to create new
+versions.  While John wrote FIGlet version 2.2 using C, Paul wrote FIGWin
+1.0, the first true GUI (Windows) implementation of FIGlet, using Visual
+Basic.  John and Paul worked together to add new features to FIGfont files
+which could be read by both programs, and together wrote this document, which
+we hope helps to establish consistency in FIGfonts and help with the creation
+of future FIGdrivers.  FIGlet 2.2 has about 4800 lines of code, of which
+over half is a support library for reading compressed files.
+
+FIGlet 2.2 and FIGWin 1.0 both allow greater flexibility by use of new
+information which can be contained in FIGfont files without interfering with
+the function of older FIGdrivers.
+
+NOTE: The Macintosh version of FIGlet is still command-line driven as of this
+writing, and a GUI version is very much in demand.  The FIGlet C code is
+written to be easily plugged in to a GUI shell, so it will be a relatively
+easy task for a Macintosh developer.
+
+
+
+
+"Layout Modes"
+
+A FIGdriver may arrange FIGcharacters using one of three "layout modes",
+which define the spacing between FIGcharacters.  The layout mode for the
+horizontal axis may differ from the layout mode for the vertical axis.  A
+default choice is defined for each axis by every FIGfont.
+
+The three layout modes are:
+
+    Full Size (Separately called "Full Width" or "Full Height".)
+
+        Represents each FIGcharacter occupying the full width or
+        height of its arrangement of sub-characters as designed.
+
+    Fitting Only (Separately called "Kerning or "Vertical Fitting".)
+
+        Moves FIGcharacters closer together until they touch.
+        Typographers use the term "kerning" for this phenomenon
+        when applied to the horizontal axis, but fitting also
+        includes this as a vertical behavior, for which there is
+        apparently no established typographical term.
+
+    Smushing (Same term for both axes.)
+
+        Moves FIGcharacters one step closer after they touch, so that
+        they partially occupy the same space.  A FIGdriver must decide
+        what sub-character to display at each junction.  There are two
+        ways of making these decisions: by controlled smushing or by
+        universal smushing.
+
+        Controlled smushing uses a set of "smushing rules" selected by
+        the designer of a FIGfont.  (See "Smushing Rules" below.)
+        Each rule is a comparison of the two sub-characters which must
+        be joined to yield what to display at the junction.
+        Controlled smushing will not always allow smushing to occur,
+        because the compared sub-characters may not correspond to any
+        active rule.  Wherever smushing cannot occur, fitting occurs
+        instead.
+
+        Universal smushing simply overrides the sub-character from the
+        earlier FIGcharacter with the sub-character from the later
+        FIGcharacter.  This produces an "overlapping" effect with some
+        FIGfonts, wherin the latter FIGcharacter may appear to be "in
+        front".
+
+        A FIGfont which does not specify any smushing rules for a
+        particular axis indicates that universal smushing is to occur
+        when smushing is requested.  Therefore, it is not possible for
+        a FIGfont designer to "forbid" smushing.  However there are
+        ways to ensure that smushing does not cause a FIGfont to be
+        illegible when smushed.  This is especially important for
+        smaller FIGfonts.  (See "Hardblanks" for details.)
+
+For vertical fitting or smushing, entire lines of output FIGcharacters are
+"moved" as a unit.
+
+Not all FIGdrivers do vertical fitting or smushing.  At present, FIGWin 1.0
+does, but FIGlet 2.2 does not.  Further, while FIGlet 2.2 allows the user to
+override the FIGfont designer's set of smushing rules, FIGWin 1.0 does not.
+
+NOTE: In the documentation of FIGlet versions prior to 2.2, the term
+"smushmode" was used to mean the layout mode, and this term further included
+the smushing rules (if any) to be applied.  However, since the layout mode
+may or may not involve smushing, we are straying from the use of this
+somewhat misleading term.
+
+
+"Smushing Rules"
+
+Again, smushing rules are for controlled smushing.  If none are defined to be
+active in a FIGfont, universal smushing occurs instead.
+
+Generally, if a FIGfont is "drawn at the borders" using sub-characters
+"-_|/\[]{}()<>", you will want to use controlled smushing by selecting from
+the rules below.  Otherwise, if your FIGfont uses a lot of other
+sub-characters, do not select any rules and universal smushing will occur
+instead.  (See "Hardblanks" below if your FIGfont is very small and would
+become illegible if smushed.)  Experimentation is the best way to make these
+decisions.
+
+There are six possible horizontal smushing rules and five possible vertical
+smushing rules.  Below is a description of all of the rules.
+
+NOTE: Ignore the "code values" for now.  They are explained later.
+
+    The Six Horizontal Smushing Rules
+
+        Rule 1: EQUAL CHARACTER SMUSHING (code value 1)
+
+            Two sub-characters are smushed into a single sub-character
+            if they are the same.  This rule does not smush
+            hardblanks.  (See "Hardblanks" below.)
+
+        Rule 2: UNDERSCORE SMUSHING (code value 2)
+
+            An underscore ("_") will be replaced by any of: "|", "/",
+            "\", "[", "]", "{", "}", "(", ")", "<" or ">".
+
+        Rule 3: HIERARCHY SMUSHING (code value 4)
+
+            A hierarchy of six classes is used: "|", "/\", "[]", "{}",
+            "()", and "<>".  When two smushing sub-characters are
+            from different classes, the one from the latter class
+            will be used.
+
+        Rule 4: OPPOSITE PAIR SMUSHING (code value 8)
+
+            Smushes opposing brackets ("[]" or "]["), braces ("{}" or
+            "}{") and parentheses ("()" or ")(") together, replacing
+            any such pair with a vertical bar ("|").
+
+        Rule 5: BIG X SMUSHING (code value 16)
+
+            Smushes "/\" into "|", "\/" into "Y", and "><" into "X".
+            Note that "<>" is not smushed in any way by this rule.
+            The name "BIG X" is historical; originally all three pairs
+            were smushed into "X".
+
+        Rule 6: HARDBLANK SMUSHING (code value 32)
+
+            Smushes two hardblanks together, replacing them with a
+            single hardblank.  (See "Hardblanks" below.)
+
+
+    The Five Vertical Smushing Rules
+
+        Rule 1: EQUAL CHARACTER SMUSHING (code value 256)
+
+            Same as horizontal smushing rule 1.
+
+        Rule 2: UNDERSCORE SMUSHING (code value 512)
+
+            Same as horizontal smushing rule 2.
+
+        Rule 3: HIERARCHY SMUSHING (code value 1024)
+
+            Same as horizontal smushing rule 3.
+
+        Rule 4: HORIZONTAL LINE SMUSHING (code value 2048)
+
+            Smushes stacked pairs of "-" and "_", replacing them with
+            a single "=" sub-character.  It does not matter which is
+            found above the other.  Note that vertical smushing rule 1
+            will smush IDENTICAL pairs of horizontal lines, while this
+            rule smushes horizontal lines consisting of DIFFERENT
+            sub-characters.
+
+        Rule 5: VERTICAL LINE SUPERSMUSHING (code value 4096)
+
+            This one rule is different from all others, in that it
+            "supersmushes" vertical lines consisting of several
+            vertical bars ("|").  This creates the illusion that
+            FIGcharacters have slid vertically against each other.
+            Supersmushing continues until any sub-characters other
+            than "|" would have to be smushed.  Supersmushing can
+            produce impressive results, but it is seldom possible,
+            since other sub-characters would usually have to be
+            considered for smushing as soon as any such stacked
+            vertical lines are encountered.
+
+
+"Hardblanks"
+
+A hardblank is a special sub-character which is displayed as a blank (space)
+in rendered FIGures, but is treated more like a "visible" sub-character when
+fitting or smushing horizontally.  Therefore, hardblanks keep adjacent
+FIGcharacters a certain distance apart.
+
+NOTE: Hardblanks act the same as blanks for vertical operations.
+
+Hardblanks have three purposes:
+
+    1) Hardblanks are used to create the blank (space) FIGcharacter.
+
+        Usually the space FIGcharacter is simply one or two vertical
+        columns of hardblanks.  Some slanted FIGfonts as shown below
+        have a diagonal arrangement of hardblanks instead.
+
+    2) Hardblanks can prevent "unreasonable" fitting or smushing.
+
+        Normally when fitting or smushing, the blank (space)
+        sub-character is considered "vacant space".  In the following
+        example, a capital "C" FIGcharacter is smushed with a "minus"
+        FIGcharacter.
+                ______                        ______
+               / ____/                       / ____/
+              / /      ____  >>-Becomes->   / /  ____
+             / /___   /___/                / /__/___/
+             \____/                        \____/
+
+        The FIGure above looks like a capital G.  To prevent this, a
+        FIGfont designer might place a hardblank in the center of the
+        capital C.  In the following example, the hardblank is
+        represented as a "$":
+                ______                        ______
+               / ____/                       / ____/
+              / /  $   ____  >>-Becomes->   / /   ____
+             / /___   /___/                / /___/___/
+             \____/                        \____/
+
+        Using hardblanks in this manner ensures that FIGcharacters
+        with a lot of empty space will not be unreasonably "invaded"
+        by adjacent FIGcharacters.  Generally, FIGcharacters such as
+        capital C, L or T, or small punctuation marks such as commas,
+        may contain hardblanks, since they may contain a lot of vacant
+        space which is "accessible" from either side.
+
+    3) Hardblanks can prevent smushing from making FIGfonts illegible.
+
+        This legitimate purpose of hardblanks is often overused.  If a
+        FIGfont designer is absolutely sure that smushing "visible"
+        sub-characters would make their FIGfont illegible, hardblanks
+        may be positioned at the end of each row of sub-characters,
+        against the visible sub-characters, creating a barrier.
+
+        With older FIGdrivers, using hardblanks for this purpose meant
+        that FIGcharacters would have to be separated by at least one
+        blank in output FIGures, since only a hardblank could smush
+        with another hardblank.  However with the advent of universal
+        smushing, this is no longer necessary.  Hardblanks ARE
+        overriden by any visible sub-character when performing
+        universal smushing.  Hardblanks still represent a "stopping
+        point", but only AFTER their locations are occupied.
+
+        NOTE: Earlier it was stated that universal smushing overrides
+        the sub-character from the former FIGcharacter with the
+        sub-character from the latter FIGcharacter.  Hardblanks (and
+        blanks or spaces) are the exception to this rule; they will
+        always be overriden by visible sub-characters, regardless of
+        which FIGcharacter contains the hardblank.  This ensures that
+        no visible sub-characters "disappear".
+
+        Therefore, one can design a FIGfont with a default behavior of
+        universal smushing, while the output FIGure would LOOK like
+        the effect of fitting, or even full size if additional
+        hardblanks are used.  If a user "scales down" the layout mode
+        to fitting, the result would look like "extra spacing" between
+        FIGcharacters.
+
+        Taking this concept further, a FIGcharacter may also include
+        extra blanks (spaces) on the left side of each FIGcharacter,
+        which would define the FIGcharacter's width as slightly larger
+        than required for the visible sub-characters and hardblanks.
+        With such a FIGfont, a user who further "scales down" the
+        layout mode to full size would see even greater spacing.
+
+        These techniques prevent horizontal smushing from causing a
+        FIGfont to become illegible, while offering greater
+        flexibility of output to users.
+
+        NOTE: These techniques cannot be used to prevent vertical
+        smushing of visible sub-characters, since hardblanks are not
+        respected in the vertical axis.  Although it is possible to
+        select only one vertical smushing rule which involves only
+        sub-characters which are not used in your FIGfont, it is
+        recommend that you do NOT do so.  In our opinion, most users
+        would prefer to get what they ask for, rather than being
+        told, in effect: "I, the FIGfont designer, have decided that
+        you wouldn't like the results of vertical smushing, so I have
+        prevented you from trying it."  Instead, we recommend setting
+        the default behavior to either fitting or full height, and
+        either allowing universal smushing, or selecting vertical
+        smushing rules which seem most appropriate.  A user of your
+        FIGfont will quickly see why you did not choose smushing as
+        the default vertical layout mode, and will agree with you.
+
+
+"Character Sets" and "Character Codes"
+
+When you type using your keyboard, you are actually sending your computer a
+series of numbers.  Each number must be interpreted by your computer so that
+it knows what character to display.  The computer uses a list of definitions,
+called a "character set".  The numbers which represent each character are
+ called "character codes".
+
+There are many character sets, most of which are internationally accepted as
+standards.  By far, the most common character set is ASCII, which stands for
+"American Standard Code for Information Interchange".  ASCII identifies its
+characters with codes ranging from 0 to 127.
+
+NOTE: The term "ASCII art" has become well-understood to mean artistic images
+which consist of characters on your screen (such as FIGures).
+
+For a list of the printable ASCII characters with the corresponding codes,
+see the section "REQUIRED CHARACTERS" below.  The other ASCII codes in the
+range of 0 through 31 are "control characters" such as carriage-return
+(code 13), linefeed/newline (code 10), tab (code 9), backspace (code 8) or
+null (code 0).  Code 127 is a delete in ASCII.
+
+Getting more technical for just a moment: A byte consisting of 8 bits (eight
+ 1's or 0's) may represent a number from 0 to 255.  Therefore, most computers
+have DIRECT access to 256 characters at any given time.  A character set
+which includes 256 characters is called an 8-bit character set.
+
+For Latin-based languages, ASCII is almost always the first half of a larger
+8-bit character set.  Latin-1 is the most common example of an 8-bit
+character set.  Latin-1 includes all of ASCII, and adds characters with codes
+from 128 to 255 which include umlauted ("double-dotted") letters and
+characters with various other accents.  In the United States, Windows and
+most Unix systems have Latin-1 directly available.
+
+Most modern systems allow the possibility of changing 8-bit character sets.
+On Windows systems, character sets are referred to as "code pages".  There
+are many other character sets which are not mentioned here.  DOS has its own
+character set (which also has international variants) that includes graphics
+characters for drawing lines.  It is also an extension of ASCII.
+
+For some languages, 8-bit character sets are insufficient, particularly on
+East Asian systems.  Therefore, some systems allow 2 bytes for each
+character, which multiplies the 256 possibilties by 256, resulting in 65536
+possible characters.  (Much more than the world will ever need.)
+
+Unicode is a character set standard which is intended to fulfill the
+worldwide need for a single character set which includes all characters used
+worldwide.  Unicode includes character codes from 0 to 65535, although at
+present, only about 22,000 characters have been officially assigned and named
+by the Unicode Consortium.  The alphabets and other writing systems
+representable with Unicode include all Latin-alphabet systems, Greek,
+Russian and other Cyrillic-alphabet systems, Hebrew, Arabic, the various
+languages of India, Chinese, Japanese, Korean, and others.  The existing
+Unicode symbols include chess pieces, astrological signs, gaming symbols,
+telephones, pointing fingers, etc. --- just about any type of FIGcharacter
+you may wish to create.  Unicode is constantly (but slowly) being extended
+to handle new writing systems and symbols.  Information on Unicode is
+available at http://www.unicode.org and at ftp://unicode.org .
+
+Unicode, Latin-1, and ASCII all specify the same meanings for overlapping
+character codes:  ASCII 65 = Latin-1 65 = Unicode 65 = "A", formally known
+as "LATIN CAPITAL LETTER A".
+
+Since a keyboard usually has only about 100 keys, your computer may contain
+a program called a "keyboard map", which will interpret certain keystrokes
+or combinations of keystrokes as different character codes.  Keyboard maps
+use "mapping tables" to make these determinations.  The appropriate keyboard
+activity for a given character code may involve several keystrokes.  Almost
+all systems are capable of handling at least 8-bit character sets (containing
+256 characters), so there is always an active keyboard map, at least for
+those characters which are not actually painted on the keys.  (United States
+users may not even know that their computer can interpret special keystrokes.
+Such keystrokes may be something similar to holding down the ALT key while
+typing a character code on the numeric keypad.  Try it!)
+
+Below are characters 160 through 255, AS REPRESENTED ON YOUR SYSTEM.
+
+        ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ
+       ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
+
+IMPORTANT NOTE: Depending on which character set is active on your system,
+you may see different characters.  This document (like all computer
+documents) does not contains characters per se, only bytes.  What you see
+above is your particular computer's representation of these byte values.
+In other words, your active character set.  However, if it is Latin-1, the
+first visible character is an inverted "!", and the last is an umlauted "y".
+Although we can safely assume your computer has ASCII, it does not
+necessarily have the Latin-1 character set active.
+
+What does all this have to do with FIGfonts???
+
+First, it should be evident that it is best to use only ASCII characters for
+sub-characters when possible.  This will ensure portability to different
+platforms.
+
+FIGlet has gained international popularity, but early versions were made to
+handle only FIGcharacters with assigned character codes corresponding to
+ASCII.  So, over the years there have been four methods used to create
+"virtual mapping tables" within the program itself:
+
+     The first method was simply to create FIGcharacters which do not
+     look like the ASCII character set implies.  For example, a
+     FIGfont might contain Greek letters, and within its comments, it
+     may say, "If you type A, you'll get a Greek Alpha" etc.  With
+     the advent of newer features, it is preferable not to use this
+     method. Instead, when possible, add new FIGcharacters to
+     existing FIGfonts or create new FIGfonts with FIGcharacters coded
+     to match the expectations of ASCII/Latin-1/Unicode, and create an
+     appropriate control file.  (See "CONTROL FILES" below.)  Remember
+     that Unicode includes almost any character for which you may want
+     to create a FIGcharacter.
+
+     The second method was very specific, to accommodate the German
+     audience.  A special option was added to the FIGlet program
+     which would re-route input characters "[", "\", and "]" to
+     umlauted A, O and U, while "{", "|", and "}" would become the
+     respective lowercase versions of these.  Also, "~" was made to
+     become the s-z character when this special option was used.  This
+     was called "the -D option."  The addition of this feature meant
+     that all compatible FIGfonts must contain these Deutsch (German)
+     FIGcharacters, in addition to the ASCII FIGcharacters.  Although
+     this option is still available in the most recent version, it is
+     no longer necessary, as the same result can be achieved by the
+     newer features described below.  However, the requirement for
+     Deutsch FIGcharacters remains for backward compatibility.  (Or at
+     least zero-width FIGcharacters in their place.)
+
+     Later, FIGlet was made to accept control files, which are quite
+     literally a form of mapping table.  (See "CONTROL FILES" below.)
+     This was a significant advance for internationalization.
+
+     FIGlet 2.2 can now accept specially encoded formats of input
+     text which imply more than one byte per character.
+
+
+CREATING FIGFONTS
+======== ========
+
+NOTE: FIGWin 1.0 is packaged with a program called FIGfont Editor for Windows
+1.0, which is just that.  There is no need to read further if you intend to
+use it.  However, the section "CONTROL FILES" below is still relevant.
+
+Since a FIGfont file is a text file, it can be created with any text editing
+program on any platform, and will still be compatible with FIGdrivers on all
+operating systems, except that the bytes used to indicate the end of each
+text line may vary.  (PC's use carriage return and linefeed at the end of
+each line, Macintosh uses carriage return only, and UNIX uses linefeed only.)
+
+This minor difference among operating systems is handled easily by setting
+your FTP program to ASCII mode during upload or download.  So there is no
+need to be concerned about this as long as you remember to do this during
+file transfer.
+
+The filename of a FIGfont file must end with ".flf", which stands for
+"<F>IG<L>ettering <F>ont".    The first part of the filename should contain
+only letters, and should be lowercase on operating systems which permit case
+sensitive filenames.  The filename should be unique in the first 8
+characters, since some older file systems truncate longer filenames.
+
+It is easier to modify an existing FIGfont than it is to create a new one
+from scratch.  The first step is to read and understand this document.
+You may want to load "standard.flf" or another FIGfont into a text editor as
+an example while you read.
+
+A FIGfont file contains three portions: a header line, comments, and
+FIGcharacter data.
+
+
+THE HEADER LINE
+
+The header line gives information about the FIGfont.  Here is an example
+showing the names of all parameters:
+
+          flf2a$ 6 5 20 15 3 0 143 229    NOTE: The first five characters in
+            |  | | | |  |  | |  |   |     the entire file must be "flf2a".
+           /  /  | | |  |  | |  |   \
+  Signature  /  /  | |  |  | |   \   Codetag_Count
+    Hardblank  /  /  |  |  |  \   Full_Layout*
+         Height  /   |  |   \  Print_Direction
+         Baseline   /    \   Comment_Lines
+          Max_Length      Old_Layout*
+
+  * The two layout parameters are closely related and fairly complex.
+      (See "INTERPRETATION OF LAYOUT PARAMETERS".)
+
+For those desiring a quick explanation, the above line indicates that this
+FIGfont uses "$" to represent the hardblank in FIGcharacter data, it has
+FIGcharacters which are 6 lines tall, 5 of which are above the baseline, no
+line in the FIGfont data is more than 20 columns wide, the default horizontal
+layout is represented by the number 15, there are 3 comment lines, the
+default print direction for this FIGfont is left-to-right, a complete
+description of default and possible horizontal and vertical layouts is
+represented by the number 143, and there are 229 code-tagged characters.
+
+The first seven parameters are required.  The last three (Direction,
+Full_Layout, and Codetag_Count, are not.  This allows for backward
+compatibility with older FIGfonts, but a FIGfont without these parameters would
+force a FIGdriver to "guess" (by means not described in this document) the
+information it would expect to find in Full_Layout.  For this reason, inclusion
+of all parameters is strongly recommended.
+
+Future versions of this standard may add more parameters after Codetag_Count.
+
+A description of each parameter follows:
+
+     Signature
+
+The signature is the first five characters: "flf2a".  The first four
+characters "flf2" identify the file as compatible with FIGlet version 2.0 or
+later (and FIGWin 1.0).  The "a" is currently ignored, but cannot be omitted.
+Different characters in the "a" location may mean something in future
+versions of this standard.  If so, you can be sure your FIGfonts will still
+work if this character is "a".
+
+     Hardblank
+
+Immediately following the signature is the hardblank character.  The
+hardblank character in the header line defines which sub-character will be
+used to represent hardblanks in the FIGcharacter data.
+
+By convention, the usual hardblank is a "$", but it can be any character
+except a blank (space), a carriage-return, a newline (linefeed) or a null
+character.  If you want the entire printable ASCII set available to use, make
+the hardblank a "delete" character (character code 127).  With the exception
+of delete, it is inadvisable to use non-printable characters as a hardblank.
+
+     Height
+
+The Height parameter specifies the consistent height of every FIGcharacter,
+measured in sub-characters.  Note that ALL FIGcharacters in a given FIGfont
+have the same height, since this includes any empty space above or below.
+This is a measurement from the top of the tallest FIGcharacter to the bottom
+of the lowest hanging FIGcharacter, such as a lowercase g.
+
+     Baseline
+
+The Baseline parameter is the number of lines of sub-characters from the
+baseline of a FIGcharacter to the top of the tallest FIGcharacter.  The
+baseline of a FIGfont is an imaginary line on top of which capital letters
+would rest, while the tails of lowercase g, j, p, q, and y may hang below.
+In other words, Baseline is the height of a FIGcharacter, ignoring any
+descenders.
+
+This parameter does not affect the output of FIGlet 2.2 or FIGWin 1.0, but
+future versions or other future FIGdrivers may use it.  The Baseline
+parameter should be correctly set to reflect the true baseline as described
+above.  It is an error for Baseline to be less than 1 or greater than the
+Height parameter.
+
+     Max_Length
+
+The Max_Length parameter is the maximum length of any line describing a
+FIGcharacter.  This is usually the width of the widest FIGcharacter, plus 2
+(to accommodate endmarks as described later.)  However, you can (and probably
+should) set Max_Length slightly larger than this as a safety measure in case
+your FIGfont is edited to include wider FIGcharacters.  FIGlet (but not
+FIGWin 1.0) uses this number to minimize the memory taken up by a FIGfont,
+which is important in the case of FIGfonts with many FIGcharacters.
+
+     Old_Layout
+
+(See "INTERPRETATION OF LAYOUT PARAMETERS" below.)
+
+     Comment_Lines
+
+Between the first line and the actual FIGcharacters of the FIGfont are the
+comment lines.  The Comment_Lines parameter specifies how many lines there
+are.  Comments are optional, but recommended to properly document the origin
+of a FIGfont.
+
+     Print_Direction
+
+The Print_Direction parameter tells which direction the font is to be
+printed by default.  A value of 0 means left-to-right, and 1 means
+right-to-left.  If this parameter is absent, 0 (left-to-right) is assumed.
+Print_Direction may not specify vertical print, although FIGdrivers are
+capable of vertical print.  Versions of FIGlet prior to 2.1 ignore this
+parameter.
+
+      Full_Layout
+
+(See "INTERPRETATION OF LAYOUT PARAMETERS" just below.)
+
+      Codetag_Count
+
+Indicates the number of code-tagged (non-required) FIGcharacters in this
+FIGfont.  This is always equal to the total number of FIGcharacters in the font
+minus 102.  This parameter is typically ignored by FIGdrivers, but can be
+used to verify that no characters are missing from the end of the FIGfont.
+The chkfont program will display the number of codetagged characters
+in the FIGfont on which it is run, making it easy to insert this parameter
+after a FIGfont is written.
+
+
+INTERPRETATION OF LAYOUT PARAMETERS
+
+Full_Layout describes ALL information about horizontal and vertical layout:
+the default layout modes and potential smushing rules, even when smushing is
+not a default layout mode.
+
+Old_Layout does not include all of the information desired by the most
+recent FIGdrivers, which is the inspiration for the creation of the new
+Full_Layout parameter.  Old_Layout is still required for backward
+compatibility, and FIGdrivers must be able to interpret FIGfonts which do not
+have the Full_Layout parameter.  (See "STANDARDIZED CAPABILITIES OF CURRENT
+AND FUTURE FIGDRIVERS".)
+
+Versions of FIGlet prior to 2.2 do not recognize the Full_Layout parameter.
+Documentation accompanying FIGlet versions prior to 2.2 refer to Old_Layout
+as "smushmode", which is somewhat misleading since it can indicate layout
+modes other than smushing.
+
+Old_Layout and Full_Layout must contain some redundant information.
+
+Setting the layout parameters is a matter of adding numbers together ("code
+values").  What follows is a chart of the meanings of all code values.
+(You may skip down to "SETTING LAYOUT PARAMETERS STEP BY STEP" if you prefer,
+or if you find this portion confusing.)
+
+Full_Layout: (Legal values 0 to 32767)
+
+     1  Apply horizontal smushing rule 1 when smushing
+     2  Apply horizontal smushing rule 2 when smushing
+     4  Apply horizontal smushing rule 3 when smushing
+     8  Apply horizontal smushing rule 4 when smushing
+    16  Apply horizontal smushing rule 5 when smushing
+    32  Apply horizontal smushing rule 6 when smushing
+    64  Horizontal fitting (kerning) by default
+   128  Horizontal smushing by default (Overrides 64)
+   256  Apply vertical smushing rule 1 when smushing
+   512  Apply vertical smushing rule 2 when smushing
+  1024  Apply vertical smushing rule 3 when smushing
+  2048  Apply vertical smushing rule 4 when smushing
+  4096  Apply vertical smushing rule 5 when smushing
+  8192  Vertical fitting by default
+ 16384  Vertical smushing by default (Overrides 8192)
+
+When no smushing rules are included in Full_Layout for a given axis, the
+meaning is that universal smushing shall occur, either by default or when
+requested.
+
+Old_Layout: (Legal values -1 to 63)
+
+    -1  Full-width layout by default
+     0  Horizontal fitting (kerning) layout by default*
+     1  Apply horizontal smushing rule 1 by default
+     2  Apply horizontal smushing rule 2 by default
+     4  Apply horizontal smushing rule 3 by default
+     8  Apply horizontal smushing rule 4 by default
+    16  Apply horizontal smushing rule 5 by default
+    32  Apply horizontal smushing rule 6 by default
+
+* When Full_Layout indicates UNIVERSAL smushing as a horizontal default
+(i.e., when none of the code values of horizontal smushing rules are included
+and code value 128 is included in Full_Layout) Old_Layout must be set to 0
+(zero).  Older FIGdrivers which cannot read the Full_Layout parameter are
+also incapable of universal smushing.  Therefore they would be directed to
+the "next best thing", which is horizontal fitting (kerning).
+
+NOTE: You should NOT add the -1 value to any positive code value for
+Old_Layout.  This would be a logical contradiction.
+
+See "STANDARDIZED CAPABILITIES OF CURRENT AND FUTURE FIGDRIVERS" for the
+behavior of a FIGdriver when the Full_Layout parameter is absent (presumably
+in an older FIGfont).
+
+The following rules establish consistency between Old_Layout and Full_Layout.
+
+  If full width is to be the horizontal default:
+    Old_Layout must be -1.
+    Full_Layout must NOT include code values 64 nor 128.
+
+  If horizontal fitting (kerning) is to be default:
+    Old_Layout must be 0.
+    Full_Layout must include code value 64.
+    Full_Layout must NOT include code value 128.
+
+  If CONTROLLED smushing is to be the horizontal default:
+    Old_Layout must be a positive number, represented by the added
+        code values of all desired horizontal smushing rules.
+    Full_Layout must include the code values for the SAME set of
+        horizontal smushing rules as included in Old_Layout.
+    Full_Layout must include code value 128.
+
+  If UNIVERSAL smushing is to be the horizontal default:
+    Old_Layout must be 0.
+    Full_Layout must include code value 128.
+    Full_Layout must NOT include any code value under 64.
+
+In general terms, if Old_Layout specifies horizontal smushing rules,
+Full_Layout must specify the same set of horizontal rules, and both must
+indicate the same horizontal default layout mode.
+
+
+SETTING LAYOUT PARAMETERS STEP-BY-STEP
+
+The following step-by-step process will yield correct and consistent values
+for the two layout parameters.  You may skip this if you find the
+explanations above easier to use.
+
+Step 1: Start with 0 for both numbers.
+
+     Write "Old_Layout" and "Full_Layout" on a piece of paper.
+     Write the number 0 next to each.
+     The number 0 may be crossed out and changed several times below.
+     Go to step 2.
+
+Step 2: Set the DEFAULT HORIZONTAL LAYOUT MODE.
+
+     If you want to use FULL WIDTH as the default
+        Make Old_Layout -1
+        Go to step 3.
+     If you want to use HORIZONTAL FITTING (kerning) as the default
+        Make Full_Layout 64
+        Go to step 3.
+     If you want to use HORIZONTAL SMUSHING as the default
+        Make Full_Layout 128
+        Go to step 3.
+
+Step 3: Specify HOW TO SMUSH HORIZONTALLY WHEN SMUSHING.
+
+     If you want to use UNIVERSAL smushing for the horizontal axis
+        Go to step 4.
+     If you want to use CONTROLLED smushing for the horizontal axis
+        Add together the code values for all the horizontal smushing
+        rules you want from the list below to get the horizontal
+        smushing rules total.
+
+            EQUAL CHARACTER SMUSHING          1
+            UNDERSCORE SMUSHING               2
+            HIERARCHY SMUSHING                4
+            OPPOSITE PAIR SMUSHING            8
+            BIG X SMUSHING                   16
+            HARDBLANK SMUSHING               32
+
+            Horizontal smushing rules total: ___
+
+     If Full_Layout is currently 128
+        Change Old_Layout to the horizontal smushing rules total.
+        Increase Full_Layout by the horizontal smushing rules total.
+        Go to Step 4.
+     If Full_Layout is currently 0 or 64
+        Increase Full_Layout by the horizontal smusing rules total.
+        Go to Step 4.
+
+Step 4: Set the DEFAULT VERTICAL LAYOUT MODE.
+
+     If you want to use FULL HEIGHT as the default
+        Go to step 5.
+     If you want to use VERTICAL FITTING as the default
+        Increase Full_Layout by 8192.
+        Go to step 5.
+     If you want to use VERTICAL SMUSHING as the default
+        Increase Full_Layout by 16384.
+        Go to step 5.
+
+Step 5: Specify HOW TO SMUSH VERTICALLY WHEN SMUSHING.
+
+     If you want to use UNIVERSAL smushing for the vertical axis
+        Go to step 6.
+     If you want to use CONTROLLED smushing for the vertical axis
+        Add together the code values for all the vertical smushing
+        rules you want from the list below to get the vertical
+        smushing rules total.
+
+            EQUAL CHARACTER SMUSHING        256
+            UNDERSCORE SMUSHING             512
+            HIERARCHY SMUSHING             1024
+            HORIZONTAL LINE SMUSHING       2048
+            VERTICAL LINE SUPERSMUSHING    4096
+
+            Vertical smushing rules total: ____
+
+        Increase Full_Layout by the vertical smushing rules total.
+        Go to step 6.
+
+Step 6: You're done.
+
+The resulting value of Old_Layout will be a number from -1 to 63.
+The resulting value of Full_Layout will be a number from 0 and 32767.
+
+
+FIGFONT COMMENTS
+
+After the header line are FIGfont comments.  The comments can be as many
+lines as you like, but should at least include your name and Email address.
+Here is an example which also shows the header line.
+
+    flf2a$ 6 5 20 15 3 0 143
+    Example by Glenn Chappell <ggc@uiuc.edu> 8/94
+    Permission is hereby given to modify this font, as long as the
+    modifier's name is placed on a comment line.
+
+Comments are not required, but they are appreciated.  Please comment your
+FIGfonts.
+
+Remember to adjust the Comment_Lines parameter as you add lines to your
+comments.  Don't forget that blank lines DO count.
+
+
+FIGCHARACTER DATA
+============ ====
+
+The FIGcharacter data begins on the next line after the comments and
+continues to the end of the file.
+
+BASIC DATA STRUCTURE
+
+The sub-characters in the file are given exactly as they should be output,
+with two exceptions:
+
+    1) Hardblanks should be the hardblank character specified in the
+       header line, not a blank (space).
+
+    2) Every line has one or two endmark characters, whose column
+       locations define the width of each FIGcharacter.
+
+In most FIGfonts, the endmark character is either "@" or "#".  The FIGdriver
+will eliminate the last block of consecutive equal characters from each line
+of sub-characters when the font is read in.  By convention, the last line of
+a FIGcharacter has two endmarks, while all the rest have one. This makes it
+easy to see where FIGcharacters begin and end.  No line should have more
+than two endmarks.
+
+Below is an example of the first few FIGcharacters, taken from small.flf.
+
+NOTE: The line drawn below consisting of "|" represents the left margin of
+your editor.  It is NOT part of the FIGfont.  Also note that hardblanks are
+represented as "$" in this FIGfont, as would be described in the header line.
+
+                        |$@
+                        |$@
+           blank/space  |$@
+                        |$@
+                        |$@@
+                        | _ @
+                        || |@
+     exclamation point  ||_|@
+                        |(_)@
+                        |   @@
+                        | _ _ @
+                        |( | )@
+          double quote  | V V @
+                        |  $  @
+                        |     @@
+                        |   _ _   @
+                        | _| | |_ @
+           number sign  ||_  .  _|@
+                        ||_     _|@
+                        |  |_|_|  @@
+                        |    @
+                        | ||_@
+           dollar sign  |(_-<@
+                        |/ _/@
+                        | || @@
+
+Notice that each FIGcharacter occupies the same number of lines (6 lines, in
+this case), which must also be expressed in the header line as the Height
+parameter.
+
+Also notice that for every FIGcharacter, there must be a consistent width
+(length) for each line once the endmarks are removed.  To do otherwise would
+be an error.
+
+Be aware of the vertical alignment of each FIGcharacter within its height,
+so that all FIGcharacters will be properly lined up when printed.
+
+If one of the last sub-characters in a particular FIGcharacter is "@", you
+should use another character for the endmark in that FIGcharacter so that
+the intended "@" is not interpreted as an endmark.  "#" is a common
+alternative.
+
+Load a few existing FIGfonts into your favorite text editor for other
+examples.
+
+
+REQUIRED FIGCHARACTERS
+
+Some FIGcharacters are required, and must be represented in a specific order.
+Specifically: all of the printable character codes from ASCII shown in the
+table below, in order, plus character codes 196, 214, 220, 228, 246, 252,
+and 223, in that order.  In Latin-1, these extra 7 characters represent the
+following German characters: umlauted "A", "O", "U", "a", "o" and "u"; and
+also "ess-zed".
+
+    Printable portion of the ASCII character set:
+
+        32 (blank/space) 64 @             96  `
+        33 !             65 A             97  a
+        34 "             66 B             98  b
+        35 #             67 C             99  c
+        36 $             68 D             100 d
+        37 %             69 E             101 e
+        38 &             70 F             102 f
+        39 '             71 G             103 g
+        40 (             72 H             104 h
+        41 )             73 I             105 i
+        42 *             74 J             106 j
+        43 +             75 K             107 k
+        44 ,             76 L             108 l
+        45 -             77 M             109 m
+        46 .             78 N             110 n
+        47 /             79 O             111 o
+        48 0             80 P             112 p
+        49 1             81 Q             113 q
+        50 2             82 R             114 r
+        51 3             83 S             115 s
+        52 4             84 T             116 t
+        53 5             85 U             117 u
+        54 6             86 V             118 v
+        55 7             87 W             119 w
+        56 8             88 X             120 x
+        57 9             89 Y             121 y
+        58 :             90 Z             122 z
+        59 ;             91 [             123 {
+        60 <             92 \             124 |
+        61 =             93 ]             125 }
+        62 >             94 ^             126 ~
+        63 ?             95 _
+
+    Additional required Deutsch FIGcharacters, in order:
+
+        196 (umlauted "A" -- two dots over letter "A")
+        214 (umlauted "O" -- two dots over letter "O")
+        220 (umlauted "U" -- two dots over letter "U")
+        228 (umlauted "a" -- two dots over letter "a")
+        246 (umlauted "o" -- two dots over letter "o")
+        252 (umlauted "u" -- two dots over letter "u")
+        223 ("ess-zed" -- see FIGcharacter illustration below)
+                                      ___
+                                     / _ \
+                                    | |/ /
+                  Ess-zed >>--->    | |\ \
+                                    | ||_/
+                                    |_|
+
+If you do not wish to define FIGcharacters for all of those required above,
+you MAY create "empty" FIGcharacters in their place by placing endmarks flush
+with the left margin.  The Deutsch FIGcharacters are commonly created as
+empty.  If your FIGfont includes only capital letters, please copy them to
+the appropriate lowercase locations, rather than leaving lowercase letters
+empty.  A FIGfont which does not include at least all ASCII letters, a space,
+and a few basic punctuation marks will probably frustrate some users.  (For
+example "@" is more frequently desired as a FIGcharacter than you may think,
+since Email addresses may be written as FIGures.)
+
+
+CODE TAGGED FIGCHARACTERS
+
+After the required FIGcharacters, you may create FIGcharacters with any
+character code in the range of -2147483648 to +2147483647. (Over four
+billion possibilities, which is "virtual infinity" for this purpose.)
+One exception: character code -1 is NOT allowed for technical reasons.
+It is advisable to assign character codes such that the appearance of your
+FIGcharacters matches the expectations of ASCII/Latin-1/Unicode, with a few
+exceptions:
+
+    1) If a FIGcharacter with code 0 is present, it is treated
+       specially.  It is a FIGfont's "missing character".  Whenever
+       the FIGdriver is told to print a character which doesn't exist
+       in the current FIGfont, it will print FIGcharacter 0.  If there
+       is no FIGcharacter 0, nothing will be printed.
+
+    2) If a FIGfont contains a non-Latin alphabet in character codes
+       in the ASCII range 32-126 (which is discouraged), we have found
+       it helpful to include a human-readable translation table as one
+       of the FIGcharacters instead of a "glyph".  Typically, the "~"
+       would contain this table.  The translation table FIGcharacter
+       would contain a list of all the special characters in the
+       FIGfont, along with the ASCII characters to which they
+       correspond.  Keep this table no more than 79 columns wide.
+       (Thanks to Gedaliah Friedenberg for this idea.)
+
+    3) In more extensive Unicode fonts, you can assign a negative
+       character code (other than -1) to one or more translation
+       tables, similar to #2 above.  (All Unicode character codes are
+       positive.)  And, you will most likely suggest within the
+       comments that a user access one of several control files (See
+       "CONTROL FILES" below) to gain access to Latin-2, Latin-3, or
+       other 8-bit standardized character sets.  The control files may
+       redirect the "~" character to one of the negative character codes so
+       that the translation table would display the table when "~" is
+       given for input.  Doing this allows you to still have a "~"
+       FIGcharacter for those who do not use a control file.
+
+Those FIGcharacters which are not required must have an explicit character
+code in a separate line preceding them, called a "code tag".  A code tag
+contains the value of the character code, followed by whitespace (a few
+spaces), and perhaps an optional comment.  The comment is usually the name of
+the FIGcharacter.  The Unicode Consortium has assigned formal names to all
+officially accepted characters, and these may be used.  An entire code tag,
+including the comment, should not occupy more than 95 columns.  (Over 100
+characters here may make older versions of FIGlet crash.)
+
+Here is an example, showing two code tagged FIGcharacters after the last two
+required Deutsch FIGcharacters.  Again, the line drawn below consisting of
+"|" represents the left margin of your editor, and is NOT part of the FIGfont.
+
+                        | _   _ @
+                        |(_) (_)@
+                        || | | |@
+                        || |_| |@
+                        | \__,_|@
+                        |       @@
+                        |  ___ @
+                        | / _ \@
+                        || |/ /@
+                        || |\ \@
+                        || ||_/@
+                        ||_|   @@
+                        |161  INVERTED EXCLAMATION MARK
+                        | _ @
+                        |(_)@
+                        || |@
+                        || |@
+                        ||_|@
+                        |   @@
+                        |162  CENT SIGN
+                        |   _  @
+                        |  | | @
+                        | / __)@
+                        || (__ @
+                        | \   )@
+                        |  |_| @@
+
+
+A character code may be expressed in decimal (as shown above, numbers we're
+all familiar with), or in Octal (seldom used) or in hexadecimal.
+
+Character codes expressed in octal must be preceded by "0" (zero), and if
+negative, "-" (minus) must precede the "0".  There are eight octal digits:
+01234567.  You may recall octal numbers from school as "base 8 numbers".
+
+Character codes expressed in hexadecimal must be preceded by "0x" or "0X".
+(That's also a zero.)  If negative, the "-" must precede the "0x".  There are
+16 hexadecimal digits: 01234567890ABCDEF.  (The "letter-digits" may also be
+lowercase.)  Hexadecimal is "base 16".
+
+It is common to express character codes less than 256 (in the range of an
+8-bit character set) as decimal, while FIGfonts which extend into the Unicode
+range would have character codes expressed in hexadecimal.  This is because
+the Unicode Standard expresses character codes in hexadecimal, which is
+helpful for programmers.
+
+The code tagged FIGcharacters may be listed in any order, but simple
+sequential order is recommended.
+
+If two or more FIGcharacters have the same character code, the last one in
+the FIGfont is the one used.  It is common for the Deutsch FIGcharacters to
+be given twice in a FIGfont, just to maintain a consistent order for the
+Latin-1 range (128 to 255).
+
+It is not advisable to assign character codes in the range of 1 to 31, since
+this range includes control characters in ASCII.  Character code 127 is a
+delete in ASCII, and is also not advised.  Character codes 128 to 159 are
+additional control characters in Latin-1, and they too should not be used.
+All of the above are legal, technically, but are not part of what is legal
+for input, so they could only be accessed by use of a control file.
+(See "CONTROL FILES" below.)  If you are still tempted to use them, consider
+negative character codes instead, which are meaningless in all standardized
+character sets.
+
+Again, the character code -1 is illegal for technical reasons.
+
+
+NOTES - AVOIDING ERRORS AND GENERAL ADVICE
+=====   ======== ====== === ======= ======
+
+It is very important that every character in a font has the same height, and,
+once the endmarks are removed, that all the lines constituting a single
+FIGcharacter have the same length.  Be careful also that no lines in the font
+file have trailing blanks (spaces), as the FIGdriver will take these to be
+the endmarks.  (FIGWin 1.0 will not consider blanks to be endmarks.)
+
+Errors in a FIGfont can be detected by using the "chkfont" program,
+part of the standard FIGlet package, and also available, as of this
+writing from http://www.figlet.org/
+…
+For FIGWin users, the FIGWin program will report errors when a FIGfont is
+read in; it is less forgiving than FIGlet, which can produce nonsense if the
+FIGfont is incorrectly formatted.
+
+Remember that sub-characters outside of the ASCII range will not necessarily
+display the same way on your system as on others.
+
+The blank (space) FIGcharacter should usually consist of one or two columns
+of hardblanks and nothing else; slanted fonts are an exception to this rule.
+If the space FIGcharacter does not contain any hardblanks, it will disappear
+when horizontal fitting (kerning) or smushing occurs.
+
+Again, if you design a FIGfont, please let us know!
+
+
+CONTROL FILES
+======= =====
+
+A FIGfont control file is a separate text file, associated with one or more
+FIGfonts, that indicates how to map input characters into FIGfont character
+codes.  By default, FIGdrivers read single bytes from the input source and
+interpret them as Latin-1 FIGcharacters.
+
+FIGlet version 2.2 (and later) can optionally interpret its input as DBCS or
+UTF-8 characters, making it possible to access FIGcharacters with codes
+outside the Latin-1 range (greater than 255).
+
+In addition, though, all versions of FIGlet can use control files to
+transform specific character codes (or ranges of codes) as other codes
+(or ranges).  Multiple control files can be specified, in which case multiple
+stages of transformation are performed.
+
+The filename of a control file always ends with ".flc".
+
+CONTROL FILE FORMAT
+
+Control files contain several kinds of lines.  Lines beginning with "#", as
+well as blank lines, are comment lines and are ignored.  All other lines are
+command lines, with one of the following formats:
+
+    t inchar outchar
+    t inchar1-inchar2 outchar1-outchar2
+    number number
+    f
+    h
+    j
+    b
+    u
+    g{0|1|2|3} {94|96|94x94} [char]
+    g{L|R} {0|1|2|3}
+
+where "inchar", "outchar", and "char" are either Latin-1 characters
+representing their own codes, or else are numeric character codes preceded by
+a "\" character; and "number" is a numeric character code with no preceding
+"\" character.
+
+Thus "A" represents the code 65, as does "\65", and "\0x100" represents the
+code 256 (100 in hexadecimal).  In addition, "\ " (backslash followed by a
+space) represents the code 32 (space), and the following backslash sequences
+are also understood:
+
+    \a        code 7 (a bell/alert)
+    \b        code 8 (a backspace)
+    \e        code 27 (an ESC character)
+    \f        code 12 (a form feed)
+    \n        code 10 (a newline/line feed)
+    \r        code 13 (a carriage return)
+    \t        code 9 (a horizontal tab)
+    \v        code 11 (a vertical tab)
+    \\        code 92 (a backslash)
+
+All of these combinations except perhaps "\\" are very unlikely to be used,
+but they are provided just in case they are needed.
+
+Whitespace characters are used between "t" and "inchar" and between "inchar"
+and "outchar", but not around the "-" characters used in the second type of
+"t" command.
+
+The term "string" refers to any number of characters represented in the
+format given above.  The characters begin after the whitespace following the
+letter "s", and continue to the end of the line.
+
+Anything following the first letter of an "f", "h", "j", or "u" command is
+ignored.
+
+The first type of "t" command transforms characters with the code "inchar"
+into characters with the code "outchar". The second type of "t" command
+transforms characters in the range "inchar1" to "inchar2" as the
+corresponding codes in the range "outchar1" to "outchar2". Both ranges must
+be of the same size.  The form "number number" is equivalent to a "t"
+command of the first type, and is provided for compatibility with the mapping
+tables issued by the Unicode Consortium.
+
+Multiple transformation stages can be encoded in a single control file by
+using "f" commands to separate the stages.
+
+Versions of FIGlet before 2.1 required that the first line of a control file
+consist of the signature string "flc2a".  This signature line is still
+permitted in FIGlet 2.2 and later versions, but is no longer required.
+
+Here is an example of a control file.  The blanks at the beginning of each
+line are for readability only, and are not part of the file.
+
+The following control file:
+
+    flc2a
+    t # $
+    t A-Z a-z
+
+will map the "#" character to "$", and will also convert uppercase ASCII to
+lowercase ASCII.
+
+If a number of consecutive "t" commands are given, then for each character
+processed, only the first applicable command (if any) will be executed.
+Consider this control file:
+
+    t A B
+    t B A
+
+It will swap the characters "A" and "B".  If the FIGdriver reads an "A", the
+first command will change "A" to "B", in which case the second will not be
+executed.  If the FIGdriver reads a "B", the first command will have no
+effect, and the second command will change "B" to "A".  Here is another
+control file:
+
+    t A B
+    t A C
+
+In this example, the second line is never executed.  In short, a sequence of
+"t" lines "does what it ought to".
+
+More complex files, in which a single character is acted upon by several "t"
+commands, can be set up using an "f" command. For example:
+
+    flc2a
+    t a-z A-Z
+    f
+    t Q ~
+
+This control file specifies two transformation stages.  In the first stage,
+lowercase ASCII letters are changed to their uppercase equivalents.  The
+second stage maps any Q (whether original or a converted "q") into the "~"
+character. If the "f" command were omitted, "q" characters would remain "Q"
+and not be converted to "~".
+
+EXTENDED COMMANDS
+
+The "h", "j", "b", "u", and "g" commands are only understood by FIGlet
+version 2.2 or later.  They control how a FIGdriver interprets bytes in the
+input.  By default, the FIGdriver interprets each byte of input as a distinct
+character.  This mode is suitable for most character encodings.  All these
+commands are logically acted on before any other control file commands, no
+matter where in the sequence of control files they appear.  They are also
+mutually exclusive; if more than one of these commands is found, only the
+last is acted on.  Multiple "g" commands are permitted, however.
+
+The "h" command forces the input to be interpreted in HZ mode, which is used
+for the HZ character encoding of Chinese text.  In this mode, the sequence
+"~{" (which is removed from the input) signals that all following characters
+are two bytes long until the sequence "~}" is detected. In addition, the
+sequence "~~" is changed to just "~", and all other two-byte sequences
+beginning with "~" are removed from the input. The character code
+corresponding to a two-byte character is:
+
+    first character * 256 + second character
+
+The "j" command forces the input to be interpreted in Shift-JIS mode (also
+called "MS-Kanji mode").  Input bytes in the ranges 128-159 and 224-239 are
+read as the high-order byte of a two-byte character; all other bytes are
+interpreted as one-byte characters.  The value of a two-byte character is
+determined in the same way as in HZ mode.
+
+The "b" command forces the input to be interpreted in DBCS mode, which is
+suitable for processing HZ or Shift-GB Chinese text or Korean text.  Input
+bytes in the ranges 128-255 are read as the high-order byte of a two-byte
+character; all other bytes are interpreted as one-byte characters.  The
+value of a two-byte character is determined in the same way as in HZ mode.
+
+The "u" command forces the input to be interpreted in UTF-8 mode, which
+causes any input byte in the range 0x80 to 0xFF to be interpreted as the
+first byte of a multi-byte Unicode (ISO 10646) character.  UTF-8 characters
+can be from 1 to 6 bytes long.  An incorrectly formatted sequence is
+interpreted as the character 128 (normally an unused control character).
+
+Otherwise, the input is allowed to contain ISO 2022 escape sequences, which
+are decoded to generate appropriate character codes.  These character codes
+are *not* a subset of Unicode, but may be more useful in processing East
+Asian text.  A brief explanation of ISO 2022 is given here in order to
+clarify how a FIGdriver should interpret it.  The "g" command provides
+information for the ISO 2022 interpreter, and is explained below.
+
+ISO 2022 text is specified using a mixture of registered character sets.
+At any time, up to four character sets may be available.  Character sets
+have one of three sizes:  single-byte character sets with 94 characters
+(e.g. ASCII), single-byte character sets with 96 characters (e.g. the top
+halves of ISO Latin-1 to Latin-5), or double-byte character sets with
+94 x 94 characters (e.g. JIS 0208X-1983).  Each registered character set has
+a standard designating byte in the range 48 to 125; the bytes are unique withi
+n character set sizes, but may be reused across sizes.  For example, byte 66
+designates the 94-character set ASCII, the 96-character set ISO Latin-2 (top
+half), and the 94 x 94 Japanese character set JIS 0208X-1983. In this
+document, the designating byte of a character set will be represented by <D>.
+
+The four available character sets are labeled G0, G1, G2, and G3.  Initially,
+G0 is the 94-character set ASCII, and G1 is the 96-character set ISO Latin-1
+(top half).  The other character sets are unassigned.  The following escape
+sequences (where ESC = the byte 27) specify changes to the available
+character sets:
+
+        ESC ( <D>    Set G0 to the 94-character set <D>
+        ESC ) <D>    Set G1 to the 94-character set <D>
+        ESC * <D>    Set G2 to the 94-character set <D>
+        ESC + <D>    Set G3 to the 94-character set <D>
+        ESC - <D>    Set G1 to the 96-character set <D>
+        ESC . <D>    Set G2 to the 96-character set <D>
+        ESC / <D>    Set G3 to the 96-character set <D>
+        ESC $ <D>    Set G0 to the 94 x 94 character set <D>
+        ESC $ ( <D>    Set G0 to the 94 x 94 character set <D>
+        ESC $ ) <D>    Set G1 to the 94 x 94 character set <D>
+        ESC $ * <D>    Set G2 to the 94 x 94 character set <D>
+        ESC $ + <D>    Set G3 to the 94 x 94 character set <D>
+
+
+Note that G0 may not be a 96-character set, and that there are two ways to
+specify a 94 x 94 character set in G0, of which the first is deprecated.
+
+ISO 2022 decoding affects input bytes in the ranges 33 to 126 and 160 to 255,
+known as "the left half" and "the right half" respectively.  All other bytes,
+unless they belong to a control sequence shown in this document, remain
+unchanged.  Initially, the left half is interpreted as character set G0,
+and the right half as character set G1.  This can be changed by the following
+control sequences:
+
+        SI (byte 15)    Interpret the left half as G1 characters
+        SO (byte 14)    Interpret the left half as G0 characters
+        ESC n           Interpret the left half as G2 characters
+        ESC o           Interpret the left half as G3 characters
+        ESC ~           Interpret the right half as G1 characters
+        ESC }           Interpret the right half as G2 characters
+        ESC |           Interpret the right half as G3 characters
+        SS2 (byte 142)  Interpret next character only as G2
+        ESC N           Interpret next character only as G2
+        SS3 (byte 143)  Interpret next character only as G3
+        ESC O           Interpret next character only as G3
+
+
+This rich schema may be used in various ways.  In ISO-2022-JP, the Japanese
+flavor of ISO 2022, only the bytes 33-126 and the G0 character set is used,
+and escape sequences are used to switch between ASCII, ISO-646-JP (the
+Japanese national variant of ASCII), and JIS 0208X-1983.  In other versions,
+the G1 character set has 94 x 94 size, and so any byte in the range 160-255
+is automatically the first byte of a double-byte character.
+
+FIGdrivers that support ISO 2022 do so in the following way.  Each character i
+is decoded and assigned to a character set <D>.
+
+    If the character belongs to a 94-bit character set,
+        then if its value exceeds 128, it is reduced by 128,
+        and the value 65536 * <D> is added to it,
+            unless <D> is 66 (ASCII).
+    If the character belongs to a 96-bit character set,
+        then if its value is less than 128, it is increased by 128,
+        and the value 65536 * <D> is added to it,
+            unless <D> is 65 (ISO Latin-1).
+    If the character belongs to a 94 x 94 character set,
+        then the value is the sum of:
+            the first byte * 256,
+            plus the second byte,
+            plus the value 65536 * <D>.
+
+
+Thus, the character code 65 ("A") in ASCII remains 65, the character code
+196 in ISO Latin-1 ("A-umlaut") remains 196, the character code 65 (0x41)
+in ISO-646-JP (whose <D> is 74 = 0x4A) becomes 0x4A0041 =4849729, and the
+two-byte sequence 33 33 (0x21 0x21) in JIS 0208X-1983 (whose <D> is
+65 = 0x41) becomes 0x412121 = 4268321.  These codes may be used in compiling
+FIGfonts suitable for use with ISO 2022 encoded text.
+
+The initial settings of G0 through G3 and their assignments to the left half
+and the right half can be altered in a control file by using "g" commands,
+as follows:
+
+    g {0|1|2|3} {94|96|94x94} [<D>]
+
+specifies that one of G0-G3 is a 94, 96, or 94x94 character set with
+designating character <D>.  If no designating character is specified, then a
+<D> value of zero is assumed.
+
+For example, the list of control commands:
+
+    g 0 94 B
+    g 1 96 A
+
+sets the G0 character set to ASCII (94-character set "B") and the G1
+character set to the top half of Latin-1 (96-character set "A"). (This is the
+default setting).
+
+To change the initial assignments of G0 to the left half and G1 to the right
+half, "g" commands of the form
+
+    g {L|R} {0|1|2|3}
+
+For example, the command:
+
+    g R 2
+
+causes right-half bytes (in the range 160-255) to be interpreted as G2.
+Whether these bytes are interpreted singly or in pairs depends on the type
+of character set that is currently available as G2.
+
+Spaces may be freely used or omitted in "g" commands.
+
+The standard FIGlet distribution contains mapping tables for Latin-2 (ISO 8859-2),
+Latin-3 (ISO 8859-3), Latin-4 (ISO 8859-4), and Latin-5 (ISO 8859-9).  They
+can be used with the font "standard.flf", which contains all the characters
+used in these standards.
+
+
+STANDARDIZED CAPABILITIES OF CURRENT AND FUTURE FIGDRIVERS
+============ ============ == ======= === ====== ==========
+
+We assert the following as the "Law" of our intentions:
+
+PROFIT
+
+All future FIGdrivers shall be FREE OF CHARGE to the general public via the
+Internet.  Any advertisements of other works by the author must be in
+documentation only, and limited to ONE "screenful", and shall not appear by
+normal program behavior, nor interfere with normal behavior.  No FIGdriver
+shall disable itself after a set period of time or request "donations".
+No FIGdriver shall offer any other FIGdriver with improved capability for
+creating FIGures in exchange for money.
+
+REQUIRED FEATURES OF FUTURE VERSIONS
+
+Future FIGdrivers must read and process FIGfont files as described in this
+document, but are not necessarily expected to process control files, smush,
+perform fitting or kerning, perform vertical operations, or even produce
+multiple lines in output FIGures.
+
+FIGDRIVER NAMES
+
+Future FIGdrivers must be named to include capitalized "FIG" and shall have
+an incremental version number specific to its own platform.
+
+BACKWARDS COMPATIBILITY OF FUTURE VERSIONS
+
+Any future FIGdriver created for the same platform as an existing FIGdriver,
+and using the same name as the existing FIGdriver, shall be considered a new
+version of the preceding FIGdriver, and shall contain all historical comments
+of updates to past versions on the same platform, and shall have full
+capability of the preceding versions.  If the source code is not provided to
+the general public, it shall be at least provided to any potential developers
+of later versions, and such comments relating to past versions shall be
+accessible to any user by other means or documentation.  If a new program is
+created on a platform that already has an existing FIGdriver, it must be
+given a new and distinct name.  This allows multiple FIGdrivers to exist for
+the same platform with different capabilities.
+
+The format of FIGfonts may not be modified to be non-backwards compatible
+UNLESS:
+
+    1) The new format is easily editable as an ASCII text file,
+       beginning with the characters "flf" followed by a sequential
+       number.
+
+    2) At least all of the same information can be derived from the
+       new format as the prior format (currently "flf2").  This
+       includes the main comments which give credit to the FIGfont
+       designer.
+
+    3) Individuals are found who are willing and have the ability to
+       either port or develop versions for at least UNIX, DOS,
+       Windows, and Amiga which will read both the new formats AND the
+       prior format (currently "flf2"), and retain the capability of
+       past versions.  It is intended that this will be expanded to
+       include Macintosh if a GUI version exists.  This list of
+       required operating systems may be reduced if an operating
+       system falls out of popularity or increased if a new operating
+       system for which there is a FIGdriver comes into greater
+       popularity, according to the consensus of opinions of past
+       developers for the most popular operating systems.
+
+    4) A C, Java, or other version must always exist which can
+       receive input and instructions either from a command line, a
+       file, or directly over the internet so that FIGures can be
+       obtained from internet-based services without the need to
+       download any FIGdriver.
+
+    5) All existing FIGfonts available from the "official" point of
+       distribution (http://www.figlet.org/),
+       must be converted to the new format, and offered for download
+       alongsidethe new versions.
+
+THE FUNCTION OF WORD WRAPPING
+
+All future FIGdrivers should duplicate these behaviors, unless a version is
+only capable of outputting one-line FIGures, which is acceptable as long no
+preceding versions exist for its platform which can output multiple-line
+FIGures.
+
+FIGdrivers which perform word wrapping do so by watching for blanks (spaces)
+in input text, making sure that the FIGure is no more wide than the maximum
+width allowed.
+
+Input text may also include linebreaks, so that a user may specify where
+lines begin or end instead of relying on the word wrapping of the FIGdriver.
+(Linebreaks are represented by different bytes on different platforms, so
+each FIGdriver must watch for the appropriate linebreaks for its particular
+platform.)
+
+When a FIGdriver word wraps and there are several consecutive blanks in input
+text where the wrapping occurred, the FIGdriver will disregard all blanks
+until the next non-blank input character is encountered.  However, if blanks
+in input text immediately follow a linebreak, or if blanks are the first
+characters in the input text, the blanks will be "printed", moving any
+visible FIGcharacters which follow on the same output line to the right.
+Similarly, if an image is right-aligned, and blanks immediately precede
+linebreaks or the end of input text, a FIGdriver will move an entire line of
+output FIGcharacters to the left to make room for the blank FIGcharacters
+until the left margin is encountered.  (If the print direction is
+right-to-left, everything stated in this paragraph is reversed.)
+
+Word processing programs or text editors usually behave similarly in all
+regards to word wrapping.
+
+GENERAL INTENT FOR CROSS-PLATFORM PORTABILITY
+
+Currently, all versions of FIGlet are compiled from C code, while FIGWin 1.0
+is written in Visual Basic.  Over time it is intended that a later version of
+FIGWin will be created using a GUI C programming language, and that the
+FIGlet C code shall continue to be written to be easily "plugged in" to a
+GUI shell.  It is preferable for developers of FIGdrivers for new platforms
+to use C or a GUI version of C, so that when the core rendering engine of
+FIGlet is updated, it will be portable to other platforms.
+
+CONTROL FILE COMMANDS
+
+New control file commands may be added to later versions of this standard.
+However, the commands "c", "d", and "s" are permanently reserved and may
+never be given a meaning.
+
+FILE COMPRESSION
+
+FIGfonts (and control files) are often quite long, especially if many
+FIGcharacters are included, or if the FIGcharacters are large.  Therefore,
+some FIGdrivers (at present, only FIGlet version 2.2 or later) allow
+compressed FIGfonts and control files.
+
+The standard for FIG compression is to place the FIGfont or control file into
+a ZIP archive.  ZIP archives can be created by the proprietary program PKZIP
+on DOS and Windows platforms, or by the free program Info-ZIP ZIP on almost
+all platforms.  More information on ZIP can be obtained at
+http://www.cdrom.com/pub/infozip/Info-Zip.html .
+
+The ZIP archive must contain only a single file.  Any files in the archive
+after the first are ignored by FIGdrivers.  In addition, the standard
+extension ".zip" of the archive must be changed to ".flf" or ".flc" as
+appropriate.  It does not matter what the name of the file within the
+archive is.
+
+
+
+CHART OF CAPABILITIES OF FIGLET 2.2 AND FIGWIN 1.0
+===== == ============ == ====== === === ====== ===
+
+The following chart lists all capabilities which are either new with the
+release of both FIGdrivers, or is not a common capability among both.
+
+                                              FIGlet 2.2    FIGWIN 1.0
+    Interpreting the Full_Layout parameter:     Yes           Yes
+    Universal smushing:                         Yes           Yes
+    Supporting multi-byte input text formats:   Yes           No
+    Processing control files:                   Yes           No
+    Changing default smushing rules:            Yes           No
+    Bundled with a GUI editor of FIGfonts:      No            Yes
+    Vertical fitting and smushing:              No            Yes
+
+                 ___________           __               _
+                 \_   _____/ ____     |__| ____ ___ __ | |
+                  |    __)_ /    \    |  |/  _ <   |  || |
+                  |        \   |  \   |  (  <_> )___  | \|
+                 /_______  /___|  /\__|  |\____// ____| __
+                         \/     \/\______|      \/      \/