aboutsummaryrefslogtreecommitdiffstats
path: root/figfont.txt
diff options
context:
space:
mode:
authorJonathan McCrohan <jmccrohan@gmail.com>2012-05-08 14:48:01 +0100
committerJonathan McCrohan <jmccrohan@gmail.com>2012-05-08 14:48:01 +0100
commite8ed9bd2e7597f7aefdfc7004a308f0e291c3ca7 (patch)
treedaaa342bcc828ba94f826c82a133da10f4a09567 /figfont.txt
downloadfiglet-e8ed9bd2e7597f7aefdfc7004a308f0e291c3ca7.tar.gz
Imported Upstream version 2.2.2upstream/2.2.2
Diffstat (limited to '')
-rw-r--r--figfont.txt1687
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
+
+ ___________ __ _
+ \_ _____/ ____ |__| ____ ___ __ | |
+ | __)_ / \ | |/ _ < | || |
+ | \ | \ | ( <_> )___ | \|
+ /_______ /___| /\__| |\____// ____| __
+ \/ \/\______| \/ \/