h8rt3rmin8r

FIGfonts Standard

Oct 20th, 2018
962
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  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.  
  48. INTRODUCTION
  49. ============
  50.  
  51. This document specifies the format of font files, and the associated control
  52. files, used by the FIGlet and FIGWin programs (FIGdrivers). It is written
  53. for designers who wish to build fonts (FIGfonts) usable by either program,
  54. and also serves as a standard for development of future versions or similar
  55. FIGdrivers. Some features explained here are not supported by both programs.
  56. See separate documentation to learn how to use FIGlet or FIGWin.
  57.  
  58. NOTE: FIGWin 1.0 is packaged with a program called FIGfont Editor for Windows
  59. 1.0, which is just that. It does not require a complete understanding of
  60. this document to create FIGfonts. However it is a good idea to become
  61. familiar with the "BASIC DEFINITIONS AND CONCEPTS" information before using
  62. it.
  63.  
  64. If you design a FIGfont, please send an e-mail announcement to
  65. <figletfonts@onelist.com>, the FIGlet fonts mailing list, and email a copy
  66. to ianchai@usa.net for him to put it at the ftp site.
  67.  
  68. BASIC DEFINITIONS AND CONCEPTS
  69. ===== =========== === ========
  70.  
  71. "FIGfont"
  72.  
  73. A FIGfont is a file which represents the graphical arrangement of characters
  74. representing larger characters. Since a FIGfont file is a text file, it can
  75. be created with any text editing program on any platform. The filename of a
  76. FIGfont file must end with ".flf", which stands for "<F>IG<L>ettering
  77. <F>ont".
  78.  
  79.  
  80. "FIGcharacters" and "Sub-characters"
  81.  
  82. Because FIGfonts describe large characters which consist of smaller
  83. characters, confusion can result when descussing one or the other.
  84. Therefore, the terms "FIGcharacter" and "sub-character" are used,
  85. respectively.
  86.  
  87.  
  88. "FIGdriver"
  89.  
  90. The term FIGdriver is used in this document to encompass FIGlet, FIGWin, and
  91. any future programs which use FIGfonts.
  92.  
  93.  
  94. "FIGure"
  95.  
  96. A FIGure (thusly capitalized) is an image created by a FIGdriver.
  97.  
  98.  
  99. "FIG"
  100.  
  101. A bit of history:
  102.  
  103. In Spring 1991, inspired by the Email signature of a friend named Frank, and
  104. goaded on by Ian Chai, Glenn Chappell wrote a nifty little 170-line "C"
  105. program called "newban", which would create large letters out of ordinary
  106. text characters. At the time, it was only compiled for UNIX. In hindsight,
  107. we 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
  109. couple of years. It had one font, which included only lowercase letters.
  110.  
  111. In early 1993, Ian decided newban was due for a few changes, so together Ian
  112. and Glenn added the full ASCII character set, to start with. First, though,
  113. Ian had to find a copy of the source, since Glenn had tossed it away as not
  114. worth the disk space. Ian and Glenn discussed what could be done with it,
  115. decided on a general re-write, and, 7 months later, ended up with 888 lines
  116. of code, 13 FIGfonts and documentation. This was FIGlet 2.0, the first real
  117. release.
  118.  
  119. To their great surprise, FIGlet took the net by storm. They received floods
  120. of "FIGlet is great!" messages and a new contributed FIGfont about once a
  121. week. To handle all the traffic, Ian quickly set up a mailing list, Daniel
  122. Simmons kindly offered space for an FTP site, several people volunteered to
  123. port FIGlet to non-Unix operating systems, ...and bug reports poured in.
  124.  
  125. Because of these, and the need to make FIGlet more "international", Ian and
  126. Glenn released a new version of FIGlet which could handle non-ASCII character
  127. sets and right-to-left printing. This was FIGlet 2.1, which, in a couple of
  128. weeks, became figlet 2.1.1. This weighed in at 1314 lines, and there were
  129. over 60 FIGfonts.
  130.  
  131. By late 1996, FIGlet had quite a following of fans subscribing to its mailing
  132. list. It had been ported to MS-DOS, Macintosh, Amiga, Apple II GS, Atari ST,
  133. Acorn and OS/2. FIGlet had been further updated, and there were nearly 200
  134. FIGfonts.
  135.  
  136. John Cowan and Paul Burton are two FIGlet fans who decided to create new
  137. versions. While John wrote FIGlet version 2.2 using C, Paul wrote FIGWin
  138. 1.0, the first true GUI (Windows) implementation of FIGlet, using Visual
  139. Basic. John and Paul worked together to add new features to FIGfont files
  140. which could be read by both programs, and together wrote this document, which
  141. we hope helps to establish consistency in FIGfonts and help with the creation
  142. of future FIGdrivers. FIGlet 2.2 has about 4800 lines of code, of which
  143. over half is a support library for reading compressed files.
  144.  
  145. FIGlet 2.2 and FIGWin 1.0 both allow greater flexibility by use of new
  146. information which can be contained in FIGfont files without interfering with
  147. the function of older FIGdrivers.
  148.  
  149. NOTE: The Macintosh version of FIGlet is still command-line driven as of this
  150. writing, and a GUI version is very much in demand. The FIGlet C code is
  151. written to be easily plugged in to a GUI shell, so it will be a relatively
  152. easy task for a Macintosh developer.
  153.  
  154.  
  155. "Layout Modes"
  156.  
  157. A FIGdriver may arrange FIGcharacters using one of three "layout modes",
  158. which define the spacing between FIGcharacters. The layout mode for the
  159. horizontal axis may differ from the layout mode for the vertical axis. A
  160. default choice is defined for each axis by every FIGfont.
  161.  
  162. The 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.  
  208. For vertical fitting or smushing, entire lines of output FIGcharacters are
  209. "moved" as a unit.
  210.  
  211. Not all FIGdrivers do vertical fitting or smushing. At present, FIGWin 1.0
  212. does, but FIGlet 2.2 does not. Further, while FIGlet 2.2 allows the user to
  213. override the FIGfont designer's set of smushing rules, FIGWin 1.0 does not.
  214.  
  215. NOTE: 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
  217. the smushing rules (if any) to be applied. However, since the layout mode
  218. may or may not involve smushing, we are straying from the use of this
  219. somewhat misleading term.
  220.  
  221.  
  222. "Smushing Rules"
  223.  
  224. Again, smushing rules are for controlled smushing. If none are defined to be
  225. active in a FIGfont, universal smushing occurs instead.
  226.  
  227. Generally, if a FIGfont is "drawn at the borders" using sub-characters
  228. "-_|/\[]{}()<>", you will want to use controlled smushing by selecting from
  229. the rules below. Otherwise, if your FIGfont uses a lot of other
  230. sub-characters, do not select any rules and universal smushing will occur
  231. instead. (See "Hardblanks" below if your FIGfont is very small and would
  232. become illegible if smushed.) Experimentation is the best way to make these
  233. decisions.
  234.  
  235. There are six possible horizontal smushing rules and five possible vertical
  236. smushing rules. Below is a description of all of the rules.
  237.  
  238. NOTE: 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.  
  318. A hardblank is a special sub-character which is displayed as a blank (space)
  319. in rendered FIGures, but is treated more like a "visible" sub-character when
  320. fitting or smushing horizontally. Therefore, hardblanks keep adjacent
  321. FIGcharacters a certain distance apart.
  322.  
  323. NOTE: Hardblanks act the same as blanks for vertical operations.
  324.  
  325. Hardblanks 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.  
  424. When you type using your keyboard, you are actually sending your computer a
  425. series of numbers. Each number must be interpreted by your computer so that
  426. it knows what character to display. The computer uses a list of definitions,
  427. called a "character set". The numbers which represent each character are
  428. called "character codes".
  429.  
  430. There are many character sets, most of which are internationally accepted as
  431. standards. By far, the most common character set is ASCII, which stands for
  432. "American Standard Code for Information Interchange". ASCII identifies its
  433. characters with codes ranging from 0 to 127.
  434.  
  435. NOTE: The term "ASCII art" has become well-understood to mean artistic images
  436. which consist of characters on your screen (such as FIGures).
  437.  
  438. For a list of the printable ASCII characters with the corresponding codes,
  439. see the section "REQUIRED CHARACTERS" below. The other ASCII codes in the
  440. range 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
  442. null (code 0). Code 127 is a delete in ASCII.
  443.  
  444. Getting 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
  446. have DIRECT access to 256 characters at any given time. A character set
  447. which includes 256 characters is called an 8-bit character set.
  448.  
  449. For Latin-based languages, ASCII is almost always the first half of a larger
  450. 8-bit character set. Latin-1 is the most common example of an 8-bit
  451. character set. Latin-1 includes all of ASCII, and adds characters with codes
  452. from 128 to 255 which include umlauted ("double-dotted") letters and
  453. characters with various other accents. In the United States, Windows and
  454. most Unix systems have Latin-1 directly available.
  455.  
  456. Most modern systems allow the possibility of changing 8-bit character sets.
  457. On Windows systems, character sets are referred to as "code pages". There
  458. are many other character sets which are not mentioned here. DOS has its own
  459. character set (which also has international variants) that includes graphics
  460. characters for drawing lines. It is also an extension of ASCII.
  461.  
  462. For some languages, 8-bit character sets are insufficient, particularly on
  463. East Asian systems. Therefore, some systems allow 2 bytes for each
  464. character, which multiplies the 256 possibilties by 256, resulting in 65536
  465. possible characters. (Much more than the world will ever need.)
  466.  
  467. Unicode is a character set standard which is intended to fulfill the
  468. worldwide need for a single character set which includes all characters used
  469. worldwide. Unicode includes character codes from 0 to 65535, although at
  470. present, only about 22,000 characters have been officially assigned and named
  471. by the Unicode Consortium. The alphabets and other writing systems
  472. representable with Unicode include all Latin-alphabet systems, Greek,
  473. Russian and other Cyrillic-alphabet systems, Hebrew, Arabic, the various
  474. languages of India, Chinese, Japanese, Korean, and others. The existing
  475. Unicode symbols include chess pieces, astrological signs, gaming symbols,
  476. telephones, pointing fingers, etc. --- just about any type of FIGcharacter
  477. you may wish to create. Unicode is constantly (but slowly) being extended
  478. to handle new writing systems and symbols. Information on Unicode is
  479. available at http://www.unicode.org and at ftp://unicode.org .
  480.  
  481. Unicode, Latin-1, and ASCII all specify the same meanings for overlapping
  482. character codes: ASCII 65 = Latin-1 65 = Unicode 65 = "A", formally known
  483. as "LATIN CAPITAL LETTER A".
  484.  
  485. Since a keyboard usually has only about 100 keys, your computer may contain
  486. a program called a "keyboard map", which will interpret certain keystrokes
  487. or combinations of keystrokes as different character codes. Keyboard maps
  488. use "mapping tables" to make these determinations. The appropriate keyboard
  489. activity for a given character code may involve several keystrokes. Almost
  490. all systems are capable of handling at least 8-bit character sets (containing
  491. 256 characters), so there is always an active keyboard map, at least for
  492. those characters which are not actually painted on the keys. (United States
  493. users may not even know that their computer can interpret special keystrokes.
  494. Such keystrokes may be something similar to holding down the ALT key while
  495. typing a character code on the numeric keypad. Try it!)
  496.  
  497. Below are characters 160 through 255, AS REPRESENTED ON YOUR SYSTEM.
  498.  
  499. ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ
  500. ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
  501.  
  502. IMPORTANT NOTE: Depending on which character set is active on your system,
  503. you may see different characters. This document (like all computer
  504. documents) does not contains characters per se, only bytes. What you see
  505. above is your particular computer's representation of these byte values.
  506. In other words, your active character set. However, if it is Latin-1, the
  507. first visible character is an inverted "!", and the last is an umlauted "y".
  508. Although we can safely assume your computer has ASCII, it does not
  509. necessarily have the Latin-1 character set active.
  510.  
  511. What does all this have to do with FIGfonts???
  512.  
  513. First, it should be evident that it is best to use only ASCII characters for
  514. sub-characters when possible. This will ensure portability to different
  515. platforms.
  516.  
  517. FIGlet has gained international popularity, but early versions were made to
  518. handle only FIGcharacters with assigned character codes corresponding to
  519. ASCII. 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.  
  557. CREATING FIGFONTS
  558. ======== ========
  559.  
  560. NOTE: FIGWin 1.0 is packaged with a program called FIGfont Editor for Windows
  561. 1.0, which is just that. There is no need to read further if you intend to
  562. use it. However, the section "CONTROL FILES" below is still relevant.
  563.  
  564. Since a FIGfont file is a text file, it can be created with any text editing
  565. program on any platform, and will still be compatible with FIGdrivers on all
  566. operating systems, except that the bytes used to indicate the end of each
  567. text line may vary. (PC's use carriage return and linefeed at the end of
  568. each line, Macintosh uses carriage return only, and UNIX uses linefeed only.)
  569.  
  570. This minor difference among operating systems is handled easily by setting
  571. your FTP program to ASCII mode during upload or download. So there is no
  572. need to be concerned about this as long as you remember to do this during
  573. file transfer.
  574.  
  575. The 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
  577. only letters, and should be lowercase on operating systems which permit case
  578. sensitive filenames. The filename should be unique in the first 8
  579. characters, since some older file systems truncate longer filenames.
  580.  
  581. It is easier to modify an existing FIGfont than it is to create a new one
  582. from scratch. The first step is to read and understand this document.
  583. You may want to load "standard.flf" or another FIGfont into a text editor as
  584. an example while you read.
  585.  
  586. A FIGfont file contains three portions: a header line, comments, and
  587. FIGcharacter data.
  588.  
  589.  
  590. THE HEADER LINE
  591.  
  592. The header line gives information about the FIGfont. Here is an example
  593. showing 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.  
  607. For those desiring a quick explanation, the above line indicates that this
  608. FIGfont uses "$" to represent the hardblank in FIGcharacter data, it has
  609. FIGcharacters which are 6 lines tall, 5 of which are above the baseline, no
  610. line in the FIGfont data is more than 20 columns wide, the default horizontal
  611. layout is represented by the number 15, there are 3 comment lines, the
  612. default print direction for this FIGfont is left-to-right, a complete
  613. description of default and possible horizontal and vertical layouts is
  614. represented by the number 143, and there are 229 code-tagged characters.
  615.  
  616. The first seven parameters are required. The last three (Direction,
  617. Full_Layout, and Codetag_Count, are not. This allows for backward
  618. compatibility with older FIGfonts, but a FIGfont without these parameters would
  619. force a FIGdriver to "guess" (by means not described in this document) the
  620. information it would expect to find in Full_Layout. For this reason, inclusion
  621. of all parameters is strongly recommended.
  622.  
  623. Future versions of this standard may add more parameters after Codetag_Count.
  624.  
  625. A description of each parameter follows:
  626.  
  627. Signature
  628.  
  629. The signature is the first five characters: "flf2a". The first four
  630. characters "flf2" identify the file as compatible with FIGlet version 2.0 or
  631. later (and FIGWin 1.0). The "a" is currently ignored, but cannot be omitted.
  632. Different characters in the "a" location may mean something in future
  633. versions of this standard. If so, you can be sure your FIGfonts will still
  634. work if this character is "a".
  635.  
  636. Hardblank
  637.  
  638. Immediately following the signature is the hardblank character. The
  639. hardblank character in the header line defines which sub-character will be
  640. used to represent hardblanks in the FIGcharacter data.
  641.  
  642. By convention, the usual hardblank is a "$", but it can be any character
  643. except a blank (space), a carriage-return, a newline (linefeed) or a null
  644. character. If you want the entire printable ASCII set available to use, make
  645. the hardblank a "delete" character (character code 127). With the exception
  646. of delete, it is inadvisable to use non-printable characters as a hardblank.
  647.  
  648. Height
  649.  
  650. The Height parameter specifies the consistent height of every FIGcharacter,
  651. measured in sub-characters. Note that ALL FIGcharacters in a given FIGfont
  652. have the same height, since this includes any empty space above or below.
  653. This is a measurement from the top of the tallest FIGcharacter to the bottom
  654. of the lowest hanging FIGcharacter, such as a lowercase g.
  655.  
  656. Baseline
  657.  
  658. The Baseline parameter is the number of lines of sub-characters from the
  659. baseline of a FIGcharacter to the top of the tallest FIGcharacter. The
  660. baseline of a FIGfont is an imaginary line on top of which capital letters
  661. would rest, while the tails of lowercase g, j, p, q, and y may hang below.
  662. In other words, Baseline is the height of a FIGcharacter, ignoring any
  663. descenders.
  664.  
  665. This parameter does not affect the output of FIGlet 2.2 or FIGWin 1.0, but
  666. future versions or other future FIGdrivers may use it. The Baseline
  667. parameter should be correctly set to reflect the true baseline as described
  668. above. It is an error for Baseline to be less than 1 or greater than the
  669. Height parameter.
  670.  
  671. Max_Length
  672.  
  673. The Max_Length parameter is the maximum length of any line describing a
  674. FIGcharacter. This is usually the width of the widest FIGcharacter, plus 2
  675. (to accommodate endmarks as described later.) However, you can (and probably
  676. should) set Max_Length slightly larger than this as a safety measure in case
  677. your FIGfont is edited to include wider FIGcharacters. FIGlet (but not
  678. FIGWin 1.0) uses this number to minimize the memory taken up by a FIGfont,
  679. which 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.  
  687. Between the first line and the actual FIGcharacters of the FIGfont are the
  688. comment lines. The Comment_Lines parameter specifies how many lines there
  689. are. Comments are optional, but recommended to properly document the origin
  690. of a FIGfont.
  691.  
  692. Print_Direction
  693.  
  694. The Print_Direction parameter tells which direction the font is to be
  695. printed by default. A value of 0 means left-to-right, and 1 means
  696. right-to-left. If this parameter is absent, 0 (left-to-right) is assumed.
  697. Print_Direction may not specify vertical print, although FIGdrivers are
  698. capable of vertical print. Versions of FIGlet prior to 2.1 ignore this
  699. parameter.
  700.  
  701. Full_Layout
  702.  
  703. (See "INTERPRETATION OF LAYOUT PARAMETERS" just below.)
  704.  
  705. Codetag_Count
  706.  
  707. Indicates the number of code-tagged (non-required) FIGcharacters in this
  708. FIGfont. This is always equal to the total number of FIGcharacters in the font
  709. minus 102. This parameter is typically ignored by FIGdrivers, but can be
  710. used to verify that no characters are missing from the end of the FIGfont.
  711. The chkfont program will display the number of codetagged characters
  712. in the FIGfont on which it is run, making it easy to insert this parameter
  713. after a FIGfont is written.
  714.  
  715.  
  716. INTERPRETATION OF LAYOUT PARAMETERS
  717.  
  718. Full_Layout describes ALL information about horizontal and vertical layout:
  719. the default layout modes and potential smushing rules, even when smushing is
  720. not a default layout mode.
  721.  
  722. Old_Layout does not include all of the information desired by the most
  723. recent FIGdrivers, which is the inspiration for the creation of the new
  724. Full_Layout parameter. Old_Layout is still required for backward
  725. compatibility, and FIGdrivers must be able to interpret FIGfonts which do not
  726. have the Full_Layout parameter. (See "STANDARDIZED CAPABILITIES OF CURRENT
  727. AND FUTURE FIGDRIVERS".)
  728.  
  729. Versions of FIGlet prior to 2.2 do not recognize the Full_Layout parameter.
  730. Documentation accompanying FIGlet versions prior to 2.2 refer to Old_Layout
  731. as "smushmode", which is somewhat misleading since it can indicate layout
  732. modes other than smushing.
  733.  
  734. Old_Layout and Full_Layout must contain some redundant information.
  735.  
  736. Setting the layout parameters is a matter of adding numbers together ("code
  737. values"). 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,
  739. or if you find this portion confusing.)
  740.  
  741. Full_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.  
  759. When no smushing rules are included in Full_Layout for a given axis, the
  760. meaning is that universal smushing shall occur, either by default or when
  761. requested.
  762.  
  763. Old_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
  776. and 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
  778. also incapable of universal smushing. Therefore they would be directed to
  779. the "next best thing", which is horizontal fitting (kerning).
  780.  
  781. NOTE: You should NOT add the -1 value to any positive code value for
  782. Old_Layout. This would be a logical contradiction.
  783.  
  784. See "STANDARDIZED CAPABILITIES OF CURRENT AND FUTURE FIGDRIVERS" for the
  785. behavior of a FIGdriver when the Full_Layout parameter is absent (presumably
  786. in an older FIGfont).
  787.  
  788. The 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.  
  811. In general terms, if Old_Layout specifies horizontal smushing rules,
  812. Full_Layout must specify the same set of horizontal rules, and both must
  813. indicate the same horizontal default layout mode.
  814.  
  815.  
  816. SETTING LAYOUT PARAMETERS STEP-BY-STEP
  817.  
  818. The following step-by-step process will yield correct and consistent values
  819. for the two layout parameters. You may skip this if you find the
  820. explanations above easier to use.
  821.  
  822. Step 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.  
  829. Step 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.  
  841. Step 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.  
  867. Step 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.  
  878. Step 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.  
  898. Step 6: You're done.
  899.  
  900. The resulting value of Old_Layout will be a number from -1 to 63.
  901. The resulting value of Full_Layout will be a number from 0 and 32767.
  902.  
  903.  
  904. FIGFONT COMMENTS
  905.  
  906. After the header line are FIGfont comments. The comments can be as many
  907. lines as you like, but should at least include your name and Email address.
  908. Here 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.  
  915. Comments are not required, but they are appreciated. Please comment your
  916. FIGfonts.
  917.  
  918. Remember to adjust the Comment_Lines parameter as you add lines to your
  919. comments. Don't forget that blank lines DO count.
  920.  
  921.  
  922. FIGCHARACTER DATA
  923. ============ ====
  924.  
  925. The FIGcharacter data begins on the next line after the comments and
  926. continues to the end of the file.
  927.  
  928. BASIC DATA STRUCTURE
  929.  
  930. The sub-characters in the file are given exactly as they should be output,
  931. with 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.  
  939. In most FIGfonts, the endmark character is either "@" or "#". The FIGdriver
  940. will eliminate the last block of consecutive equal characters from each line
  941. of sub-characters when the font is read in. By convention, the last line of
  942. a FIGcharacter has two endmarks, while all the rest have one. This makes it
  943. easy to see where FIGcharacters begin and end. No line should have more
  944. than two endmarks.
  945.  
  946. Below is an example of the first few FIGcharacters, taken from small.flf.
  947.  
  948. NOTE: The line drawn below consisting of "|" represents the left margin of
  949. your editor. It is NOT part of the FIGfont. Also note that hardblanks are
  950. represented 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.  
  978. Notice that each FIGcharacter occupies the same number of lines (6 lines, in
  979. this case), which must also be expressed in the header line as the Height
  980. parameter.
  981.  
  982. Also 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
  984. be an error.
  985.  
  986. Be aware of the vertical alignment of each FIGcharacter within its height,
  987. so that all FIGcharacters will be properly lined up when printed.
  988.  
  989. If one of the last sub-characters in a particular FIGcharacter is "@", you
  990. should use another character for the endmark in that FIGcharacter so that
  991. the intended "@" is not interpreted as an endmark. "#" is a common
  992. alternative.
  993.  
  994. Load a few existing FIGfonts into your favorite text editor for other
  995. examples.
  996.  
  997.  
  998. REQUIRED FIGCHARACTERS
  999.  
  1000. Some FIGcharacters are required, and must be represented in a specific order.
  1001. Specifically: all of the printable character codes from ASCII shown in the
  1002. table below, in order, plus character codes 196, 214, 220, 228, 246, 252,
  1003. and 223, in that order. In Latin-1, these extra 7 characters represent the
  1004. following German characters: umlauted "A", "O", "U", "a", "o" and "u"; and
  1005. also "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.  
  1058. If you do not wish to define FIGcharacters for all of those required above,
  1059. you MAY create "empty" FIGcharacters in their place by placing endmarks flush
  1060. with the left margin. The Deutsch FIGcharacters are commonly created as
  1061. empty. If your FIGfont includes only capital letters, please copy them to
  1062. the appropriate lowercase locations, rather than leaving lowercase letters
  1063. empty. A FIGfont which does not include at least all ASCII letters, a space,
  1064. and a few basic punctuation marks will probably frustrate some users. (For
  1065. example "@" is more frequently desired as a FIGcharacter than you may think,
  1066. since Email addresses may be written as FIGures.)
  1067.  
  1068.  
  1069. CODE TAGGED FIGCHARACTERS
  1070.  
  1071. After the required FIGcharacters, you may create FIGcharacters with any
  1072. character code in the range of -2147483648 to +2147483647. (Over four
  1073. billion possibilities, which is "virtual infinity" for this purpose.)
  1074. One exception: character code -1 is NOT allowed for technical reasons.
  1075. It is advisable to assign character codes such that the appearance of your
  1076. FIGcharacters matches the expectations of ASCII/Latin-1/Unicode, with a few
  1077. exceptions:
  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.  
  1107. Those FIGcharacters which are not required must have an explicit character
  1108. code in a separate line preceding them, called a "code tag". A code tag
  1109. contains the value of the character code, followed by whitespace (a few
  1110. spaces), and perhaps an optional comment. The comment is usually the name of
  1111. the FIGcharacter. The Unicode Consortium has assigned formal names to all
  1112. officially accepted characters, and these may be used. An entire code tag,
  1113. including the comment, should not occupy more than 95 columns. (Over 100
  1114. characters here may make older versions of FIGlet crash.)
  1115.  
  1116. Here is an example, showing two code tagged FIGcharacters after the last two
  1117. required 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.  
  1148. A character code may be expressed in decimal (as shown above, numbers we're
  1149. all familiar with), or in Octal (seldom used) or in hexadecimal.
  1150.  
  1151. Character codes expressed in octal must be preceded by "0" (zero), and if
  1152. negative, "-" (minus) must precede the "0". There are eight octal digits:
  1153. 01234567. You may recall octal numbers from school as "base 8 numbers".
  1154.  
  1155. Character 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
  1157. 16 hexadecimal digits: 01234567890ABCDEF. (The "letter-digits" may also be
  1158. lowercase.) Hexadecimal is "base 16".
  1159.  
  1160. It is common to express character codes less than 256 (in the range of an
  1161. 8-bit character set) as decimal, while FIGfonts which extend into the Unicode
  1162. range would have character codes expressed in hexadecimal. This is because
  1163. the Unicode Standard expresses character codes in hexadecimal, which is
  1164. helpful for programmers.
  1165.  
  1166. The code tagged FIGcharacters may be listed in any order, but simple
  1167. sequential order is recommended.
  1168.  
  1169. If two or more FIGcharacters have the same character code, the last one in
  1170. the FIGfont is the one used. It is common for the Deutsch FIGcharacters to
  1171. be given twice in a FIGfont, just to maintain a consistent order for the
  1172. Latin-1 range (128 to 255).
  1173.  
  1174. It is not advisable to assign character codes in the range of 1 to 31, since
  1175. this range includes control characters in ASCII. Character code 127 is a
  1176. delete in ASCII, and is also not advised. Character codes 128 to 159 are
  1177. additional control characters in Latin-1, and they too should not be used.
  1178. All of the above are legal, technically, but are not part of what is legal
  1179. for 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
  1181. negative character codes instead, which are meaningless in all standardized
  1182. character sets.
  1183.  
  1184. Again, the character code -1 is illegal for technical reasons.
  1185.  
  1186.  
  1187. NOTES - AVOIDING ERRORS AND GENERAL ADVICE
  1188. ===== ======== ====== === ======= ======
  1189.  
  1190. It is very important that every character in a font has the same height, and,
  1191. once the endmarks are removed, that all the lines constituting a single
  1192. FIGcharacter have the same length. Be careful also that no lines in the font
  1193. file have trailing blanks (spaces), as the FIGdriver will take these to be
  1194. the endmarks. (FIGWin 1.0 will not consider blanks to be endmarks.)
  1195.  
  1196. Errors in a FIGfont can be detected by using the "chkfont" program,
  1197. part of the standard FIGlet package, and also available, as of this
  1198. writing from http://st-www.cs.uiuc.edu/users/chai/figlet.html.
  1199. For FIGWin users, the FIGWin program will report errors when a FIGfont is
  1200. read in; it is less forgiving than FIGlet, which can produce nonsense if the
  1201. FIGfont is incorrectly formatted.
  1202.  
  1203. Remember that sub-characters outside of the ASCII range will not necessarily
  1204. display the same way on your system as on others.
  1205.  
  1206. The blank (space) FIGcharacter should usually consist of one or two columns
  1207. of hardblanks and nothing else; slanted fonts are an exception to this rule.
  1208. If the space FIGcharacter does not contain any hardblanks, it will disappear
  1209. when horizontal fitting (kerning) or smushing occurs.
  1210.  
  1211. Again, if you design a FIGfont, please let us know!
  1212.  
  1213.  
  1214. CONTROL FILES
  1215. ======= =====
  1216.  
  1217. A FIGfont control file is a separate text file, associated with one or more
  1218. FIGfonts, that indicates how to map input characters into FIGfont character
  1219. codes. By default, FIGdrivers read single bytes from the input source and
  1220. interpret them as Latin-1 FIGcharacters.
  1221.  
  1222. FIGlet version 2.2 (and later) can optionally interpret its input as DBCS or
  1223. UTF-8 characters, making it possible to access FIGcharacters with codes
  1224. outside the Latin-1 range (greater than 255).
  1225.  
  1226. In addition, though, all versions of FIGlet can use control files to
  1227. transform specific character codes (or ranges of codes) as other codes
  1228. (or ranges). Multiple control files can be specified, in which case multiple
  1229. stages of transformation are performed.
  1230.  
  1231. The filename of a control file always ends with ".flc".
  1232.  
  1233. CONTROL FILE FORMAT
  1234.  
  1235. Control files contain several kinds of lines. Lines beginning with "#", as
  1236. well as blank lines, are comment lines and are ignored. All other lines are
  1237. command lines, with one of the following formats:
  1238.  
  1239. t inchar outchar
  1240. t inchar1-inchar2 outchar1-outchar2
  1241. number number
  1242. f
  1243. h
  1244. j
  1245. b
  1246. u
  1247. g{0|1|2|3} {94|96|94x94} [char]
  1248. g{L|R} {0|1|2|3}
  1249.  
  1250. where "inchar", "outchar", and "char" are either Latin-1 characters
  1251. representing their own codes, or else are numeric character codes preceded by
  1252. a "\" character; and "number" is a numeric character code with no preceding
  1253. "\" character.
  1254.  
  1255. Thus "A" represents the code 65, as does "\65", and "\0x100" represents the
  1256. code 256 (100 in hexadecimal). In addition, "\ " (backslash followed by a
  1257. space) represents the code 32 (space), and the following backslash sequences
  1258. are also understood:
  1259.  
  1260. \a code 7 (a bell/alert)
  1261. \b code 8 (a backspace)
  1262. \e code 27 (an ESC character)
  1263. \f code 12 (a form feed)
  1264. \n code 10 (a newline/line feed)
  1265. \r code 13 (a carriage return)
  1266. \t code 9 (a horizontal tab)
  1267. \v code 11 (a vertical tab)
  1268. \\ code 92 (a backslash)
  1269.  
  1270. All of these combinations except perhaps "\\" are very unlikely to be used,
  1271. but they are provided just in case they are needed.
  1272.  
  1273. Whitespace characters are used between "t" and "inchar" and between "inchar"
  1274. and "outchar", but not around the "-" characters used in the second type of
  1275. "t" command.
  1276.  
  1277. The term "string" refers to any number of characters represented in the
  1278. format given above. The characters begin after the whitespace following the
  1279. letter "s", and continue to the end of the line.
  1280.  
  1281. Anything following the first letter of an "f", "h", "j", or "u" command is
  1282. ignored.
  1283.  
  1284. The first type of "t" command transforms characters with the code "inchar"
  1285. into characters with the code "outchar". The second type of "t" command
  1286. transforms characters in the range "inchar1" to "inchar2" as the
  1287. corresponding codes in the range "outchar1" to "outchar2". Both ranges must
  1288. be of the same size. The form "number number" is equivalent to a "t"
  1289. command of the first type, and is provided for compatibility with the mapping
  1290. tables issued by the Unicode Consortium.
  1291.  
  1292. Multiple transformation stages can be encoded in a single control file by
  1293. using "f" commands to separate the stages.
  1294.  
  1295. Versions of FIGlet before 2.1 required that the first line of a control file
  1296. consist of the signature string "flc2a". This signature line is still
  1297. permitted in FIGlet 2.2 and later versions, but is no longer required.
  1298.  
  1299. Here is an example of a control file. The blanks at the beginning of each
  1300. line are for readability only, and are not part of the file.
  1301.  
  1302. The following control file:
  1303.  
  1304. flc2a
  1305. t # $
  1306. t A-Z a-z
  1307.  
  1308. will map the "#" character to "$", and will also convert uppercase ASCII to
  1309. lowercase ASCII.
  1310.  
  1311. If a number of consecutive "t" commands are given, then for each character
  1312. processed, only the first applicable command (if any) will be executed.
  1313. Consider this control file:
  1314.  
  1315. t A B
  1316. t B A
  1317.  
  1318. It will swap the characters "A" and "B". If the FIGdriver reads an "A", the
  1319. first command will change "A" to "B", in which case the second will not be
  1320. executed. If the FIGdriver reads a "B", the first command will have no
  1321. effect, and the second command will change "B" to "A". Here is another
  1322. control file:
  1323.  
  1324. t A B
  1325. t A C
  1326.  
  1327. In this example, the second line is never executed. In short, a sequence of
  1328. "t" lines "does what it ought to".
  1329.  
  1330. More complex files, in which a single character is acted upon by several "t"
  1331. commands, can be set up using an "f" command. For example:
  1332.  
  1333. flc2a
  1334. t a-z A-Z
  1335. f
  1336. t Q ~
  1337.  
  1338. This control file specifies two transformation stages. In the first stage,
  1339. lowercase ASCII letters are changed to their uppercase equivalents. The
  1340. second stage maps any Q (whether original or a converted "q") into the "~"
  1341. character. If the "f" command were omitted, "q" characters would remain "Q"
  1342. and not be converted to "~".
  1343.  
  1344. EXTENDED COMMANDS
  1345.  
  1346. The "h", "j", "b", "u", and "g" commands are only understood by FIGlet
  1347. version 2.2 or later. They control how a FIGdriver interprets bytes in the
  1348. input. By default, the FIGdriver interprets each byte of input as a distinct
  1349. character. This mode is suitable for most character encodings. All these
  1350. commands are logically acted on before any other control file commands, no
  1351. matter where in the sequence of control files they appear. They are also
  1352. mutually exclusive; if more than one of these commands is found, only the
  1353. last is acted on. Multiple "g" commands are permitted, however.
  1354.  
  1355. The "h" command forces the input to be interpreted in HZ mode, which is used
  1356. for the HZ character encoding of Chinese text. In this mode, the sequence
  1357. "~{" (which is removed from the input) signals that all following characters
  1358. are two bytes long until the sequence "~}" is detected. In addition, the
  1359. sequence "~~" is changed to just "~", and all other two-byte sequences
  1360. beginning with "~" are removed from the input. The character code
  1361. corresponding to a two-byte character is:
  1362.  
  1363. first character * 256 + second character
  1364.  
  1365. The "j" command forces the input to be interpreted in Shift-JIS mode (also
  1366. called "MS-Kanji mode"). Input bytes in the ranges 128-159 and 224-239 are
  1367. read as the high-order byte of a two-byte character; all other bytes are
  1368. interpreted as one-byte characters. The value of a two-byte character is
  1369. determined in the same way as in HZ mode.
  1370.  
  1371. The "b" command forces the input to be interpreted in DBCS mode, which is
  1372. suitable for processing HZ or Shift-GB Chinese text or Korean text. Input
  1373. bytes in the ranges 128-255 are read as the high-order byte of a two-byte
  1374. character; all other bytes are interpreted as one-byte characters. The
  1375. value of a two-byte character is determined in the same way as in HZ mode.
  1376.  
  1377. The "u" command forces the input to be interpreted in UTF-8 mode, which
  1378. causes any input byte in the range 0x80 to 0xFF to be interpreted as the
  1379. first byte of a multi-byte Unicode (ISO 10646) character. UTF-8 characters
  1380. can be from 1 to 6 bytes long. An incorrectly formatted sequence is
  1381. interpreted as the character 128 (normally an unused control character).
  1382.  
  1383. Otherwise, the input is allowed to contain ISO 2022 escape sequences, which
  1384. are decoded to generate appropriate character codes. These character codes
  1385. are *not* a subset of Unicode, but may be more useful in processing East
  1386. Asian text. A brief explanation of ISO 2022 is given here in order to
  1387. clarify how a FIGdriver should interpret it. The "g" command provides
  1388. information for the ISO 2022 interpreter, and is explained below.
  1389.  
  1390. ISO 2022 text is specified using a mixture of registered character sets.
  1391. At any time, up to four character sets may be available. Character sets
  1392. have one of three sizes: single-byte character sets with 94 characters
  1393. (e.g. ASCII), single-byte character sets with 96 characters (e.g. the top
  1394. halves of ISO Latin-1 to Latin-5), or double-byte character sets with
  1395. 94 x 94 characters (e.g. JIS 0208X-1983). Each registered character set has
  1396. a standard designating byte in the range 48 to 125; the bytes are unique withi
  1397. n character set sizes, but may be reused across sizes. For example, byte 66
  1398. designates the 94-character set ASCII, the 96-character set ISO Latin-2 (top
  1399. half), and the 94 x 94 Japanese character set JIS 0208X-1983. In this
  1400. document, the designating byte of a character set will be represented by <D>.
  1401.  
  1402. The four available character sets are labeled G0, G1, G2, and G3. Initially,
  1403. G0 is the 94-character set ASCII, and G1 is the 96-character set ISO Latin-1
  1404. (top half). The other character sets are unassigned. The following escape
  1405. sequences (where ESC = the byte 27) specify changes to the available
  1406. character sets:
  1407.  
  1408. ESC ( <D> Set G0 to the 94-character set <D>
  1409. ESC ) <D> Set G1 to the 94-character set <D>
  1410. ESC * <D> Set G2 to the 94-character set <D>
  1411. ESC + <D> Set G3 to the 94-character set <D>
  1412. ESC - <D> Set G1 to the 96-character set <D>
  1413. ESC . <D> Set G2 to the 96-character set <D>
  1414. ESC / <D> Set G3 to the 96-character set <D>
  1415. ESC $ <D> Set G0 to the 94 x 94 character set <D>
  1416. ESC $ ( <D> Set G0 to the 94 x 94 character set <D>
  1417. ESC $ ) <D> Set G1 to the 94 x 94 character set <D>
  1418. ESC $ * <D> Set G2 to the 94 x 94 character set <D>
  1419. ESC $ + <D> Set G3 to the 94 x 94 character set <D>
  1420.  
  1421.  
  1422. Note that G0 may not be a 96-character set, and that there are two ways to
  1423. specify a 94 x 94 character set in G0, of which the first is deprecated.
  1424.  
  1425. ISO 2022 decoding affects input bytes in the ranges 33 to 126 and 160 to 255,
  1426. known as "the left half" and "the right half" respectively. All other bytes,
  1427. unless they belong to a control sequence shown in this document, remain
  1428. unchanged. Initially, the left half is interpreted as character set G0,
  1429. and the right half as character set G1. This can be changed by the following
  1430. control sequences:
  1431.  
  1432. SI (byte 15) Interpret the left half as G1 characters
  1433. SO (byte 14) Interpret the left half as G0 characters
  1434. ESC n Interpret the left half as G2 characters
  1435. ESC o Interpret the left half as G3 characters
  1436. ESC ~ Interpret the right half as G1 characters
  1437. ESC } Interpret the right half as G2 characters
  1438. ESC | Interpret the right half as G3 characters
  1439. SS2 (byte 142) Interpret next character only as G2
  1440. ESC N Interpret next character only as G2
  1441. SS3 (byte 143) Interpret next character only as G3
  1442. ESC O Interpret next character only as G3
  1443.  
  1444.  
  1445. This rich schema may be used in various ways. In ISO-2022-JP, the Japanese
  1446. flavor of ISO 2022, only the bytes 33-126 and the G0 character set is used,
  1447. and escape sequences are used to switch between ASCII, ISO-646-JP (the
  1448. Japanese national variant of ASCII), and JIS 0208X-1983. In other versions,
  1449. the G1 character set has 94 x 94 size, and so any byte in the range 160-255
  1450. is automatically the first byte of a double-byte character.
  1451.  
  1452. FIGdrivers that support ISO 2022 do so in the following way. Each character i
  1453. is decoded and assigned to a character set <D>.
  1454.  
  1455. If the character belongs to a 94-bit character set,
  1456. then if its value exceeds 128, it is reduced by 128,
  1457. and the value 65536 * <D> is added to it,
  1458. unless <D> is 66 (ASCII).
  1459. If the character belongs to a 96-bit character set,
  1460. then if its value is less than 128, it is increased by 128,
  1461. and the value 65536 * <D> is added to it,
  1462. unless <D> is 65 (ISO Latin-1).
  1463. If the character belongs to a 94 x 94 character set,
  1464. then the value is the sum of:
  1465. the first byte * 256,
  1466. plus the second byte,
  1467. plus the value 65536 * <D>.
  1468.  
  1469.  
  1470. Thus, the character code 65 ("A") in ASCII remains 65, the character code
  1471. 196 in ISO Latin-1 ("A-umlaut") remains 196, the character code 65 (0x41)
  1472. in ISO-646-JP (whose <D> is 74 = 0x4A) becomes 0x4A0041 =4849729, and the
  1473. two-byte sequence 33 33 (0x21 0x21) in JIS 0208X-1983 (whose <D> is
  1474. 65 = 0x41) becomes 0x412121 = 4268321. These codes may be used in compiling
  1475. FIGfonts suitable for use with ISO 2022 encoded text.
  1476.  
  1477. The initial settings of G0 through G3 and their assignments to the left half
  1478. and the right half can be altered in a control file by using "g" commands,
  1479. as follows:
  1480.  
  1481. g {0|1|2|3} {94|96|94x94} [<D>]
  1482.  
  1483. specifies that one of G0-G3 is a 94, 96, or 94x94 character set with
  1484. designating character <D>. If no designating character is specified, then a
  1485. <D> value of zero is assumed.
  1486.  
  1487. For example, the list of control commands:
  1488.  
  1489. g 0 94 B
  1490. g 1 96 A
  1491.  
  1492. sets the G0 character set to ASCII (94-character set "B") and the G1
  1493. character set to the top half of Latin-1 (96-character set "A"). (This is the
  1494. default setting).
  1495.  
  1496. To change the initial assignments of G0 to the left half and G1 to the right
  1497. half, "g" commands of the form
  1498.  
  1499. g {L|R} {0|1|2|3}
  1500.  
  1501. For example, the command:
  1502.  
  1503. g R 2
  1504.  
  1505. causes right-half bytes (in the range 160-255) to be interpreted as G2.
  1506. Whether these bytes are interpreted singly or in pairs depends on the type
  1507. of character set that is currently available as G2.
  1508.  
  1509. Spaces may be freely used or omitted in "g" commands.
  1510.  
  1511. The standard FIGlet distribution contains mapping tables for Latin-2 (ISO 8859-2),
  1512. Latin-3 (ISO 8859-3), Latin-4 (ISO 8859-4), and Latin-5 (ISO 8859-9). They
  1513. can be used with the font "standard.flf", which contains all the characters
  1514. used in these standards.
  1515.  
  1516.  
  1517. STANDARDIZED CAPABILITIES OF CURRENT AND FUTURE FIGDRIVERS
  1518. ============ ============ == ======= === ====== ==========
  1519.  
  1520. We assert the following as the "Law" of our intentions:
  1521.  
  1522. PROFIT
  1523.  
  1524. All future FIGdrivers shall be FREE OF CHARGE to the general public via the
  1525. Internet. Any advertisements of other works by the author must be in
  1526. documentation only, and limited to ONE "screenful", and shall not appear by
  1527. normal program behavior, nor interfere with normal behavior. No FIGdriver
  1528. shall disable itself after a set period of time or request "donations".
  1529. No FIGdriver shall offer any other FIGdriver with improved capability for
  1530. creating FIGures in exchange for money.
  1531.  
  1532. REQUIRED FEATURES OF FUTURE VERSIONS
  1533.  
  1534. Future FIGdrivers must read and process FIGfont files as described in this
  1535. document, but are not necessarily expected to process control files, smush,
  1536. perform fitting or kerning, perform vertical operations, or even produce
  1537. multiple lines in output FIGures.
  1538.  
  1539. FIGDRIVER NAMES
  1540.  
  1541. Future FIGdrivers must be named to include capitalized "FIG" and shall have
  1542. an incremental version number specific to its own platform.
  1543.  
  1544. BACKWARDS COMPATIBILITY OF FUTURE VERSIONS
  1545.  
  1546. Any future FIGdriver created for the same platform as an existing FIGdriver,
  1547. and using the same name as the existing FIGdriver, shall be considered a new
  1548. version of the preceding FIGdriver, and shall contain all historical comments
  1549. of updates to past versions on the same platform, and shall have full
  1550. capability of the preceding versions. If the source code is not provided to
  1551. the general public, it shall be at least provided to any potential developers
  1552. of later versions, and such comments relating to past versions shall be
  1553. accessible to any user by other means or documentation. If a new program is
  1554. created on a platform that already has an existing FIGdriver, it must be
  1555. given a new and distinct name. This allows multiple FIGdrivers to exist for
  1556. the same platform with different capabilities.
  1557.  
  1558. The format of FIGfonts may not be modified to be non-backwards compatible
  1559. UNLESS:
  1560.  
  1561. 1) The new format is easily editable as an ASCII text file,
  1562. beginning with the characters "flf" followed by a sequential
  1563. number.
  1564.  
  1565. 2) At least all of the same information can be derived from the
  1566. new format as the prior format (currently "flf2"). This
  1567. includes the main comments which give credit to the FIGfont
  1568. designer.
  1569.  
  1570. 3) Individuals are found who are willing and have the ability to
  1571. either port or develop versions for at least UNIX, DOS,
  1572. Windows, and Amiga which will read both the new formats AND the
  1573. prior format (currently "flf2"), and retain the capability of
  1574. past versions. It is intended that this will be expanded to
  1575. include Macintosh if a GUI version exists. This list of
  1576. required operating systems may be reduced if an operating
  1577. system falls out of popularity or increased if a new operating
  1578. system for which there is a FIGdriver comes into greater
  1579. popularity, according to the consensus of opinions of past
  1580. developers for the most popular operating systems.
  1581.  
  1582. 4) A C, Java, or other version must always exist which can
  1583. receive input and instructions either from a command line, a
  1584. file, or directly over the internet so that FIGures can be
  1585. obtained from internet-based services without the need to
  1586. download any FIGdriver.
  1587.  
  1588. 5) All existing FIGfonts available from the "official" point of
  1589. distribution (http://st-www.cs.uiuc.edu/users/chai/figlet.html),
  1590. must be converted to the new format, and offered for download
  1591. alongsidethe new versions.
  1592.  
  1593. THE FUNCTION OF WORD WRAPPING
  1594.  
  1595. All future FIGdrivers should duplicate these behaviors, unless a version is
  1596. only capable of outputting one-line FIGures, which is acceptable as long no
  1597. preceding versions exist for its platform which can output multiple-line
  1598. FIGures.
  1599.  
  1600. FIGdrivers which perform word wrapping do so by watching for blanks (spaces)
  1601. in input text, making sure that the FIGure is no more wide than the maximum
  1602. width allowed.
  1603.  
  1604. Input text may also include linebreaks, so that a user may specify where
  1605. lines begin or end instead of relying on the word wrapping of the FIGdriver.
  1606. (Linebreaks are represented by different bytes on different platforms, so
  1607. each FIGdriver must watch for the appropriate linebreaks for its particular
  1608. platform.)
  1609.  
  1610. When a FIGdriver word wraps and there are several consecutive blanks in input
  1611. text where the wrapping occurred, the FIGdriver will disregard all blanks
  1612. until the next non-blank input character is encountered. However, if blanks
  1613. in input text immediately follow a linebreak, or if blanks are the first
  1614. characters in the input text, the blanks will be "printed", moving any
  1615. visible FIGcharacters which follow on the same output line to the right.
  1616. Similarly, if an image is right-aligned, and blanks immediately precede
  1617. linebreaks or the end of input text, a FIGdriver will move an entire line of
  1618. output FIGcharacters to the left to make room for the blank FIGcharacters
  1619. until the left margin is encountered. (If the print direction is
  1620. right-to-left, everything stated in this paragraph is reversed.)
  1621.  
  1622. Word processing programs or text editors usually behave similarly in all
  1623. regards to word wrapping.
  1624.  
  1625. GENERAL INTENT FOR CROSS-PLATFORM PORTABILITY
  1626.  
  1627. Currently, all versions of FIGlet are compiled from C code, while FIGWin 1.0
  1628. is written in Visual Basic. Over time it is intended that a later version of
  1629. FIGWin will be created using a GUI C programming language, and that the
  1630. FIGlet C code shall continue to be written to be easily "plugged in" to a
  1631. GUI shell. It is preferable for developers of FIGdrivers for new platforms
  1632. to use C or a GUI version of C, so that when the core rendering engine of
  1633. FIGlet is updated, it will be portable to other platforms.
  1634.  
  1635. CONTROL FILE COMMANDS
  1636.  
  1637. New control file commands may be added to later versions of this standard.
  1638. However, the commands "c", "d", and "s" are permanently reserved and may
  1639. never be given a meaning.
  1640.  
  1641. FILE COMPRESSION
  1642.  
  1643. FIGfonts (and control files) are often quite long, especially if many
  1644. FIGcharacters are included, or if the FIGcharacters are large. Therefore,
  1645. some FIGdrivers (at present, only FIGlet version 2.2 or later) allow
  1646. compressed FIGfonts and control files.
  1647.  
  1648. The standard for FIG compression is to place the FIGfont or control file into
  1649. a ZIP archive. ZIP archives can be created by the proprietary program PKZIP
  1650. on DOS and Windows platforms, or by the free program Info-ZIP ZIP on almost
  1651. all platforms. More information on ZIP can be obtained at
  1652. http://www.cdrom.com/pub/infozip/Info-Zip.html .
  1653.  
  1654. The ZIP archive must contain only a single file. Any files in the archive
  1655. after the first are ignored by FIGdrivers. In addition, the standard
  1656. extension ".zip" of the archive must be changed to ".flf" or ".flc" as
  1657. appropriate. It does not matter what the name of the file within the
  1658. archive is.
  1659.  
  1660.  
  1661.  
  1662. CHART OF CAPABILITIES OF FIGLET 2.2 AND FIGWIN 1.0
  1663. ===== == ============ == ====== === === ====== ===
  1664.  
  1665. The following chart lists all capabilities which are either new with the
  1666. release of both FIGdrivers, or is not a common capability among both.
  1667.  
  1668. FIGlet 2.2 FIGWIN 1.0
  1669. Interpreting the Full_Layout parameter: Yes Yes
  1670. Universal smushing: Yes Yes
  1671. Supporting multi-byte input text formats: Yes No
  1672. Processing control files: Yes No
  1673. Changing default smushing rules: Yes No
  1674. Bundled with a GUI editor of FIGfonts: No Yes
  1675. Vertical fitting and smushing: No Yes
  1676.  
  1677. ___________ __ _
  1678. \_ _____/ ____ |__| ____ ___ __ | |
  1679. | __)_ / \ | |/ _ < | || |
  1680. | \ | \ | ( <_> )___ | \|
  1681. /_______ /___| /\__| |\____// ____| __
  1682. \/ \/\______| \/ \/
RAW Paste Data