· 7 years ago · Oct 20, 2018, 07:58 AM
1 _____ ___ ____ __ _
2 | ___||_ _|/ ___| / _| ___ _ __ | |_ ___ _
3 | |_ | || | _ | |_ / _ \ | '_ \ | __|/ __|(_)
4 | _| | || |_| || _|| (_) || | | || |_ \__ \ _
5 |_| |___|\____||_| \___/ |_| |_| \__||___/(_)
6
7 The FIGfont Version 2 FIGfont and FIGdriver Standard
8 === ======= ======= = ======= === ========= ========
9 Draft 2.0 Copyright 1996, 1997
10 by John Cowan and Paul Burton
11 Portions Copyright 1991, 1993, 1994
12 by Glenn Chappell and Ian Chai
13 May be freely copied and distributed.
14
15 _____ __ __
16 / ___/__ ___ / /____ ___ / /____
17/ /__/ _ \/ _ \/ __/ -_) _ \/ __(_-<
18\___/\___/_//_/\__/\__/_//_/\__/___/
19
20 INTRODUCTION
21 BASIC DEFINITIONS AND CONCEPTS
22 "FIGfont"
23 "FIGcharacters" and "Sub-characters"
24 "FIGdriver"
25 "FIGure"
26 "FIG"
27 "Layout Modes"
28 "Smushing Rules"
29 "Hardblanks"
30 CREATING FIGFONTS
31 The Header Line
32 Interpretation of Layout Parameters
33 Setting Layout Parameters Step-by-Step
34 FIGfont Comments
35 FIGcharacter Data
36 - Basic Data Structure
37 - Character Codes
38 - Required FIGcharacters
39 - Code Tagged FIGcharacters
40 NOTES - AVOIDING ERRORS AND GENERAL ADVICE
41 CONTROL FILES
42 Standard Format
43 Extended Commands
44 STANDARDIZED CAPABILITIES OF CURRENT AND FUTURE FIGDRIVERS
45 CHART OF CAPABILITIES OF FIGLET 2.2 AND FIGWIN 1.0
46
47
48INTRODUCTION
49============
50
51This document specifies the format of font files, and the associated control
52files, used by the FIGlet and FIGWin programs (FIGdrivers). It is written
53for designers who wish to build fonts (FIGfonts) usable by either program,
54and also serves as a standard for development of future versions or similar
55FIGdrivers. Some features explained here are not supported by both programs.
56See separate documentation to learn how to use FIGlet or FIGWin.
57
58NOTE: FIGWin 1.0 is packaged with a program called FIGfont Editor for Windows
591.0, which is just that. It does not require a complete understanding of
60this document to create FIGfonts. However it is a good idea to become
61familiar with the "BASIC DEFINITIONS AND CONCEPTS" information before using
62it.
63
64If you design a FIGfont, please send an e-mail announcement to
65<figletfonts@onelist.com>, the FIGlet fonts mailing list, and email a copy
66to ianchai@usa.net for him to put it at the ftp site.
67
68BASIC DEFINITIONS AND CONCEPTS
69===== =========== === ========
70
71"FIGfont"
72
73A FIGfont is a file which represents the graphical arrangement of characters
74representing larger characters. Since a FIGfont file is a text file, it can
75be created with any text editing program on any platform. The filename of a
76FIGfont file must end with ".flf", which stands for "<F>IG<L>ettering
77<F>ont".
78
79
80"FIGcharacters" and "Sub-characters"
81
82Because FIGfonts describe large characters which consist of smaller
83characters, confusion can result when descussing one or the other.
84Therefore, the terms "FIGcharacter" and "sub-character" are used,
85respectively.
86
87
88"FIGdriver"
89
90The term FIGdriver is used in this document to encompass FIGlet, FIGWin, and
91any future programs which use FIGfonts.
92
93
94"FIGure"
95
96A FIGure (thusly capitalized) is an image created by a FIGdriver.
97
98
99"FIG"
100
101A bit of history:
102
103In Spring 1991, inspired by the Email signature of a friend named Frank, and
104goaded on by Ian Chai, Glenn Chappell wrote a nifty little 170-line "C"
105program called "newban", which would create large letters out of ordinary
106text characters. At the time, it was only compiled for UNIX. In hindsight,
107we now call it "FIGlet 1.0". FIGlet stands for <F>rank, <I>an, and <G>lenn's
108<let>ters. In various incarnations, newban circulated around the net for a
109couple of years. It had one font, which included only lowercase letters.
110
111In early 1993, Ian decided newban was due for a few changes, so together Ian
112and Glenn added the full ASCII character set, to start with. First, though,
113Ian had to find a copy of the source, since Glenn had tossed it away as not
114worth the disk space. Ian and Glenn discussed what could be done with it,
115decided on a general re-write, and, 7 months later, ended up with 888 lines
116of code, 13 FIGfonts and documentation. This was FIGlet 2.0, the first real
117release.
118
119To their great surprise, FIGlet took the net by storm. They received floods
120of "FIGlet is great!" messages and a new contributed FIGfont about once a
121week. To handle all the traffic, Ian quickly set up a mailing list, Daniel
122Simmons kindly offered space for an FTP site, several people volunteered to
123port FIGlet to non-Unix operating systems, ...and bug reports poured in.
124
125Because of these, and the need to make FIGlet more "international", Ian and
126Glenn released a new version of FIGlet which could handle non-ASCII character
127sets and right-to-left printing. This was FIGlet 2.1, which, in a couple of
128weeks, became figlet 2.1.1. This weighed in at 1314 lines, and there were
129over 60 FIGfonts.
130
131By late 1996, FIGlet had quite a following of fans subscribing to its mailing
132list. It had been ported to MS-DOS, Macintosh, Amiga, Apple II GS, Atari ST,
133Acorn and OS/2. FIGlet had been further updated, and there were nearly 200
134FIGfonts.
135
136John Cowan and Paul Burton are two FIGlet fans who decided to create new
137versions. While John wrote FIGlet version 2.2 using C, Paul wrote FIGWin
1381.0, the first true GUI (Windows) implementation of FIGlet, using Visual
139Basic. John and Paul worked together to add new features to FIGfont files
140which could be read by both programs, and together wrote this document, which
141we hope helps to establish consistency in FIGfonts and help with the creation
142of future FIGdrivers. FIGlet 2.2 has about 4800 lines of code, of which
143over half is a support library for reading compressed files.
144
145FIGlet 2.2 and FIGWin 1.0 both allow greater flexibility by use of new
146information which can be contained in FIGfont files without interfering with
147the function of older FIGdrivers.
148
149NOTE: The Macintosh version of FIGlet is still command-line driven as of this
150writing, and a GUI version is very much in demand. The FIGlet C code is
151written to be easily plugged in to a GUI shell, so it will be a relatively
152easy task for a Macintosh developer.
153
154
155"Layout Modes"
156
157A FIGdriver may arrange FIGcharacters using one of three "layout modes",
158which define the spacing between FIGcharacters. The layout mode for the
159horizontal axis may differ from the layout mode for the vertical axis. A
160default choice is defined for each axis by every FIGfont.
161
162The three layout modes are:
163
164 Full Size (Separately called "Full Width" or "Full Height".)
165
166 Represents each FIGcharacter occupying the full width or
167 height of its arrangement of sub-characters as designed.
168
169 Fitting Only (Separately called "Kerning" or "Vertical Fitting".)
170
171 Moves FIGcharacters closer together until they touch.
172 Typographers use the term "kerning" for this phenomenon
173 when applied to the horizontal axis, but fitting also
174 includes this as a vertical behavior, for which there is
175 apparently no established typographical term.
176
177 Smushing (Same term for both axes.)
178
179 Moves FIGcharacters one step closer after they touch, so that
180 they partially occupy the same space. A FIGdriver must decide
181 what sub-character to display at each junction. There are two
182 ways of making these decisions: by controlled smushing or by
183 universal smushing.
184
185 Controlled smushing uses a set of "smushing rules" selected by
186 the designer of a FIGfont. (See "Smushing Rules" below.)
187 Each rule is a comparison of the two sub-characters which must
188 be joined to yield what to display at the junction.
189 Controlled smushing will not always allow smushing to occur,
190 because the compared sub-characters may not correspond to any
191 active rule. Wherever smushing cannot occur, fitting occurs
192 instead.
193
194 Universal smushing simply overrides the sub-character from the
195 earlier FIGcharacter with the sub-character from the later
196 FIGcharacter. This produces an "overlapping" effect with some
197 FIGfonts, wherin the latter FIGcharacter may appear to be "in
198 front".
199
200 A FIGfont which does not specify any smushing rules for a
201 particular axis indicates that universal smushing is to occur
202 when smushing is requested. Therefore, it is not possible for
203 a FIGfont designer to "forbid" smushing. However there are
204 ways to ensure that smushing does not cause a FIGfont to be
205 illegible when smushed. This is especially important for
206 smaller FIGfonts. (See "Hardblanks" for details.)
207
208For vertical fitting or smushing, entire lines of output FIGcharacters are
209"moved" as a unit.
210
211Not all FIGdrivers do vertical fitting or smushing. At present, FIGWin 1.0
212does, but FIGlet 2.2 does not. Further, while FIGlet 2.2 allows the user to
213override the FIGfont designer's set of smushing rules, FIGWin 1.0 does not.
214
215NOTE: In the documentation of FIGlet versions prior to 2.2, the term
216"smushmode" was used to mean the layout mode, and this term further included
217the smushing rules (if any) to be applied. However, since the layout mode
218may or may not involve smushing, we are straying from the use of this
219somewhat misleading term.
220
221
222"Smushing Rules"
223
224Again, smushing rules are for controlled smushing. If none are defined to be
225active in a FIGfont, universal smushing occurs instead.
226
227Generally, if a FIGfont is "drawn at the borders" using sub-characters
228"-_|/\[]{}()<>", you will want to use controlled smushing by selecting from
229the rules below. Otherwise, if your FIGfont uses a lot of other
230sub-characters, do not select any rules and universal smushing will occur
231instead. (See "Hardblanks" below if your FIGfont is very small and would
232become illegible if smushed.) Experimentation is the best way to make these
233decisions.
234
235There are six possible horizontal smushing rules and five possible vertical
236smushing rules. Below is a description of all of the rules.
237
238NOTE: Ignore the "code values" for now. They are explained later.
239
240 The Six Horizontal Smushing Rules
241
242 Rule 1: EQUAL CHARACTER SMUSHING (code value 1)
243
244 Two sub-characters are smushed into a single sub-character
245 if they are the same. This rule does not smush
246 hardblanks. (See "Hardblanks" below.)
247
248 Rule 2: UNDERSCORE SMUSHING (code value 2)
249
250 An underscore ("_") will be replaced by any of: "|", "/",
251 "\", "[", "]", "{", "}", "(", ")", "<" or ">".
252
253 Rule 3: HIERARCHY SMUSHING (code value 4)
254
255 A hierarchy of six classes is used: "|", "/\", "[]", "{}",
256 "()", and "<>". When two smushing sub-characters are
257 from different classes, the one from the latter class
258 will be used.
259
260 Rule 4: OPPOSITE PAIR SMUSHING (code value 8)
261
262 Smushes opposing brackets ("[]" or "]["), braces ("{}" or
263 "}{") and parentheses ("()" or ")(") together, replacing
264 any such pair with a vertical bar ("|").
265
266 Rule 5: BIG X SMUSHING (code value 16)
267
268 Smushes "/\" into "|", "\/" into "Y", and "><" into "X".
269 Note that "<>" is not smushed in any way by this rule.
270 The name "BIG X" is historical; originally all three pairs
271 were smushed into "X".
272
273 Rule 6: HARDBLANK SMUSHING (code value 32)
274
275 Smushes two hardblanks together, replacing them with a
276 single hardblank. (See "Hardblanks" below.)
277
278
279 The Five Vertical Smushing Rules
280
281 Rule 1: EQUAL CHARACTER SMUSHING (code value 256)
282
283 Same as horizontal smushing rule 1.
284
285 Rule 2: UNDERSCORE SMUSHING (code value 512)
286
287 Same as horizontal smushing rule 2.
288
289 Rule 3: HIERARCHY SMUSHING (code value 1024)
290
291 Same as horizontal smushing rule 3.
292
293 Rule 4: HORIZONTAL LINE SMUSHING (code value 2048)
294
295 Smushes stacked pairs of "-" and "_", replacing them with
296 a single "=" sub-character. It does not matter which is
297 found above the other. Note that vertical smushing rule 1
298 will smush IDENTICAL pairs of horizontal lines, while this
299 rule smushes horizontal lines consisting of DIFFERENT
300 sub-characters.
301
302 Rule 5: VERTICAL LINE SUPERSMUSHING (code value 4096)
303
304 This one rule is different from all others, in that it
305 "supersmushes" vertical lines consisting of several
306 vertical bars ("|"). This creates the illusion that
307 FIGcharacters have slid vertically against each other.
308 Supersmushing continues until any sub-characters other
309 than "|" would have to be smushed. Supersmushing can
310 produce impressive results, but it is seldom possible,
311 since other sub-characters would usually have to be
312 considered for smushing as soon as any such stacked
313 vertical lines are encountered.
314
315
316"Hardblanks"
317
318A hardblank is a special sub-character which is displayed as a blank (space)
319in rendered FIGures, but is treated more like a "visible" sub-character when
320fitting or smushing horizontally. Therefore, hardblanks keep adjacent
321FIGcharacters a certain distance apart.
322
323NOTE: Hardblanks act the same as blanks for vertical operations.
324
325Hardblanks have three purposes:
326
327 1) Hardblanks are used to create the blank (space) FIGcharacter.
328
329 Usually the space FIGcharacter is simply one or two vertical
330 columns of hardblanks. Some slanted FIGfonts as shown below
331 have a diagonal arrangement of hardblanks instead.
332
333 2) Hardblanks can prevent "unreasonable" fitting or smushing.
334
335 Normally when fitting or smushing, the blank (space)
336 sub-character is considered "vacant space". In the following
337 example, a capital "C" FIGcharacter is smushed with a "minus"
338 FIGcharacter.
339 ______ ______
340 / ____/ / ____/
341 / / ____ >>-Becomes-> / / ____
342 / /___ /___/ / /__/___/
343 \____/ \____/
344
345 The FIGure above looks like a capital G. To prevent this, a
346 FIGfont designer might place a hardblank in the center of the
347 capital C. In the following example, the hardblank is
348 represented as a "$":
349 ______ ______
350 / ____/ / ____/
351 / / $ ____ >>-Becomes-> / / ____
352 / /___ /___/ / /___/___/
353 \____/ \____/
354
355 Using hardblanks in this manner ensures that FIGcharacters
356 with a lot of empty space will not be unreasonably "invaded"
357 by adjacent FIGcharacters. Generally, FIGcharacters such as
358 capital C, L or T, or small punctuation marks such as commas,
359 may contain hardblanks, since they may contain a lot of vacant
360 space which is "accessible" from either side.
361
362 3) Hardblanks can prevent smushing from making FIGfonts illegible.
363
364 This legitimate purpose of hardblanks is often overused. If a
365 FIGfont designer is absolutely sure that smushing "visible"
366 sub-characters would make their FIGfont illegible, hardblanks
367 may be positioned at the end of each row of sub-characters,
368 against the visible sub-characters, creating a barrier.
369
370 With older FIGdrivers, using hardblanks for this purpose meant
371 that FIGcharacters would have to be separated by at least one
372 blank in output FIGures, since only a hardblank could smush
373 with another hardblank. However with the advent of universal
374 smushing, this is no longer necessary. Hardblanks ARE
375 overriden by any visible sub-character when performing
376 universal smushing. Hardblanks still represent a "stopping
377 point", but only AFTER their locations are occupied.
378
379 NOTE: Earlier it was stated that universal smushing overrides
380 the sub-character from the former FIGcharacter with the
381 sub-character from the latter FIGcharacter. Hardblanks (and
382 blanks or spaces) are the exception to this rule; they will
383 always be overriden by visible sub-characters, regardless of
384 which FIGcharacter contains the hardblank. This ensures that
385 no visible sub-characters "disappear".
386
387 Therefore, one can design a FIGfont with a default behavior of
388 universal smushing, while the output FIGure would LOOK like
389 the effect of fitting, or even full size if additional
390 hardblanks are used. If a user "scales down" the layout mode
391 to fitting, the result would look like "extra spacing" between
392 FIGcharacters.
393
394 Taking this concept further, a FIGcharacter may also include
395 extra blanks (spaces) on the left side of each FIGcharacter,
396 which would define the FIGcharacter's width as slightly larger
397 than required for the visible sub-characters and hardblanks.
398 With such a FIGfont, a user who further "scales down" the
399 layout mode to full size would see even greater spacing.
400
401 These techniques prevent horizontal smushing from causing a
402 FIGfont to become illegible, while offering greater
403 flexibility of output to users.
404
405 NOTE: These techniques cannot be used to prevent vertical
406 smushing of visible sub-characters, since hardblanks are not
407 respected in the vertical axis. Although it is possible to
408 select only one vertical smushing rule which involves only
409 sub-characters which are not used in your FIGfont, it is
410 recommend that you do NOT do so. In our opinion, most users
411 would prefer to get what they ask for, rather than being
412 told, in effect: "I, the FIGfont designer, have decided that
413 you wouldn't like the results of vertical smushing, so I have
414 prevented you from trying it." Instead, we recommend setting
415 the default behavior to either fitting or full height, and
416 either allowing universal smushing, or selecting vertical
417 smushing rules which seem most appropriate. A user of your
418 FIGfont will quickly see why you did not choose smushing as
419 the default vertical layout mode, and will agree with you.
420
421
422"Character Sets" and "Character Codes"
423
424When you type using your keyboard, you are actually sending your computer a
425series of numbers. Each number must be interpreted by your computer so that
426it knows what character to display. The computer uses a list of definitions,
427called a "character set". The numbers which represent each character are
428 called "character codes".
429
430There are many character sets, most of which are internationally accepted as
431standards. By far, the most common character set is ASCII, which stands for
432"American Standard Code for Information Interchange". ASCII identifies its
433characters with codes ranging from 0 to 127.
434
435NOTE: The term "ASCII art" has become well-understood to mean artistic images
436which consist of characters on your screen (such as FIGures).
437
438For a list of the printable ASCII characters with the corresponding codes,
439see the section "REQUIRED CHARACTERS" below. The other ASCII codes in the
440range of 0 through 31 are "control characters" such as carriage-return
441(code 13), linefeed/newline (code 10), tab (code 9), backspace (code 8) or
442null (code 0). Code 127 is a delete in ASCII.
443
444Getting more technical for just a moment: A byte consisting of 8 bits (eight
445 1's or 0's) may represent a number from 0 to 255. Therefore, most computers
446have DIRECT access to 256 characters at any given time. A character set
447which includes 256 characters is called an 8-bit character set.
448
449For Latin-based languages, ASCII is almost always the first half of a larger
4508-bit character set. Latin-1 is the most common example of an 8-bit
451character set. Latin-1 includes all of ASCII, and adds characters with codes
452from 128 to 255 which include umlauted ("double-dotted") letters and
453characters with various other accents. In the United States, Windows and
454most Unix systems have Latin-1 directly available.
455
456Most modern systems allow the possibility of changing 8-bit character sets.
457On Windows systems, character sets are referred to as "code pages". There
458are many other character sets which are not mentioned here. DOS has its own
459character set (which also has international variants) that includes graphics
460characters for drawing lines. It is also an extension of ASCII.
461
462For some languages, 8-bit character sets are insufficient, particularly on
463East Asian systems. Therefore, some systems allow 2 bytes for each
464character, which multiplies the 256 possibilties by 256, resulting in 65536
465possible characters. (Much more than the world will ever need.)
466
467Unicode is a character set standard which is intended to fulfill the
468worldwide need for a single character set which includes all characters used
469worldwide. Unicode includes character codes from 0 to 65535, although at
470present, only about 22,000 characters have been officially assigned and named
471by the Unicode Consortium. The alphabets and other writing systems
472representable with Unicode include all Latin-alphabet systems, Greek,
473Russian and other Cyrillic-alphabet systems, Hebrew, Arabic, the various
474languages of India, Chinese, Japanese, Korean, and others. The existing
475Unicode symbols include chess pieces, astrological signs, gaming symbols,
476telephones, pointing fingers, etc. --- just about any type of FIGcharacter
477you may wish to create. Unicode is constantly (but slowly) being extended
478to handle new writing systems and symbols. Information on Unicode is
479available at http://www.unicode.org and at ftp://unicode.org .
480
481Unicode, Latin-1, and ASCII all specify the same meanings for overlapping
482character codes: ASCII 65 = Latin-1 65 = Unicode 65 = "A", formally known
483as "LATIN CAPITAL LETTER A".
484
485Since a keyboard usually has only about 100 keys, your computer may contain
486a program called a "keyboard map", which will interpret certain keystrokes
487or combinations of keystrokes as different character codes. Keyboard maps
488use "mapping tables" to make these determinations. The appropriate keyboard
489activity for a given character code may involve several keystrokes. Almost
490all systems are capable of handling at least 8-bit character sets (containing
491256 characters), so there is always an active keyboard map, at least for
492those characters which are not actually painted on the keys. (United States
493users may not even know that their computer can interpret special keystrokes.
494Such keystrokes may be something similar to holding down the ALT key while
495typing a character code on the numeric keypad. Try it!)
496
497Below are characters 160 through 255, AS REPRESENTED ON YOUR SYSTEM.
498
499 ¡¢£¤¥¦§¨©ª«¬Â®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÃÂÃÄÅÆÇÈÉÊËÌÃÃŽÃ
500 ÃÑÒÓÔÕÖ×ØÙÚÛÜÃÞßà áâãäåæçèéêëìÃîïðñòóôõö÷øùúûüýþÿ
501
502IMPORTANT NOTE: Depending on which character set is active on your system,
503you may see different characters. This document (like all computer
504documents) does not contains characters per se, only bytes. What you see
505above is your particular computer's representation of these byte values.
506In other words, your active character set. However, if it is Latin-1, the
507first visible character is an inverted "!", and the last is an umlauted "y".
508Although we can safely assume your computer has ASCII, it does not
509necessarily have the Latin-1 character set active.
510
511What does all this have to do with FIGfonts???
512
513First, it should be evident that it is best to use only ASCII characters for
514sub-characters when possible. This will ensure portability to different
515platforms.
516
517FIGlet has gained international popularity, but early versions were made to
518handle only FIGcharacters with assigned character codes corresponding to
519ASCII. So, over the years there have been four methods used to create
520"virtual mapping tables" within the program itself:
521
522 The first method was simply to create FIGcharacters which do not
523 look like the ASCII character set implies. For example, a
524 FIGfont might contain Greek letters, and within its comments, it
525 may say, "If you type A, you'll get a Greek Alpha" etc. With
526 the advent of newer features, it is preferable not to use this
527 method. Instead, when possible, add new FIGcharacters to
528 existing FIGfonts or create new FIGfonts with FIGcharacters coded
529 to match the expectations of ASCII/Latin-1/Unicode, and create an
530 appropriate control file. (See "CONTROL FILES" below.) Remember
531 that Unicode includes almost any character for which you may want
532 to create a FIGcharacter.
533
534 The second method was very specific, to accommodate the German
535 audience. A special option was added to the FIGlet program
536 which would re-route input characters "[", "\", and "]" to
537 umlauted A, O and U, while "{", "|", and "}" would become the
538 respective lowercase versions of these. Also, "~" was made to
539 become the s-z character when this special option was used. This
540 was called "the -D option." The addition of this feature meant
541 that all compatible FIGfonts must contain these Deutsch (German)
542 FIGcharacters, in addition to the ASCII FIGcharacters. Although
543 this option is still available in the most recent version, it is
544 no longer necessary, as the same result can be achieved by the
545 newer features described below. However, the requirement for
546 Deutsch FIGcharacters remains for backward compatibility. (Or at
547 least zero-width FIGcharacters in their place.)
548
549 Later, FIGlet was made to accept control files, which are quite
550 literally a form of mapping table. (See "CONTROL FILES" below.)
551 This was a significant advance for internationalization.
552
553 FIGlet 2.2 can now accept specially encoded formats of input
554 text which imply more than one byte per character.
555
556
557CREATING FIGFONTS
558======== ========
559
560NOTE: FIGWin 1.0 is packaged with a program called FIGfont Editor for Windows
5611.0, which is just that. There is no need to read further if you intend to
562use it. However, the section "CONTROL FILES" below is still relevant.
563
564Since a FIGfont file is a text file, it can be created with any text editing
565program on any platform, and will still be compatible with FIGdrivers on all
566operating systems, except that the bytes used to indicate the end of each
567text line may vary. (PC's use carriage return and linefeed at the end of
568each line, Macintosh uses carriage return only, and UNIX uses linefeed only.)
569
570This minor difference among operating systems is handled easily by setting
571your FTP program to ASCII mode during upload or download. So there is no
572need to be concerned about this as long as you remember to do this during
573file transfer.
574
575The filename of a FIGfont file must end with ".flf", which stands for
576"<F>IG<L>ettering <F>ont". The first part of the filename should contain
577only letters, and should be lowercase on operating systems which permit case
578sensitive filenames. The filename should be unique in the first 8
579characters, since some older file systems truncate longer filenames.
580
581It is easier to modify an existing FIGfont than it is to create a new one
582from scratch. The first step is to read and understand this document.
583You may want to load "standard.flf" or another FIGfont into a text editor as
584an example while you read.
585
586A FIGfont file contains three portions: a header line, comments, and
587FIGcharacter data.
588
589
590THE HEADER LINE
591
592The header line gives information about the FIGfont. Here is an example
593showing the names of all parameters:
594
595 flf2a$ 6 5 20 15 3 0 143 229 NOTE: The first five characters in
596 | | | | | | | | | | the entire file must be "flf2a".
597 / / | | | | | | | \
598 Signature / / | | | | | \ Codetag_Count
599 Hardblank / / | | | \ Full_Layout*
600 Height / | | \ Print_Direction
601 Baseline / \ Comment_Lines
602 Max_Length Old_Layout*
603
604 * The two layout parameters are closely related and fairly complex.
605 (See "INTERPRETATION OF LAYOUT PARAMETERS".)
606
607For those desiring a quick explanation, the above line indicates that this
608FIGfont uses "$" to represent the hardblank in FIGcharacter data, it has
609FIGcharacters which are 6 lines tall, 5 of which are above the baseline, no
610line in the FIGfont data is more than 20 columns wide, the default horizontal
611layout is represented by the number 15, there are 3 comment lines, the
612default print direction for this FIGfont is left-to-right, a complete
613description of default and possible horizontal and vertical layouts is
614represented by the number 143, and there are 229 code-tagged characters.
615
616The first seven parameters are required. The last three (Direction,
617Full_Layout, and Codetag_Count, are not. This allows for backward
618compatibility with older FIGfonts, but a FIGfont without these parameters would
619force a FIGdriver to "guess" (by means not described in this document) the
620information it would expect to find in Full_Layout. For this reason, inclusion
621of all parameters is strongly recommended.
622
623Future versions of this standard may add more parameters after Codetag_Count.
624
625A description of each parameter follows:
626
627 Signature
628
629The signature is the first five characters: "flf2a". The first four
630characters "flf2" identify the file as compatible with FIGlet version 2.0 or
631later (and FIGWin 1.0). The "a" is currently ignored, but cannot be omitted.
632Different characters in the "a" location may mean something in future
633versions of this standard. If so, you can be sure your FIGfonts will still
634work if this character is "a".
635
636 Hardblank
637
638Immediately following the signature is the hardblank character. The
639hardblank character in the header line defines which sub-character will be
640used to represent hardblanks in the FIGcharacter data.
641
642By convention, the usual hardblank is a "$", but it can be any character
643except a blank (space), a carriage-return, a newline (linefeed) or a null
644character. If you want the entire printable ASCII set available to use, make
645the hardblank a "delete" character (character code 127). With the exception
646of delete, it is inadvisable to use non-printable characters as a hardblank.
647
648 Height
649
650The Height parameter specifies the consistent height of every FIGcharacter,
651measured in sub-characters. Note that ALL FIGcharacters in a given FIGfont
652have the same height, since this includes any empty space above or below.
653This is a measurement from the top of the tallest FIGcharacter to the bottom
654of the lowest hanging FIGcharacter, such as a lowercase g.
655
656 Baseline
657
658The Baseline parameter is the number of lines of sub-characters from the
659baseline of a FIGcharacter to the top of the tallest FIGcharacter. The
660baseline of a FIGfont is an imaginary line on top of which capital letters
661would rest, while the tails of lowercase g, j, p, q, and y may hang below.
662In other words, Baseline is the height of a FIGcharacter, ignoring any
663descenders.
664
665This parameter does not affect the output of FIGlet 2.2 or FIGWin 1.0, but
666future versions or other future FIGdrivers may use it. The Baseline
667parameter should be correctly set to reflect the true baseline as described
668above. It is an error for Baseline to be less than 1 or greater than the
669Height parameter.
670
671 Max_Length
672
673The Max_Length parameter is the maximum length of any line describing a
674FIGcharacter. This is usually the width of the widest FIGcharacter, plus 2
675(to accommodate endmarks as described later.) However, you can (and probably
676should) set Max_Length slightly larger than this as a safety measure in case
677your FIGfont is edited to include wider FIGcharacters. FIGlet (but not
678FIGWin 1.0) uses this number to minimize the memory taken up by a FIGfont,
679which is important in the case of FIGfonts with many FIGcharacters.
680
681 Old_Layout
682
683(See "INTERPRETATION OF LAYOUT PARAMETERS" below.)
684
685 Comment_Lines
686
687Between the first line and the actual FIGcharacters of the FIGfont are the
688comment lines. The Comment_Lines parameter specifies how many lines there
689are. Comments are optional, but recommended to properly document the origin
690of a FIGfont.
691
692 Print_Direction
693
694The Print_Direction parameter tells which direction the font is to be
695printed by default. A value of 0 means left-to-right, and 1 means
696right-to-left. If this parameter is absent, 0 (left-to-right) is assumed.
697Print_Direction may not specify vertical print, although FIGdrivers are
698capable of vertical print. Versions of FIGlet prior to 2.1 ignore this
699parameter.
700
701 Full_Layout
702
703(See "INTERPRETATION OF LAYOUT PARAMETERS" just below.)
704
705 Codetag_Count
706
707Indicates the number of code-tagged (non-required) FIGcharacters in this
708FIGfont. This is always equal to the total number of FIGcharacters in the font
709minus 102. This parameter is typically ignored by FIGdrivers, but can be
710used to verify that no characters are missing from the end of the FIGfont.
711The chkfont program will display the number of codetagged characters
712in the FIGfont on which it is run, making it easy to insert this parameter
713after a FIGfont is written.
714
715
716INTERPRETATION OF LAYOUT PARAMETERS
717
718Full_Layout describes ALL information about horizontal and vertical layout:
719the default layout modes and potential smushing rules, even when smushing is
720not a default layout mode.
721
722Old_Layout does not include all of the information desired by the most
723recent FIGdrivers, which is the inspiration for the creation of the new
724Full_Layout parameter. Old_Layout is still required for backward
725compatibility, and FIGdrivers must be able to interpret FIGfonts which do not
726have the Full_Layout parameter. (See "STANDARDIZED CAPABILITIES OF CURRENT
727AND FUTURE FIGDRIVERS".)
728
729Versions of FIGlet prior to 2.2 do not recognize the Full_Layout parameter.
730Documentation accompanying FIGlet versions prior to 2.2 refer to Old_Layout
731as "smushmode", which is somewhat misleading since it can indicate layout
732modes other than smushing.
733
734Old_Layout and Full_Layout must contain some redundant information.
735
736Setting the layout parameters is a matter of adding numbers together ("code
737values"). What follows is a chart of the meanings of all code values.
738(You may skip down to "SETTING LAYOUT PARAMETERS STEP BY STEP" if you prefer,
739or if you find this portion confusing.)
740
741Full_Layout: (Legal values 0 to 32767)
742
743 1 Apply horizontal smushing rule 1 when smushing
744 2 Apply horizontal smushing rule 2 when smushing
745 4 Apply horizontal smushing rule 3 when smushing
746 8 Apply horizontal smushing rule 4 when smushing
747 16 Apply horizontal smushing rule 5 when smushing
748 32 Apply horizontal smushing rule 6 when smushing
749 64 Horizontal fitting (kerning) by default
750 128 Horizontal smushing by default (Overrides 64)
751 256 Apply vertical smushing rule 1 when smushing
752 512 Apply vertical smushing rule 2 when smushing
753 1024 Apply vertical smushing rule 3 when smushing
754 2048 Apply vertical smushing rule 4 when smushing
755 4096 Apply vertical smushing rule 5 when smushing
756 8192 Vertical fitting by default
757 16384 Vertical smushing by default (Overrides 8192)
758
759When no smushing rules are included in Full_Layout for a given axis, the
760meaning is that universal smushing shall occur, either by default or when
761requested.
762
763Old_Layout: (Legal values -1 to 63)
764
765 -1 Full-width layout by default
766 0 Horizontal fitting (kerning) layout by default*
767 1 Apply horizontal smushing rule 1 by default
768 2 Apply horizontal smushing rule 2 by default
769 4 Apply horizontal smushing rule 3 by default
770 8 Apply horizontal smushing rule 4 by default
771 16 Apply horizontal smushing rule 5 by default
772 32 Apply horizontal smushing rule 6 by default
773
774* When Full_Layout indicates UNIVERSAL smushing as a horizontal default
775(i.e., when none of the code values of horizontal smushing rules are included
776and code value 128 is included in Full_Layout) Old_Layout must be set to 0
777(zero). Older FIGdrivers which cannot read the Full_Layout parameter are
778also incapable of universal smushing. Therefore they would be directed to
779the "next best thing", which is horizontal fitting (kerning).
780
781NOTE: You should NOT add the -1 value to any positive code value for
782Old_Layout. This would be a logical contradiction.
783
784See "STANDARDIZED CAPABILITIES OF CURRENT AND FUTURE FIGDRIVERS" for the
785behavior of a FIGdriver when the Full_Layout parameter is absent (presumably
786in an older FIGfont).
787
788The following rules establish consistency between Old_Layout and Full_Layout.
789
790 If full width is to be the horizontal default:
791 Old_Layout must be -1.
792 Full_Layout must NOT include code values 64 nor 128.
793
794 If horizontal fitting (kerning) is to be default:
795 Old_Layout must be 0.
796 Full_Layout must include code value 64.
797 Full_Layout must NOT include code value 128.
798
799 If CONTROLLED smushing is to be the horizontal default:
800 Old_Layout must be a positive number, represented by the added
801 code values of all desired horizontal smushing rules.
802 Full_Layout must include the code values for the SAME set of
803 horizontal smushing rules as included in Old_Layout.
804 Full_Layout must include code value 128.
805
806 If UNIVERSAL smushing is to be the horizontal default:
807 Old_Layout must be 0.
808 Full_Layout must include code value 128.
809 Full_Layout must NOT include any code value under 64.
810
811In general terms, if Old_Layout specifies horizontal smushing rules,
812Full_Layout must specify the same set of horizontal rules, and both must
813indicate the same horizontal default layout mode.
814
815
816SETTING LAYOUT PARAMETERS STEP-BY-STEP
817
818The following step-by-step process will yield correct and consistent values
819for the two layout parameters. You may skip this if you find the
820explanations above easier to use.
821
822Step 1: Start with 0 for both numbers.
823
824 Write "Old_Layout" and "Full_Layout" on a piece of paper.
825 Write the number 0 next to each.
826 The number 0 may be crossed out and changed several times below.
827 Go to step 2.
828
829Step 2: Set the DEFAULT HORIZONTAL LAYOUT MODE.
830
831 If you want to use FULL WIDTH as the default
832 Make Old_Layout -1
833 Go to step 3.
834 If you want to use HORIZONTAL FITTING (kerning) as the default
835 Make Full_Layout 64
836 Go to step 3.
837 If you want to use HORIZONTAL SMUSHING as the default
838 Make Full_Layout 128
839 Go to step 3.
840
841Step 3: Specify HOW TO SMUSH HORIZONTALLY WHEN SMUSHING.
842
843 If you want to use UNIVERSAL smushing for the horizontal axis
844 Go to step 4.
845 If you want to use CONTROLLED smushing for the horizontal axis
846 Add together the code values for all the horizontal smushing
847 rules you want from the list below to get the horizontal
848 smushing rules total.
849
850 EQUAL CHARACTER SMUSHING 1
851 UNDERSCORE SMUSHING 2
852 HIERARCHY SMUSHING 4
853 OPPOSITE PAIR SMUSHING 8
854 BIG X SMUSHING 16
855 HARDBLANK SMUSHING 32
856
857 Horizontal smushing rules total: ___
858
859 If Full_Layout is currently 128
860 Change Old_Layout to the horizontal smushing rules total.
861 Increase Full_Layout by the horizontal smushing rules total.
862 Go to Step 4.
863 If Full_Layout is currently 0 or 64
864 Increase Full_Layout by the horizontal smusing rules total.
865 Go to Step 4.
866
867Step 4: Set the DEFAULT VERTICAL LAYOUT MODE.
868
869 If you want to use FULL HEIGHT as the default
870 Go to step 5.
871 If you want to use VERTICAL FITTING as the default
872 Increase Full_Layout by 8192.
873 Go to step 5.
874 If you want to use VERTICAL SMUSHING as the default
875 Increase Full_Layout by 16384.
876 Go to step 5.
877
878Step 5: Specify HOW TO SMUSH VERTICALLY WHEN SMUSHING.
879
880 If you want to use UNIVERSAL smushing for the vertical axis
881 Go to step 6.
882 If you want to use CONTROLLED smushing for the vertical axis
883 Add together the code values for all the vertical smushing
884 rules you want from the list below to get the vertical
885 smushing rules total.
886
887 EQUAL CHARACTER SMUSHING 256
888 UNDERSCORE SMUSHING 512
889 HIERARCHY SMUSHING 1024
890 HORIZONTAL LINE SMUSHING 2048
891 VERTICAL LINE SUPERSMUSHING 4096
892
893 Vertical smushing rules total: ____
894
895 Increase Full_Layout by the vertical smushing rules total.
896 Go to step 6.
897
898Step 6: You're done.
899
900The resulting value of Old_Layout will be a number from -1 to 63.
901The resulting value of Full_Layout will be a number from 0 and 32767.
902
903
904FIGFONT COMMENTS
905
906After the header line are FIGfont comments. The comments can be as many
907lines as you like, but should at least include your name and Email address.
908Here is an example which also shows the header line.
909
910 flf2a$ 6 5 20 15 3 0 143
911 Example by Glenn Chappell <ggc@uiuc.edu> 8/94
912 Permission is hereby given to modify this font, as long as the
913 modifier's name is placed on a comment line.
914
915Comments are not required, but they are appreciated. Please comment your
916FIGfonts.
917
918Remember to adjust the Comment_Lines parameter as you add lines to your
919comments. Don't forget that blank lines DO count.
920
921
922FIGCHARACTER DATA
923============ ====
924
925The FIGcharacter data begins on the next line after the comments and
926continues to the end of the file.
927
928BASIC DATA STRUCTURE
929
930The sub-characters in the file are given exactly as they should be output,
931with two exceptions:
932
933 1) Hardblanks should be the hardblank character specified in the
934 header line, not a blank (space).
935
936 2) Every line has one or two endmark characters, whose column
937 locations define the width of each FIGcharacter.
938
939In most FIGfonts, the endmark character is either "@" or "#". The FIGdriver
940will eliminate the last block of consecutive equal characters from each line
941of sub-characters when the font is read in. By convention, the last line of
942a FIGcharacter has two endmarks, while all the rest have one. This makes it
943easy to see where FIGcharacters begin and end. No line should have more
944than two endmarks.
945
946Below is an example of the first few FIGcharacters, taken from small.flf.
947
948NOTE: The line drawn below consisting of "|" represents the left margin of
949your editor. It is NOT part of the FIGfont. Also note that hardblanks are
950represented as "$" in this FIGfont, as would be described in the header line.
951
952 |$@
953 |$@
954 blank/space |$@
955 |$@
956 |$@@
957 | _ @
958 || |@
959 exclamation point ||_|@
960 |(_)@
961 | @@
962 | _ _ @
963 |( | )@
964 double quote | V V @
965 | $ @
966 | @@
967 | _ _ @
968 | _| | |_ @
969 number sign ||_ . _|@
970 ||_ _|@
971 | |_|_| @@
972 | @
973 | ||_@
974 dollar sign |(_-<@
975 |/ _/@
976 | || @@
977
978Notice that each FIGcharacter occupies the same number of lines (6 lines, in
979this case), which must also be expressed in the header line as the Height
980parameter.
981
982Also notice that for every FIGcharacter, there must be a consistent width
983(length) for each line once the endmarks are removed. To do otherwise would
984be an error.
985
986Be aware of the vertical alignment of each FIGcharacter within its height,
987so that all FIGcharacters will be properly lined up when printed.
988
989If one of the last sub-characters in a particular FIGcharacter is "@", you
990should use another character for the endmark in that FIGcharacter so that
991the intended "@" is not interpreted as an endmark. "#" is a common
992alternative.
993
994Load a few existing FIGfonts into your favorite text editor for other
995examples.
996
997
998REQUIRED FIGCHARACTERS
999
1000Some FIGcharacters are required, and must be represented in a specific order.
1001Specifically: all of the printable character codes from ASCII shown in the
1002table below, in order, plus character codes 196, 214, 220, 228, 246, 252,
1003and 223, in that order. In Latin-1, these extra 7 characters represent the
1004following German characters: umlauted "A", "O", "U", "a", "o" and "u"; and
1005also "ess-zed".
1006
1007 Printable portion of the ASCII character set:
1008
1009 32 (blank/space) 64 @ 96 `
1010 33 ! 65 A 97 a
1011 34 " 66 B 98 b
1012 35 # 67 C 99 c
1013 36 $ 68 D 100 d
1014 37 % 69 E 101 e
1015 38 & 70 F 102 f
1016 39 ' 71 G 103 g
1017 40 ( 72 H 104 h
1018 41 ) 73 I 105 i
1019 42 * 74 J 106 j
1020 43 + 75 K 107 k
1021 44 , 76 L 108 l
1022 45 - 77 M 109 m
1023 46 . 78 N 110 n
1024 47 / 79 O 111 o
1025 48 0 80 P 112 p
1026 49 1 81 Q 113 q
1027 50 2 82 R 114 r
1028 51 3 83 S 115 s
1029 52 4 84 T 116 t
1030 53 5 85 U 117 u
1031 54 6 86 V 118 v
1032 55 7 87 W 119 w
1033 56 8 88 X 120 x
1034 57 9 89 Y 121 y
1035 58 : 90 Z 122 z
1036 59 ; 91 [ 123 {
1037 60 < 92 \ 124 |
1038 61 = 93 ] 125 }
1039 62 > 94 ^ 126 ~
1040 63 ? 95 _
1041
1042 Additional required Deutsch FIGcharacters, in order:
1043
1044 196 (umlauted "A" -- two dots over letter "A")
1045 214 (umlauted "O" -- two dots over letter "O")
1046 220 (umlauted "U" -- two dots over letter "U")
1047 228 (umlauted "a" -- two dots over letter "a")
1048 246 (umlauted "o" -- two dots over letter "o")
1049 252 (umlauted "u" -- two dots over letter "u")
1050 223 ("ess-zed" -- see FIGcharacter illustration below)
1051 ___
1052 / _ \
1053 | |/ /
1054 Ess-zed >>---> | |\ \
1055 | ||_/
1056 |_|
1057
1058If you do not wish to define FIGcharacters for all of those required above,
1059you MAY create "empty" FIGcharacters in their place by placing endmarks flush
1060with the left margin. The Deutsch FIGcharacters are commonly created as
1061empty. If your FIGfont includes only capital letters, please copy them to
1062the appropriate lowercase locations, rather than leaving lowercase letters
1063empty. A FIGfont which does not include at least all ASCII letters, a space,
1064and a few basic punctuation marks will probably frustrate some users. (For
1065example "@" is more frequently desired as a FIGcharacter than you may think,
1066since Email addresses may be written as FIGures.)
1067
1068
1069CODE TAGGED FIGCHARACTERS
1070
1071After the required FIGcharacters, you may create FIGcharacters with any
1072character code in the range of -2147483648 to +2147483647. (Over four
1073billion possibilities, which is "virtual infinity" for this purpose.)
1074One exception: character code -1 is NOT allowed for technical reasons.
1075It is advisable to assign character codes such that the appearance of your
1076FIGcharacters matches the expectations of ASCII/Latin-1/Unicode, with a few
1077exceptions:
1078
1079 1) If a FIGcharacter with code 0 is present, it is treated
1080 specially. It is a FIGfont's "missing character". Whenever
1081 the FIGdriver is told to print a character which doesn't exist
1082 in the current FIGfont, it will print FIGcharacter 0. If there
1083 is no FIGcharacter 0, nothing will be printed.
1084
1085 2) If a FIGfont contains a non-Latin alphabet in character codes
1086 in the ASCII range 32-126 (which is discouraged), we have found
1087 it helpful to include a human-readable translation table as one
1088 of the FIGcharacters instead of a "glyph". Typically, the "~"
1089 would contain this table. The translation table FIGcharacter
1090 would contain a list of all the special characters in the
1091 FIGfont, along with the ASCII characters to which they
1092 correspond. Keep this table no more than 79 columns wide.
1093 (Thanks to Gedaliah Friedenberg for this idea.)
1094
1095 3) In more extensive Unicode fonts, you can assign a negative
1096 character code (other than -1) to one or more translation
1097 tables, similar to #2 above. (All Unicode character codes are
1098 positive.) And, you will most likely suggest within the
1099 comments that a user access one of several control files (See
1100 "CONTROL FILES" below) to gain access to Latin-2, Latin-3, or
1101 other 8-bit standardized character sets. The control files may
1102 redirect the "~" character to one of the negative character codes so
1103 that the translation table would display the table when "~" is
1104 given for input. Doing this allows you to still have a "~"
1105 FIGcharacter for those who do not use a control file.
1106
1107Those FIGcharacters which are not required must have an explicit character
1108code in a separate line preceding them, called a "code tag". A code tag
1109contains the value of the character code, followed by whitespace (a few
1110spaces), and perhaps an optional comment. The comment is usually the name of
1111the FIGcharacter. The Unicode Consortium has assigned formal names to all
1112officially accepted characters, and these may be used. An entire code tag,
1113including the comment, should not occupy more than 95 columns. (Over 100
1114characters here may make older versions of FIGlet crash.)
1115
1116Here is an example, showing two code tagged FIGcharacters after the last two
1117required Deutsch FIGcharacters. Again, the line drawn below consisting of
1118"|" represents the left margin of your editor, and is NOT part of the FIGfont.
1119
1120 | _ _ @
1121 |(_) (_)@
1122 || | | |@
1123 || |_| |@
1124 | \__,_|@
1125 | @@
1126 | ___ @
1127 | / _ \@
1128 || |/ /@
1129 || |\ \@
1130 || ||_/@
1131 ||_| @@
1132 |161 INVERTED EXCLAMATION MARK
1133 | _ @
1134 |(_)@
1135 || |@
1136 || |@
1137 ||_|@
1138 | @@
1139 |162 CENT SIGN
1140 | _ @
1141 | | | @
1142 | / __)@
1143 || (__ @
1144 | \ )@
1145 | |_| @@
1146
1147
1148A character code may be expressed in decimal (as shown above, numbers we're
1149all familiar with), or in Octal (seldom used) or in hexadecimal.
1150
1151Character codes expressed in octal must be preceded by "0" (zero), and if
1152negative, "-" (minus) must precede the "0". There are eight octal digits:
115301234567. You may recall octal numbers from school as "base 8 numbers".
1154
1155Character codes expressed in hexadecimal must be preceded by "0x" or "0X".
1156(That's also a zero.) If negative, the "-" must precede the "0x". There are
115716 hexadecimal digits: 01234567890ABCDEF. (The "letter-digits" may also be
1158lowercase.) Hexadecimal is "base 16".
1159
1160It is common to express character codes less than 256 (in the range of an
11618-bit character set) as decimal, while FIGfonts which extend into the Unicode
1162range would have character codes expressed in hexadecimal. This is because
1163the Unicode Standard expresses character codes in hexadecimal, which is
1164helpful for programmers.
1165
1166The code tagged FIGcharacters may be listed in any order, but simple
1167sequential order is recommended.
1168
1169If two or more FIGcharacters have the same character code, the last one in
1170the FIGfont is the one used. It is common for the Deutsch FIGcharacters to
1171be given twice in a FIGfont, just to maintain a consistent order for the
1172Latin-1 range (128 to 255).
1173
1174It is not advisable to assign character codes in the range of 1 to 31, since
1175this range includes control characters in ASCII. Character code 127 is a
1176delete in ASCII, and is also not advised. Character codes 128 to 159 are
1177additional control characters in Latin-1, and they too should not be used.
1178All of the above are legal, technically, but are not part of what is legal
1179for input, so they could only be accessed by use of a control file.
1180(See "CONTROL FILES" below.) If you are still tempted to use them, consider
1181negative character codes instead, which are meaningless in all standardized
1182character sets.
1183
1184Again, the character code -1 is illegal for technical reasons.
1185
1186
1187NOTES - AVOIDING ERRORS AND GENERAL ADVICE
1188===== ======== ====== === ======= ======
1189
1190It is very important that every character in a font has the same height, and,
1191once the endmarks are removed, that all the lines constituting a single
1192FIGcharacter have the same length. Be careful also that no lines in the font
1193file have trailing blanks (spaces), as the FIGdriver will take these to be
1194the endmarks. (FIGWin 1.0 will not consider blanks to be endmarks.)
1195
1196Errors in a FIGfont can be detected by using the "chkfont" program,
1197part of the standard FIGlet package, and also available, as of this
1198writing from http://st-www.cs.uiuc.edu/users/chai/figlet.html.
1199…
1200For FIGWin users, the FIGWin program will report errors when a FIGfont is
1201read in; it is less forgiving than FIGlet, which can produce nonsense if the
1202FIGfont is incorrectly formatted.
1203
1204Remember that sub-characters outside of the ASCII range will not necessarily
1205display the same way on your system as on others.
1206
1207The blank (space) FIGcharacter should usually consist of one or two columns
1208of hardblanks and nothing else; slanted fonts are an exception to this rule.
1209If the space FIGcharacter does not contain any hardblanks, it will disappear
1210when horizontal fitting (kerning) or smushing occurs.
1211
1212Again, if you design a FIGfont, please let us know!
1213
1214
1215CONTROL FILES
1216======= =====
1217
1218A FIGfont control file is a separate text file, associated with one or more
1219FIGfonts, that indicates how to map input characters into FIGfont character
1220codes. By default, FIGdrivers read single bytes from the input source and
1221interpret them as Latin-1 FIGcharacters.
1222
1223FIGlet version 2.2 (and later) can optionally interpret its input as DBCS or
1224UTF-8 characters, making it possible to access FIGcharacters with codes
1225outside the Latin-1 range (greater than 255).
1226
1227In addition, though, all versions of FIGlet can use control files to
1228transform specific character codes (or ranges of codes) as other codes
1229(or ranges). Multiple control files can be specified, in which case multiple
1230stages of transformation are performed.
1231
1232The filename of a control file always ends with ".flc".
1233
1234CONTROL FILE FORMAT
1235
1236Control files contain several kinds of lines. Lines beginning with "#", as
1237well as blank lines, are comment lines and are ignored. All other lines are
1238command lines, with one of the following formats:
1239
1240 t inchar outchar
1241 t inchar1-inchar2 outchar1-outchar2
1242 number number
1243 f
1244 h
1245 j
1246 b
1247 u
1248 g{0|1|2|3} {94|96|94x94} [char]
1249 g{L|R} {0|1|2|3}
1250
1251where "inchar", "outchar", and "char" are either Latin-1 characters
1252representing their own codes, or else are numeric character codes preceded by
1253a "\" character; and "number" is a numeric character code with no preceding
1254"\" character.
1255
1256Thus "A" represents the code 65, as does "\65", and "\0x100" represents the
1257code 256 (100 in hexadecimal). In addition, "\ " (backslash followed by a
1258space) represents the code 32 (space), and the following backslash sequences
1259are also understood:
1260
1261 \a code 7 (a bell/alert)
1262 \b code 8 (a backspace)
1263 \e code 27 (an ESC character)
1264 \f code 12 (a form feed)
1265 \n code 10 (a newline/line feed)
1266 \r code 13 (a carriage return)
1267 \t code 9 (a horizontal tab)
1268 \v code 11 (a vertical tab)
1269 \\ code 92 (a backslash)
1270
1271All of these combinations except perhaps "\\" are very unlikely to be used,
1272but they are provided just in case they are needed.
1273
1274Whitespace characters are used between "t" and "inchar" and between "inchar"
1275and "outchar", but not around the "-" characters used in the second type of
1276"t" command.
1277
1278The term "string" refers to any number of characters represented in the
1279format given above. The characters begin after the whitespace following the
1280letter "s", and continue to the end of the line.
1281
1282Anything following the first letter of an "f", "h", "j", or "u" command is
1283ignored.
1284
1285The first type of "t" command transforms characters with the code "inchar"
1286into characters with the code "outchar". The second type of "t" command
1287transforms characters in the range "inchar1" to "inchar2" as the
1288corresponding codes in the range "outchar1" to "outchar2". Both ranges must
1289be of the same size. The form "number number" is equivalent to a "t"
1290command of the first type, and is provided for compatibility with the mapping
1291tables issued by the Unicode Consortium.
1292
1293Multiple transformation stages can be encoded in a single control file by
1294using "f" commands to separate the stages.
1295
1296Versions of FIGlet before 2.1 required that the first line of a control file
1297consist of the signature string "flc2a". This signature line is still
1298permitted in FIGlet 2.2 and later versions, but is no longer required.
1299
1300Here is an example of a control file. The blanks at the beginning of each
1301line are for readability only, and are not part of the file.
1302
1303The following control file:
1304
1305 flc2a
1306 t # $
1307 t A-Z a-z
1308
1309will map the "#" character to "$", and will also convert uppercase ASCII to
1310lowercase ASCII.
1311
1312If a number of consecutive "t" commands are given, then for each character
1313processed, only the first applicable command (if any) will be executed.
1314Consider this control file:
1315
1316 t A B
1317 t B A
1318
1319It will swap the characters "A" and "B". If the FIGdriver reads an "A", the
1320first command will change "A" to "B", in which case the second will not be
1321executed. If the FIGdriver reads a "B", the first command will have no
1322effect, and the second command will change "B" to "A". Here is another
1323control file:
1324
1325 t A B
1326 t A C
1327
1328In this example, the second line is never executed. In short, a sequence of
1329"t" lines "does what it ought to".
1330
1331More complex files, in which a single character is acted upon by several "t"
1332commands, can be set up using an "f" command. For example:
1333
1334 flc2a
1335 t a-z A-Z
1336 f
1337 t Q ~
1338
1339This control file specifies two transformation stages. In the first stage,
1340lowercase ASCII letters are changed to their uppercase equivalents. The
1341second stage maps any Q (whether original or a converted "q") into the "~"
1342character. If the "f" command were omitted, "q" characters would remain "Q"
1343and not be converted to "~".
1344
1345EXTENDED COMMANDS
1346
1347The "h", "j", "b", "u", and "g" commands are only understood by FIGlet
1348version 2.2 or later. They control how a FIGdriver interprets bytes in the
1349input. By default, the FIGdriver interprets each byte of input as a distinct
1350character. This mode is suitable for most character encodings. All these
1351commands are logically acted on before any other control file commands, no
1352matter where in the sequence of control files they appear. They are also
1353mutually exclusive; if more than one of these commands is found, only the
1354last is acted on. Multiple "g" commands are permitted, however.
1355
1356The "h" command forces the input to be interpreted in HZ mode, which is used
1357for the HZ character encoding of Chinese text. In this mode, the sequence
1358"~{" (which is removed from the input) signals that all following characters
1359are two bytes long until the sequence "~}" is detected. In addition, the
1360sequence "~~" is changed to just "~", and all other two-byte sequences
1361beginning with "~" are removed from the input. The character code
1362corresponding to a two-byte character is:
1363
1364 first character * 256 + second character
1365
1366The "j" command forces the input to be interpreted in Shift-JIS mode (also
1367called "MS-Kanji mode"). Input bytes in the ranges 128-159 and 224-239 are
1368read as the high-order byte of a two-byte character; all other bytes are
1369interpreted as one-byte characters. The value of a two-byte character is
1370determined in the same way as in HZ mode.
1371
1372The "b" command forces the input to be interpreted in DBCS mode, which is
1373suitable for processing HZ or Shift-GB Chinese text or Korean text. Input
1374bytes in the ranges 128-255 are read as the high-order byte of a two-byte
1375character; all other bytes are interpreted as one-byte characters. The
1376value of a two-byte character is determined in the same way as in HZ mode.
1377
1378The "u" command forces the input to be interpreted in UTF-8 mode, which
1379causes any input byte in the range 0x80 to 0xFF to be interpreted as the
1380first byte of a multi-byte Unicode (ISO 10646) character. UTF-8 characters
1381can be from 1 to 6 bytes long. An incorrectly formatted sequence is
1382interpreted as the character 128 (normally an unused control character).
1383
1384Otherwise, the input is allowed to contain ISO 2022 escape sequences, which
1385are decoded to generate appropriate character codes. These character codes
1386are *not* a subset of Unicode, but may be more useful in processing East
1387Asian text. A brief explanation of ISO 2022 is given here in order to
1388clarify how a FIGdriver should interpret it. The "g" command provides
1389information for the ISO 2022 interpreter, and is explained below.
1390
1391ISO 2022 text is specified using a mixture of registered character sets.
1392At any time, up to four character sets may be available. Character sets
1393have one of three sizes: single-byte character sets with 94 characters
1394(e.g. ASCII), single-byte character sets with 96 characters (e.g. the top
1395halves of ISO Latin-1 to Latin-5), or double-byte character sets with
139694 x 94 characters (e.g. JIS 0208X-1983). Each registered character set has
1397a standard designating byte in the range 48 to 125; the bytes are unique withi
1398n character set sizes, but may be reused across sizes. For example, byte 66
1399designates the 94-character set ASCII, the 96-character set ISO Latin-2 (top
1400half), and the 94 x 94 Japanese character set JIS 0208X-1983. In this
1401document, the designating byte of a character set will be represented by <D>.
1402
1403The four available character sets are labeled G0, G1, G2, and G3. Initially,
1404G0 is the 94-character set ASCII, and G1 is the 96-character set ISO Latin-1
1405(top half). The other character sets are unassigned. The following escape
1406sequences (where ESC = the byte 27) specify changes to the available
1407character sets:
1408
1409 ESC ( <D> Set G0 to the 94-character set <D>
1410 ESC ) <D> Set G1 to the 94-character set <D>
1411 ESC * <D> Set G2 to the 94-character set <D>
1412 ESC + <D> Set G3 to the 94-character set <D>
1413 ESC - <D> Set G1 to the 96-character set <D>
1414 ESC . <D> Set G2 to the 96-character set <D>
1415 ESC / <D> Set G3 to the 96-character set <D>
1416 ESC $ <D> Set G0 to the 94 x 94 character set <D>
1417 ESC $ ( <D> Set G0 to the 94 x 94 character set <D>
1418 ESC $ ) <D> Set G1 to the 94 x 94 character set <D>
1419 ESC $ * <D> Set G2 to the 94 x 94 character set <D>
1420 ESC $ + <D> Set G3 to the 94 x 94 character set <D>
1421
1422
1423Note that G0 may not be a 96-character set, and that there are two ways to
1424specify a 94 x 94 character set in G0, of which the first is deprecated.
1425
1426ISO 2022 decoding affects input bytes in the ranges 33 to 126 and 160 to 255,
1427known as "the left half" and "the right half" respectively. All other bytes,
1428unless they belong to a control sequence shown in this document, remain
1429unchanged. Initially, the left half is interpreted as character set G0,
1430and the right half as character set G1. This can be changed by the following
1431control sequences:
1432
1433 SI (byte 15) Interpret the left half as G1 characters
1434 SO (byte 14) Interpret the left half as G0 characters
1435 ESC n Interpret the left half as G2 characters
1436 ESC o Interpret the left half as G3 characters
1437 ESC ~ Interpret the right half as G1 characters
1438 ESC } Interpret the right half as G2 characters
1439 ESC | Interpret the right half as G3 characters
1440 SS2 (byte 142) Interpret next character only as G2
1441 ESC N Interpret next character only as G2
1442 SS3 (byte 143) Interpret next character only as G3
1443 ESC O Interpret next character only as G3
1444
1445
1446This rich schema may be used in various ways. In ISO-2022-JP, the Japanese
1447flavor of ISO 2022, only the bytes 33-126 and the G0 character set is used,
1448and escape sequences are used to switch between ASCII, ISO-646-JP (the
1449Japanese national variant of ASCII), and JIS 0208X-1983. In other versions,
1450the G1 character set has 94 x 94 size, and so any byte in the range 160-255
1451is automatically the first byte of a double-byte character.
1452
1453FIGdrivers that support ISO 2022 do so in the following way. Each character i
1454is decoded and assigned to a character set <D>.
1455
1456 If the character belongs to a 94-bit character set,
1457 then if its value exceeds 128, it is reduced by 128,
1458 and the value 65536 * <D> is added to it,
1459 unless <D> is 66 (ASCII).
1460 If the character belongs to a 96-bit character set,
1461 then if its value is less than 128, it is increased by 128,
1462 and the value 65536 * <D> is added to it,
1463 unless <D> is 65 (ISO Latin-1).
1464 If the character belongs to a 94 x 94 character set,
1465 then the value is the sum of:
1466 the first byte * 256,
1467 plus the second byte,
1468 plus the value 65536 * <D>.
1469
1470
1471Thus, the character code 65 ("A") in ASCII remains 65, the character code
1472196 in ISO Latin-1 ("A-umlaut") remains 196, the character code 65 (0x41)
1473in ISO-646-JP (whose <D> is 74 = 0x4A) becomes 0x4A0041 =4849729, and the
1474two-byte sequence 33 33 (0x21 0x21) in JIS 0208X-1983 (whose <D> is
147565 = 0x41) becomes 0x412121 = 4268321. These codes may be used in compiling
1476FIGfonts suitable for use with ISO 2022 encoded text.
1477
1478The initial settings of G0 through G3 and their assignments to the left half
1479and the right half can be altered in a control file by using "g" commands,
1480as follows:
1481
1482 g {0|1|2|3} {94|96|94x94} [<D>]
1483
1484specifies that one of G0-G3 is a 94, 96, or 94x94 character set with
1485designating character <D>. If no designating character is specified, then a
1486<D> value of zero is assumed.
1487
1488For example, the list of control commands:
1489
1490 g 0 94 B
1491 g 1 96 A
1492
1493sets the G0 character set to ASCII (94-character set "B") and the G1
1494character set to the top half of Latin-1 (96-character set "A"). (This is the
1495default setting).
1496
1497To change the initial assignments of G0 to the left half and G1 to the right
1498half, "g" commands of the form
1499
1500 g {L|R} {0|1|2|3}
1501
1502For example, the command:
1503
1504 g R 2
1505
1506causes right-half bytes (in the range 160-255) to be interpreted as G2.
1507Whether these bytes are interpreted singly or in pairs depends on the type
1508of character set that is currently available as G2.
1509
1510Spaces may be freely used or omitted in "g" commands.
1511
1512The standard FIGlet distribution contains mapping tables for Latin-2 (ISO 8859-2),
1513Latin-3 (ISO 8859-3), Latin-4 (ISO 8859-4), and Latin-5 (ISO 8859-9). They
1514can be used with the font "standard.flf", which contains all the characters
1515used in these standards.
1516
1517
1518STANDARDIZED CAPABILITIES OF CURRENT AND FUTURE FIGDRIVERS
1519============ ============ == ======= === ====== ==========
1520
1521We assert the following as the "Law" of our intentions:
1522
1523PROFIT
1524
1525All future FIGdrivers shall be FREE OF CHARGE to the general public via the
1526Internet. Any advertisements of other works by the author must be in
1527documentation only, and limited to ONE "screenful", and shall not appear by
1528normal program behavior, nor interfere with normal behavior. No FIGdriver
1529shall disable itself after a set period of time or request "donations".
1530No FIGdriver shall offer any other FIGdriver with improved capability for
1531creating FIGures in exchange for money.
1532
1533REQUIRED FEATURES OF FUTURE VERSIONS
1534
1535Future FIGdrivers must read and process FIGfont files as described in this
1536document, but are not necessarily expected to process control files, smush,
1537perform fitting or kerning, perform vertical operations, or even produce
1538multiple lines in output FIGures.
1539
1540FIGDRIVER NAMES
1541
1542Future FIGdrivers must be named to include capitalized "FIG" and shall have
1543an incremental version number specific to its own platform.
1544
1545BACKWARDS COMPATIBILITY OF FUTURE VERSIONS
1546
1547Any future FIGdriver created for the same platform as an existing FIGdriver,
1548and using the same name as the existing FIGdriver, shall be considered a new
1549version of the preceding FIGdriver, and shall contain all historical comments
1550of updates to past versions on the same platform, and shall have full
1551capability of the preceding versions. If the source code is not provided to
1552the general public, it shall be at least provided to any potential developers
1553of later versions, and such comments relating to past versions shall be
1554accessible to any user by other means or documentation. If a new program is
1555created on a platform that already has an existing FIGdriver, it must be
1556given a new and distinct name. This allows multiple FIGdrivers to exist for
1557the same platform with different capabilities.
1558
1559The format of FIGfonts may not be modified to be non-backwards compatible
1560UNLESS:
1561
1562 1) The new format is easily editable as an ASCII text file,
1563 beginning with the characters "flf" followed by a sequential
1564 number.
1565
1566 2) At least all of the same information can be derived from the
1567 new format as the prior format (currently "flf2"). This
1568 includes the main comments which give credit to the FIGfont
1569 designer.
1570
1571 3) Individuals are found who are willing and have the ability to
1572 either port or develop versions for at least UNIX, DOS,
1573 Windows, and Amiga which will read both the new formats AND the
1574 prior format (currently "flf2"), and retain the capability of
1575 past versions. It is intended that this will be expanded to
1576 include Macintosh if a GUI version exists. This list of
1577 required operating systems may be reduced if an operating
1578 system falls out of popularity or increased if a new operating
1579 system for which there is a FIGdriver comes into greater
1580 popularity, according to the consensus of opinions of past
1581 developers for the most popular operating systems.
1582
1583 4) A C, Java, or other version must always exist which can
1584 receive input and instructions either from a command line, a
1585 file, or directly over the internet so that FIGures can be
1586 obtained from internet-based services without the need to
1587 download any FIGdriver.
1588
1589 5) All existing FIGfonts available from the "official" point of
1590 distribution (http://st-www.cs.uiuc.edu/users/chai/figlet.html),
1591 must be converted to the new format, and offered for download
1592 alongsidethe new versions.
1593
1594THE FUNCTION OF WORD WRAPPING
1595
1596All future FIGdrivers should duplicate these behaviors, unless a version is
1597only capable of outputting one-line FIGures, which is acceptable as long no
1598preceding versions exist for its platform which can output multiple-line
1599FIGures.
1600
1601FIGdrivers which perform word wrapping do so by watching for blanks (spaces)
1602in input text, making sure that the FIGure is no more wide than the maximum
1603width allowed.
1604
1605Input text may also include linebreaks, so that a user may specify where
1606lines begin or end instead of relying on the word wrapping of the FIGdriver.
1607(Linebreaks are represented by different bytes on different platforms, so
1608each FIGdriver must watch for the appropriate linebreaks for its particular
1609platform.)
1610
1611When a FIGdriver word wraps and there are several consecutive blanks in input
1612text where the wrapping occurred, the FIGdriver will disregard all blanks
1613until the next non-blank input character is encountered. However, if blanks
1614in input text immediately follow a linebreak, or if blanks are the first
1615characters in the input text, the blanks will be "printed", moving any
1616visible FIGcharacters which follow on the same output line to the right.
1617Similarly, if an image is right-aligned, and blanks immediately precede
1618linebreaks or the end of input text, a FIGdriver will move an entire line of
1619output FIGcharacters to the left to make room for the blank FIGcharacters
1620until the left margin is encountered. (If the print direction is
1621right-to-left, everything stated in this paragraph is reversed.)
1622
1623Word processing programs or text editors usually behave similarly in all
1624regards to word wrapping.
1625
1626GENERAL INTENT FOR CROSS-PLATFORM PORTABILITY
1627
1628Currently, all versions of FIGlet are compiled from C code, while FIGWin 1.0
1629is written in Visual Basic. Over time it is intended that a later version of
1630FIGWin will be created using a GUI C programming language, and that the
1631FIGlet C code shall continue to be written to be easily "plugged in" to a
1632GUI shell. It is preferable for developers of FIGdrivers for new platforms
1633to use C or a GUI version of C, so that when the core rendering engine of
1634FIGlet is updated, it will be portable to other platforms.
1635
1636CONTROL FILE COMMANDS
1637
1638New control file commands may be added to later versions of this standard.
1639However, the commands "c", "d", and "s" are permanently reserved and may
1640never be given a meaning.
1641
1642FILE COMPRESSION
1643
1644FIGfonts (and control files) are often quite long, especially if many
1645FIGcharacters are included, or if the FIGcharacters are large. Therefore,
1646some FIGdrivers (at present, only FIGlet version 2.2 or later) allow
1647compressed FIGfonts and control files.
1648
1649The standard for FIG compression is to place the FIGfont or control file into
1650a ZIP archive. ZIP archives can be created by the proprietary program PKZIP
1651on DOS and Windows platforms, or by the free program Info-ZIP ZIP on almost
1652all platforms. More information on ZIP can be obtained at
1653http://www.cdrom.com/pub/infozip/Info-Zip.html .
1654
1655The ZIP archive must contain only a single file. Any files in the archive
1656after the first are ignored by FIGdrivers. In addition, the standard
1657extension ".zip" of the archive must be changed to ".flf" or ".flc" as
1658appropriate. It does not matter what the name of the file within the
1659archive is.
1660
1661
1662
1663CHART OF CAPABILITIES OF FIGLET 2.2 AND FIGWIN 1.0
1664===== == ============ == ====== === === ====== ===
1665
1666The following chart lists all capabilities which are either new with the
1667release of both FIGdrivers, or is not a common capability among both.
1668
1669 FIGlet 2.2 FIGWIN 1.0
1670 Interpreting the Full_Layout parameter: Yes Yes
1671 Universal smushing: Yes Yes
1672 Supporting multi-byte input text formats: Yes No
1673 Processing control files: Yes No
1674 Changing default smushing rules: Yes No
1675 Bundled with a GUI editor of FIGfonts: No Yes
1676 Vertical fitting and smushing: No Yes
1677
1678 ___________ __ _
1679 \_ _____/ ____ |__| ____ ___ __ | |
1680 | __)_ / \ | |/ _ < | || |
1681 | \ | \ | ( <_> )___ | \|
1682 /_______ /___| /\__| |\____// ____| __
1683 \/ \/\______| \/ \/