c Xerox Corporation 1980XEROXPALO ALTO RESEARCH CENTERComputer Sciences LaboratoryOctober 1, 1980To:FileFrom:Bob Sproull (revised by Dan Swinehart and Lyle Ramshaw)Subject:Font Representations and FormatsFiled on:FontFormats.PressSources:FontFormatsA.Bravo andFontFormatsB.BravoThis report presents the various standard and device-dependent font formats in use at PARC.1. IntroductionA font is a collection of character descriptions, indexed by a character code. These descriptionsrepresent, in one fashion or another, the appearance of the character. The ultimate purpose ofmaintaining a font is for use when generating a raster-scanned image of a document. This imagemay be created on a display and used for interactive purposes, or it may be generated by a printingservice as part of a "hard copy" function. In both cases, for purposes of space and deviceindependence, the document itself does not normally contain the character representations, but onlycodes used to identify the characters that comprise the document.It is important to distinguish font representations from font formats.We use two generically different representations for character shapes. The first, loosely termed"splines" or "spline fonts," represents the outline of the each character shape with a series ofparametric cubic spline curves (see Figure 1). This representation is handy because it isindependent of the particular output device and its resolution: the outlines describe the desiredappearance of the character. The second representation we use is a raster (sometimes looselytermed a "bit map"), as shown in Figure 2. This representation records, in some way, a two-dimensional (binary) occupancy map: it tells where the character lies on a two-dimensional grid.This representation is handy for actually building raster images of documents: the occupancy map iscombined with color information, often at very high speed, to generate a larger raster image of thedocument. The raster character description is in effect merged into the page raster at the properposition.When characters are recorded in font files, we choose a particular format for the file; quite anumber of different formats have emerged. This is because there are many ways to encode digitallythe information in either an outline or raster representation of a character. The details of theencoding are often of vital concern when making a particular piece of hardware or softwaregenerate page rasters rapidly.Fortunately, we can write conversion programs that are able to generate the various specializedformats from standard formats. When an artist (or a needy user) devotes a large amount of effort todesigning and debugging a font, it should be recorded and disseminated in one of the standardformats. Clients can then easily convert to one of the subsidiary formats, or to their own privateformat.",OpqX%D]Kr[s!@Yt%Xxq Upu`q Rhu`q7 Ou`q Mu` K`$`J FHqVuq Cs ?q>$ >mT <I ;eD 9*0 8]I 6A 3tqt 0q!tq .V -z C  +C *r!#tq (+1 'i2. %C $a&= "9tq !Y .t qtq )9 &a E  $; n tq#$ P fI  \ >])3Font Representations and Formats2WidthsAn important adjunct to the font descriptions themselves is the "widths file," which summarizes thedimensions of all characters in the font data base. This summary must be available to a text editorwhen it formats a document for hard copy: the widths are used to determine how many characterswill fit on a line and to perform justification calculations. Because the information in this file canbe independent of any particular output device, the hard-copy file produced by the editor can beprinted on any of a number of printing devices. The widths summary is, in effect, extracted frominformation recorded in the standard formats of the relevant fonts.There are several different flavors of width files now in existence. Some of them contain widthsthat can be scaled to handle different sizes of a font; others apply to only one size. Some widthfiles give the height and depth dimensions of the design box of each character separately, whereothers give only the font bounding box and the individual widths. The type of width file that giveseach character's design box is used by the TEX document compiler, and is not discussed in detail inthis memo.SoftwareThe PARC font descriptions are supported by a reasonably full set of software:FRED: Interactive program for building outline font representations. Documentation is onFred.Press. The program is on Fred.Dm.PREPRESS: Interactive program for building standard raster font representations. Theprogram also contains numerous options for converting from standard to subsidiary formats.Documentation is on PrePress.Press. The program is on PrePress.Run.COMPRESS (Obsolete): A program that converts .CU format to EARS (.EP and .EL) formats.The program is on Compress.Run.The reader is invited to consult PrePress documentation (PrePress.Press) for miscellaneouslore relating to fonts and for "standard operating procedures" for maintaining font files.PeopleThis document is simply a convenient summary of formats and techniques developed by a largenumber of individuals. The people behind the formats include Patrick Baudelaire, Peter Deutsch,Joe Maleson, Diana Merry, Ron Rider, Bob Sproull, Dan Swinehart, Larry Tesler, and ChuckThacker.2. TerminologyThe terminology that has developed around fonts is hopelessly inconsistent. This section is intendedto serve as a glossary for the descriptions in the remainder of this document. Be forewarned thatterminology used elsewhere may not match.2.1 CharactersFamily is the term given to a particular design of characters. Examples of families are"TimesRoman", or "Helvetica".Point size of a character refers to size measurements used in the printing industry. If text is npoints high, this means that closely-spaced lines of text will fall n/72 inches apart on the page.Note that the point size does not relate in any consistent way to the geometry of characters, e.g., to gfqXHY _t [q_ ZfS X4* W^U UO TVN RC OR N#H L R KK I+uq( H Dt AquqF>uq@= u quq9uqM8]Q6u q#uq 3uq'uq uququq 2)uq . ,u q! -zZ *Nt '#qF %=# $(0 " ks @q23 N 8)  t qR ] 2t qRt q3tq *I >](;Font Representations and Formats3the height of an upper case A.Face denotes a number of attributes of a particular font: italic, bold, light, condensed, expanded areall attributes of the font. Sometimes this is called a "style." Sometimes the face is defined with athree-letter code: the first letter is L for light, M for medium, or B for bold; the second is R forregular or I for italic; the third is C for condensed, R for regular or E for expanded. An optionalfourth character can be used to specify the character coding used in the font: X for Xerox-style, Afor ASCII, and O for other.Rotation refers to the orientation of the character. If a string of characters is intended to behorizontal, it has rotation zero; if a string runs vertically upward, it has a rotation of 90 degrees.Font, as we use the term, refers to a collection of characters of the same family, the same size, thesame rotation, and the same face attributes.Character code refers to a number (usually only 8 bits) that identifies a character. All our fonts usean approximation to the standard ASCII convention, when that convention is meaningful. Forspecial-character fonts (e.g., mathematics, logic design), another mapping must generally be devised.Origin of a character (sometimes called "the (0,0) point") is conceptually a reference mark that isused to describe a character's location on a page or display. Thus a directive to "display an A atx=103, y=204" is interpreted to mean "place an instance of the symbol A on the display so thatthe character origin coincides with the coordinate x=103, y=204." Figures 1 and 2 show the originof a sample character. Note that the origin is located midway between pixels in each dimension,not in the center of a pixel.Width of a character is a two-dimensional vector that represents the incremental translation thatshould take place to determine the placement of the origin of the next character to be displayed ina (conventionally aligned) string of characters. In the example of Figure 3, if we assume the xdirection points to the right and the y direction up, we see that the width vector has a zero ycomponent. In this document, we will refer to the components of the width vector as Wx and Wy.In all our font representations, we associate the width vector with each character code. If this width vector isused for character positioning, the spacing between the origin of a A (say) and the origin of the next characteris independent of that next character. This is not always desirable: because of the different shapes ofcharacters, spacing between differing pairs may want to be adjusted slightly to make the text line appear morepleasing.An empty character is one with an empty occupancy map; in particular, an empty character is someflavor of space.Bounding box is the term for a rectangle that just barely surrounds the character (see Figure 3). Itis characterized by its width and height, and by a two-dimensional vector that specifies where thelower-left corner of the bounding box is with respect to the origin of the character inside. Thesefour numbers are named (in this document) BBdx, BBdy, BBox, and BBoy.An empty character, by convention, has both BBdx and BBdy equal to zero. BBox and BBoy makeeven less sense for an empty character; they are often set to zero as well.The font bounding box is a bounding box that applies to all characters in the font. That is, if all thecharacters in the font were placed with their origins coincident, the smallest rectangle that enclosesevery part is the font bounding box. The four parameters of the font bounding box are named (inthis document) FBBdx, FBBdy, FBBox, and FBBoyThe coordinate system assumed for this document is that x points to the right on a (portrait-oriented) page, and y points up. A mica is a unit of measure, equal to 10 microns or 1/2540 inch. gfqXHY _uq [tq6t(q ZfS X'uq uq uquq W^ uquq uquq U<uqu TVququq Q+tqV OT L{tqR J, Gt q.+ FHuq5 D+: AtqU @[uq >Fuq = b ;P : 6tqtq1 5U/4 38't 2Lq&tqt 0q8uquq-un,K%+E,<*%I( %|qtqtq: # t qI Htqtq: 8+ @*u ququq uquququq K etq#tq% N ].2 u ququ qtq#tq *tqtq$ =](Font Representations and Formats4Both of these conventions are identical to those used by Press. Scanning mode refers to the way a raster is laid upon a character description. This in effect definesa coordinate system in which one direction is measured in scan-lines and the other direction ismeasured in bits (along a scan line). To describe the modes, we use a single number that relates thescanning regime to the conventional (x,y) coordinate system: the mode is bit-direction-description*4+ scan-line-direction-description, where a direction-description is:0 if the coordinate increases as x increases1 if the coordinate decreases as x increases2 if the coordinate increases as y increases3 if the coordinate decreases as y increasesThis convention is identical to the one used by Press and AIS. We use it in this document tocharacterize character encodings: if a raster is encoded in mode 8, then the first bit of the bit streamdefining the character will be at the lower left-hand corner of the character; the next bit will be justabove the first, and so on up the page (because the bit-direction-description is 2); then the nextscan-line to the right will be given (because the scan-line-direction-description is 0).Note that there is a relation between rotation and scanning mode. For example, a character encodedwith rotation=0, scanning mode=3 is identical to one recorded with rotation=90 degrees, scanningmode=8.2.2 File terminologyA file is a homogeneous sequence of data bits. (We at PARC do not have any file systems that havethe concept of "record" as implemented in XDS and IBM operating systems. We view a file as anunbroken sequence of data.)A word is 16 bits, a byte is 8 bits. If these are to interpreted as signed integers, the representation istwo's complement.Several files use the concept of self-relative pointers. The idea is that the pointer specifies a fileposition relative to the file position of the pointer itself. The following example may help clarifythe notion of self-relative pointers. Suppose that the character encoding for character 101b starts atword 1650b of the file, and that a self-relative pointer to that encoding is at word 105b of the file.Then word 105b of the file will contain 1543b=1650b105b.2.3 NumbersNumbers in this document are decimal unless followed by a "b," in which case they are octal.12b=10.A FloatingPoint number is a two-word structure that contains a sign, an 8-bit exponent and a 23-bitmantissa. This representation is identical to the 32 most significant bits of the representation used bythe PDP-10 and MAXC. The Alto BCPL subroutine package FLOAT manipulates these numbers as well.(Further information about the actual encoding of numbers can be found in PDP-10 documentationor in FLOAT documentation.)3. File Naming ConventionsA standard naming convention is used for font files. In some cases, programs depend on adherenceto the convention (e.g., extracting width information from EARS fonts). The convention permitsprograms to "parse" the font name to discover various parameters. The convention is: gfqXHY _@ [t qtq6 Zf- t q X tqD W^e UDR!tq Q+!tq O!tq N#!tq J5uq Is$D GR FktqE DX Atqt q# @7` > ;t 8]q6uq' 6*uquq) 5U 2)tqtq,tq  0 -z!t q0 +tq8 *r%B ( \ 'i9 $>t !qG  cD *> [uquq uquq# 0uq Suq (s qW x;uq U  >[^JFont Representations and Formats5{family-name-in-full}{point-size}{[B|L]}{[I]}{[C|E]}.{extension}The optional B stands for "bold;" L for "light," I for "italic," C for "condensed," and E for"expanded." If a font file applies to all sizes of character (e.g., a spline file), the {point-size} isomitted. Examples:Helvetica12.Ep12-point Helvetica font for EARSHelvetica12b.Ep12-point bold Helvetica font for EARSThe {extension}s are chosen to identify the format of the file. Standard extensions are given below,together with the MAXC directory (inside brackets < >) where such files are traditionally found.Standard formats:.xx-SFSpline representations edited with FRED. .ACRaster representations, edited or created with PrePress. (These are usually Alto or Press printer fonts.)Subsidiary formats:Fonts.WidthsSummary of widths. .SDCompact spline representations (SDtemp format). .CU"Carnegie-Mellon University" format.Subsidiary formats (device-dependent):.ALAlto-format (CONVERT) font. and .STRIKEAlto-format font (BITBLT)..KSAlto-format font (BITBLT) with kerning. and .EPEARS-format portrait font (obsolete)..ELEARS-format landscape font (obsolete)..XHXGP-format font, for XPRINT (obsolete). Archived from .VTVTS-format font (obsolete). Archived from .FONTSDictionary of fonts in .AC format or one of its subsidiary formats, used byPress printing software4. PrePress File FormatSeveral of the file formats are variants of a generic file created and modified by PrePress. Theformat was designed to be easily extendable to include new sorts of information and to permit manydifferent fonts to be included in one file. PrePress documentation refers to this files with nameslike SD, SDtemp, CD, CDtemp, WD, WDtemp. An index at the head of the file describes each fontsegment that is contained within the file. The intention is that a reader will scan the index to find apointer to the font she desires. Thus a file is:structure PrePressFile:[index word howeverMany@IX//Index entry with type=0 (end of index)stuff word howeverManyAgain]Each index entry begins with a common form of header:structure IX: gfqXHY_#uququq [ uq uq uququq ZfT XU uT3q!u Qqtq3 Ouq82LXI-uq#uqu Gq7u F$q02B? qxu>Jquq u <q$29&6ouq uqu4ququq3guququ qu 1quuq!0_uuq".uuququ-Vquq'u+quqH*N '#s #q+6 "sS X ku%q4 tq<% c0 80u(`q(( x5 M uq =]GFont Representations and Formats6[type bit 4//Various type codes are assignedlength bit 12//Length of entry in words, counting this one]A particular kind of index entry establishes a correspondence between a code and a string:structure IXN:[@IX//Header with type =1code word//The numeric codenameLength byte//The number of characters in the namecharacters ^1,19 byte//Room for the name]Note that a name entry has a fixed length, although the name itself can be of any length up to 19.The final 20 bytes in the IXN structure are in the same format as a BCPL string. By convention, anIXN entry must establish a correspondence between a name and a code before any index entries thatuse the code appear.Each segment of the file will have an index entry that points to it (SplineSegment,CharacterSegment, or WidthSegment). They all have roughly the same form:structure STDIX:[@IX//Header with various typesfamily byte//Family name, using a name codeface byte//Encoding of the face propertiesbc byte//Code for the "beginning character"ec byte//Code for the "ending character"size word//Size of the font segmentrotation word//Rotation of the font segmentsegmentSA word 2//Starting address in file of the font segmentsegmentLength word 2//Length of the segment]The family name is identified by referring to a name-code correspondence established with an IXNentry. The face is encoded as:(if bold then 2 elseif light then 4 else 0)+(if italic then 1 else 0)+(if condensed then 6 elseif expanded then 12 else 0)+(if Xerox then 0 elseif ASCII then 18 else 36)This encoding generates face byte values in the range from 0 through 53. Codes 54 through 254inclusive are used to denote the logical size of a TEX font, the size that the font was designed forindependent of its physical magnification; for an explanation of this concept, see the memo[Maxc1]TexFonts.Press. A face byte value of F in the range [54,254] denotes a logical sizeof (254F)/2 points; thus, logical sizes range from 0 through 100 points in units of half-points.Face code 255 is reserved as an escape.The two entries bc and ec give the character codes for the first and last characters represented inthe segment. This allows partial fonts to occupy less space. Size gives the size of the fontdescription in micas. Rotation gives the rotation, in minutes of arc. segmentSA and segmentLengthspecify the location of the segment in the file (both entries are double-word integers, in units of filewords): these are included to permit random access to a large number of segments in one file. gfqXHY_] (`\ (`%Z W^4tq T3 uqRQ+u(`qO(` N#(`!L(` K G"@ Fkuq&uq DuqY Cc @7I"J1 >I ; uq:8u(`q6 (`5x(` 3(`2p(`0(`/h (` -(` $,_(`* 'Yu &,q#,!}5t. IZ  t q7 AS 8* 9R ' :) != 5, T yS  2>]fFont Representations and Formats7A common special case of a PrePress file is a font file that contains only one segment, andconsequently a very brief index (a name entry, and entry pointing to the segment, and an Endentry). The AC and SD files are examples.5. Standard Formats5.1. Outline representation  SF format.The standard format for outline representations is a specially-organized text file. The file isnormally read and written by FRED, the interactive editor for outlines, and by PrePress, the programfor converting the outline representations to other formats. We designed the SF format to be basedon a text file, and further to be readable by the INTERLISP programming system, in anticipation ofthe need to make transformations on outlines once they were defined (the transformations could bemade by hand with a text editor, or by writing a suitable LISP program). This approach has severaltimes saved us from some very messy effort to repair a damaged binary filethe text file has beena good idea.The definition of the file follows normal INTERLISP conventions for atoms, numbers, strings, andlists. (A number is either an integer of the form 123 or an octal number followed by Q, i.e.,12Q=10, or a floating-point number with an exponent heralded by E, e.g., 1.23E4.) In thedescription below, vertical bar (|) is used to separate alternatives, and<...>is a list,{...}is a string,[...]is a number.A single SF file may contain definitions for several characters, although the definitions areindependent. The file is a sequence of s, terminated by the atom STOP: ... STOPNormally, a full font will consist of about 7 SF files. These are conventionally given names like:family.LC1-SFLower case, first filefamily.LC2-SFLower case, continuation filefamily.UC1-SFUpper case, first filefamily.UC2-SFLower case, continuation filefamily.NUM-SFNumeralsfamily.S1-SFSpecial characters, first filefamily.S2-SFSpecial characters, continuation fileA is: ((FAMILY {family name}) (CHARACTER [code]) (FACE { B | M | R } { R | I } { C | R | E }) (WIDTH [width in x] [width in y]) (FIDUCIAL [dimension in x] [dimension in y]) (VERSION [number] {date}) (MADE-FROM {file name}[x character origin] [y character origin][x fiducial origin] [y fiducial origin]) (SPLINES ... ))Alternatively, a may specify that some other character is to be copied into gfqXHY _[ ]\ \ uquq Xs Utvt Rq4, Quq7 ONuq  M2uq  L{a J)uq% Is*7 G Duq- C@Ouq Auq$uq uq @7I=  ; :( 6uqR 5U@uq2)4u .q #uq3+u"q*Nu"q(u"q'Fu"q%u"q$>u"q"u"q% cuquq[uquququququququququqSuq%uqKuq *C*uq% c L=\MFont Representations and Formats8this one (not universally implemented): ((FAMILY {family name}) (CHARACTER [code]) (USE {family name} [code] { B | M | R } { R | I } { C | R | E }))Within the top-level list for , a construct of the form (COMMENT {anystring}) may be inserted at will.The FACE characters stand for:BOLD | MEDIUM | LIGHTREGULAR | ITALICCONDENSED | REGULAR | EXPANDEDIt is important to understand the normal use of coordinates in a SF file. The coordinates of knots,for the width, origins in the MADE-FROM description, and in the FIDUCIAL annotation, are all Altoscreen units: these are recorded directly by FRED. However, these coordinates must ultimately berelated to a more standard system common to all characters in the world. The FIDUCIAL serves thispurpose: it gives the distances, in x and y, that correspond to the point size of the character. Forexample, if we use FRED to design a (nominal) 12-point character, we set the fiducials to thedimension (in Alto screen units) that should be mapped into 12/72 inch on the final page image.A is: ( ... )A is: ([n] {solution method}) where [n] is the number of knots, is: (([X1] [Y1]) ([X2] [Y2]) ... ([Xn] [Yn])) is either NIL, in which case all knots are weighted equally, or: ([W1] [W2] ... [Wn]) and is: (([X1'] [Y1'] [X1''] [Y1''] [X1'''] [Y1''']) ...... ([Xn-1'] [Yn-1'] [Xn-1''] [Yn-1''] [Xn-1'''] [Yn-1'''])) and {solution method} is: { NATURAL | CYCLIC | PSEUDOCYCLIC }The numbers in this description are handled slightly differently: derivatives and weights are floatingpoint numbers, character code is octal (e.g. 101Q) or decimal, all other numbers (in particular knotcoordinates) are integers.5.2 Raster representations  AC format.The standard format for raster representations is the AC file, usually edited with the PrePress fonteditor. This format is used because it contains more information about characters than any otherfont format we have. Consequently, one can always convert to formats that demand lessinformation. By convention, AC files assume a scanning mode of 8.The file is a segment of a "PrePress font file" (see section 4 for a general discussion of PrePressfiles). The font file contains some identification information, and a directory that points to acharacter segment, which itself contains the information about the font. An index entry that pointsto a character segment is: gfqXHY _'[uqZfuqXuququququququququq UPuq T3! QuqMuququLXquJququ Gq/uq! F$uquq D uq0 C(&uq At1q @uq0 >,3 ;e89 5 2G02/hu./hqu./hqu./hqu./hqu./hqu./hq-uq3,u+,qu+,qu+,q*N(u(=(qu(=(qu(=(qu(=(qu(=(qu(=(q('u&s'qu&s'qu&s'qu&s'qu&s'qu&s'q%5#uququ q S 0uq. } Rtvt 'q5uq, R A  tvt# Cq tquq Y ;tqR  p=\Font Representations and Formats9structure CharacterIndexEntry:[@STDIX//Standard header with type=3.resolutionX word//Resolution in scan-lines/inch * 10resolutionY word//Resolution in bits/inch * 10]This index entry points to a CharacterSegment:structure CharacterSegment:[charData ^bc,ec @CharacterData//Useful data about each characterdirectory ^bc,ec @relFilePos//Relative file positions of rastersrasters ^bc,ec @rasterDefn//The actual raster encodings]structure CharacterData:[Wx @Fraction//X Width (scan-lines)Wy @Fraction//Y Width (bits)BBox word//Bounding box offsetsBBoy wordBBdx word//Width of bounding box (scan-lines)BBdy word//Height of bounding box (bits) or special code]The first two entries are signed fractions (a fraction is two words: the first is the integer part, thesecond the fractional part) that give the width vector (with reference to the origin of the character).The four parameters of the bounding box follow. However, BBdy=1 is reserved to indicate that acharacter of this code does not really exist in the font (such a code is necessary becauseCharacterData structures are recorded for all character codes in the range bc through ec).The directory portion is a table that points to the raster definitions of each character in the range bcthrough ec. Each pointer is 32 bits long (a double-word integer) that gives the position in the filein words, relative to the beginning of the directory table, of the rasterDefn for the appropriatecharacter. If a character of the given code is not in the font, both words of the relFilePos are 1.A rasterDefn is:structure rasterDefn:[BBdyW bit 6//Height of raster (in words)BBdx bit 10//Same as BBdx in CharacterDataraster word BBdyW*BBdx//The actual raster bits!]The value of BBdyW is simply k(BBdy+15)/16l, the number of words required to specify one scan-line. Each scan-line in the raster encoding begins on a word boundary.Important Note: Most Press printing software uses dictionaries of fonts in one of two subsidiaryformats derived from AC format. These important derived formats are described in sections 7.3 and7.4. gfqXHY _]\u(`qZ(` Y(` W TV. QPzN(`Mr(` K(`Jj GbEDZuq (`uqBuq (`uq ARuq(`  ?uq>Juq(`VgFont Representations and Formats106. Subsidiary Formats6.1 Fonts.Widths format.The file Fonts.Widths is used to disseminate width information to all formatting and editingprograms. Its basic format is that of a PrePress font file, with index entries that point toWidthSegments. An index entry is of the form:structure WidthIndexEntry:[@STDIX//Standard header, type=4]The interpretation of the size entry in this index is somewhat subtle. If it is non-zero, then it is thesize of the font, measured in micas. Thus, a 12-point font would have size=423. In this case, thewidth information is said to be absolute. On the other hand, if size is zero, then the widthinformation will be usable for fonts of any size (i.e., we shall scale it by the actual font size), andthe information is said to be fractional. If the data are absolute, then all dimensions are measuredin micas. If they are relative, dimensions cited in the WidthSegment must be scaled by2540P/72000, where P is the point size of the desired font, in order to convert the numbers to micas(You will note that this simply means that entries are measured in thousandths of the point size).The widths file may contain entries for both absolute and fractional information for the same font;in this case the absolute information takes precedence.The index entry points to a WidthSegment, which has the following format:structure WidthSegment:[FBBox word//X offset for font bounding boxFBBoy word//Y offset for font bounding boxFBBdx word//X width for font bounding boxFBBdy word//Y height for font bounding boxXWidthFixed bit//=1 if all X widths equalYWidthFixed bit//=1 if all Y widths equalspare bit 14widthData word howEverMany]The first four numbers are the dimensions of the font bounding box. At the end of the entry comes(widthData) the width information for individual characters. First comes the X width information.If the XWidthFixed flag is set, there is only one number given, which applies to all characters in thefont. If the XWidthFixed flag is zero, then there are ecbc+1 words that give the X widths of thecharacters with codes from bc to ec inclusive. Then follows the Y width information,correspondingly encoded. In order to identify "non-existent" characters in the range bc to ec, awidth (either absolute or fractional) of 100000b (the most negative number) signals a non-existentcharacter.Note: The widths file should really be able to deal with device-dependent widths as well: this is a tremendous help withphotocomposers, etc. Consequently, a WidthIndexEntry should really include a deviceCode, which identifies (bycorrespondence with some string in a IXN entry) the relevant device. If the device is PRESS, then the font would beassumed to be standard across a variety of devices; a width entry with an exact match of device name would takeprecedence over standard (PRESS) widths.6.2. Compact outline representations  SD format.Because the SF files that describe outline representations are somewhat bulky and tiresome to gfpXG _q [ro ( Xp D W9)'K,G Ur p! RQO~s(`pM JrpA IH6rp Grprp F>L Dr prp" C4N Asp spP @*N >-rpr p = rp 9r p! 65C3sp(`sp29sp(`sp0sp(`sp//sp(`sp-spsp(`sp ,%spsp(`1s1p * )' $jrp "Nsp !`spsp L  spsp>sp V*+,sp [ L:(  s&R <t s D\ P ( r'tr p spO O>\Font Representations and Formats11interpret, there is an alternative format: SD. This format is created from the SF files by the PrePressREADSF command (i.e., SD files are in the same format as is SDtemp). The file is in the general"PrePress font file" format, with an index entry:structure SplineIndexEntry:[@STDIX//Standard header, type=2]The size entry in the index must be zero. This index entry points to a SplineSegment:structure SplineSegment:[splineData ^bc,ec @SplineData//Useful information about each characterdirectory ^bc,ec @relFilePos//Directory pointing to spline encodingssplines ^bc,ec @splineCodes//The encodings of each character]The information about each character is:structure SplineData:[Wx @FloatingPoint//Width in X directionWy @FloatingPoint//Width in Y directionBBox @FloatingPoint//Left edge of bounding boxBBoy @FloatingPoint//Bottom edge of bounding boxRightX @FloatingPoint//Right edge of bounding box (=BBox+BBdx)TopY @FloatingPoint//Top edge of bounding box (=BBoy+BBdy)]All of these coordinates are relative to the origin of the character, and use the convention that 1.0 isequal to the point size of the final character. Consequently, most are usually fractional. A special(illegal) value of Wx is used to flag SplineData structures that correspond to non-existent charactersin the font (this problem arises because there are SplineData structures for all characters bc throughec, even though they may not all exist). The special value is 0 in the first word, and 1 in thesecond word.The interpretation of the directory is precisely the same as for AC files.The encoding of each character (splineCodes) is essentially a list of commands to a scan-conversionalgorithm, such as the one used in PICO. Five different kinds of entries may appear:structure SMoveTo:[codeMoveTo word//Command code =1X @FloatingPointY @FloatingPoint]structure SDrawTo:[codeDrawTo word//Command code =2X @FloatingPointY @FloatingPoint] gfpXG _"sp#sp C ]spsp$sp" \ gc( XW[Us(`pTQ Q%rpN MLtJ(`!Ij(` G(`F` C4( @>#sp. (`sSpsSpy oe (`sSp [sSp  =^XFont Representations and Formats12structure SDrawCurve:[codeDrawCurve word//Command code =3X' @FloatingPointY' @FloatingPointX''/2 @FloatingPointY''/2 @FloatingPointX'''/6 @FloatingPointY'''/6 @FloatingPoint]structure SNewObject:[codeNewObject word//Command code =1]structure SEndDefinition:[codeEndDefinition word//Command code =2]Each closed curve is specified with a sequence that begins with SMoveTo, and uses subsequentSDrawTo and SDrawCurve entries to trace the outline. An entirely new object is initiated withSNewObject (this is presently unnecesssary, and unimplemented). The entire character isterminated with SEndDefinition.The SDrawCurve entry gives the parameters for a parametric cubic spline:x = X0 + X' t + (X''/2) t2 + (X'''/6) t3y = Y0 + Y' t + (Y''/2) t2 + (Y'''/6) t3where t ranges from 0 to 1, and (X0, Y0) is the starting point of the curve.The SD files created by PrePress from SF files have an additional property: each SDrawCurve entrydefines a curve segment that is monotonic in both x and y directions. This simplifies scan-conversion for both portrait and landscape printing devices, provided the font characters are rotateda multiple of 90 degrees (or 0 degress, of course).6.3 CU format.The CU format was once our standard format for raster representations; some vestigial software infact still uses this format. It has the great virtue of simplicity, but is rather bulky and lacks somecrucial information.The file has the structure:structure CU:[H word//Height of font (number of scan lines)WW word//"Word width" of fontcharacter ^1,howeverMany//Character codings]Each character is a separate encoding with a character code, a width (in bits) for the character, anda raster. Every character in the file is placed within a raster of the same size: this raster size is thus gfpXG _]\ (`ZsSpYsSpW}sSpUsSpTssSpRsSpQi N_LKU(`I FEAC(`67{B7 ? > ='7 <K :| 7PH4rps3s4psprpspr4s4pspr4s1rpsX1?1pEsprpspr2Ys1p&s'pr2Ys .}prps-.}ps-.}p% +uspsp( )-rp (kI &3 #rtr psp[  b  X , sp"sp(`)sp(`(`  gH C( =]onFont Representations and Formats13analogous to the font bounding box, but is actually somewhat larger because the width of the box isa multiple of 16.structure CUChar:[ASCIICode word//ASCII character codeWidth word//Width of character in bitsraster word H*WW//The actual encoding of the raster]The raster is a sequence of scan-lines, each encoded in WW words. The first scan-line is at the"top" of the character. Within a scan-line, bits are given from left to right (more significant bits toless significant bits). Characters are, in general, "at the left" in the font bounding box; white spaceis provided on the right.This font format omits some useful information: the location of the origin within the bounding box.There is a convention used to remedy this lack: the lower leftmost 1 bit in the encoding of uppercase A (ASCII code 101b=65 decimal) is at the origin.7. Subsidiary formats  device dependent7.1 AL format.The AL format is designed to simplify the use of the Alto CONVERT instruction for creating displays(see the Alto Hardware Manual for a description of CONVERT).structure AL:[Height word//Height of font (scan-lines)proportional bit//True if proportionally spaced fontbaseline bit 7//(see below)maxWidth bit 8//Width of widest characterpointers ^0,nCharsX//Self-relative pointers to XW entriescharData word howEverMany]The Height entry must be > FBBdy. The baseline entry equals the height of the font bounding boxabove the origin (=FBBoy+FBBdy). If the AL font dates from a somewhat earlier vintage, the baselinemay be recorded as 0.The pointers table contains self-relative pointers to character encodings. Each character encoding inthe charData region can describe at most 16 (horizontal) bits of character data; if the characterrequires more data bits, an "extension character" is used to contain the rest of the data. Charactersmay have as many extensions as necessary.By convention, the first 377b entries in the pointers table are assumed to be self-relative pointers forthe corresponding ASCII characters codes. Following these entries are entries for any necessaryextension characters.The data for a character encoding is represented as:structure XHdata:[bitData word XH//Top scan-line firstXW word//(see below) gfpXG _rp@ ] Ze spXW[sp(`sp U (`)TQ s(`pR O)sp& N!G L<, K GU F` W Dspsp( Aq( >rtr ;Wpsp4sp 93sp 6 sp5!3 (`2(`0 (`/ (`-(` sp,*~ 'R upsp= %s psp . $H !T P T ) aJ sp7 W +4  spz s(`p psp(` )>\UFont Representations and Formats14HD byte//(see below)XH byte//Number of scan-lines of bit data]In order to conserve space, the bit data omits all-zero words at the top and bottom of the character.The HD entry records the number of scan-lines at the top of the character (relative to the fontbounding box) that are omitted. (Technically, HD = FBBdy+FBBoy(BBdy+BBoy).)The XW word is interpreted in one of two ways. If the width of the character is 16 or fewer bits,then XW is (2*width)+1. Otherwise, the character must require an extension character, and XWcontains 2*xCode, where xCode is the character code of the extension character. The finalextension character will have an XW that contains (2* width of final extension)+1, rather than thetotal width. The self-relative pointers in the pointers table point to the XW word.By convention, the first character encoding in the charData region is a "dummy" to which all non-existent character codes point. This dummy has XH=0, HD=0, and XW=1.7.2. PLAINSTRIKE and KERNEDSTRIKE format.The STRIKE formats were devised to permit graceful use of BITBLT for writing characters onto theAlto screen. Like .AL format, the STRIKE formats can only handle fonts with zero rotation, that is,with nonnegative X widths and zero Y widths.There are four kinds of files in the Strike class: a PlainStrike file (conventional extension .Strike), aKernedStrike file (conventional extension .KS), a PlainStrikeIndex file (conventional extension.StrikeX), and a KernedStrikeIndex file (conventional extension .KSX). In a PlainStrike file, theindividual rasters of the characters are assembled in ascending order of character code into one largeraster, called the strike. The baselines of the characters are aligned, and the origin of each characteris made coincident with the end of the width vector of the preceding character. The PlainStrike filealso contains a table indexed by character code that points to the leftmost column of the raster foreach character in the strike. Warning: since the rasters in a PlainStrike file are positioned by theirorigins and width vectors, it must be the case that all of the black bits of the character lie betweenthese two bounds. No character may include bits to the left of its origin (left-kerning) or to theright of the end of its width vector (right-kerning).A KernedStrike file handles kerned characters, and does so in the following way: the individualrasters are put into the strike by their bounding box widths. Just think about taking the boundingboxes of all of the characters, lining up their baselines, and packing them tightly into one longraster array; in this format, there are no blank columns between characters in the strike. AKernedStrike file has three additional tables, indexed by character code. One gives the position inthe strike of the first column of the character's raster, which is also the leftmost column of itsbounding box. The other two tables consist of small integers that specify the left-to-right locationof the origin with respect to the bounding box, and the length of the width vector. A StrikeIndex is essentially a table that maps character codes into pairs, together withthe associated strikes. An index can be used to achieve sharing if several character codes map tothe same pair, and hence refer to the same raster. Or it can help to save space, bygrouping the rasters into several strikes to save top and bottom scanlines. [By the way, to the bestof my knowledge, no one has ever used a StrikeIndex format.]PlainStrike and KernedStrike files have the following format: gfpXG_sp(`]sp(`\ X@% W[spG U/spsp RspH Q%sp8s OpP N!sp- LLsp IjG G0spspsp Drt rt r Apsp/sp @sp sp2 >spsp ;455 9B 7J 6<(> 4 rpP 2:+ 1D;) /rpK -.8 ,LY *5 'U2. %(; $F "]1- I  K e#B T nL [ L v14 < =4 8>YiFont Representations and Formats15structure PlainStrike: [ @StrikeHeader// header common to all Strike files @StrikeBody// the actual strike ]structure KernedStrike: [ @StrikeHeader// header common to all Strike files @BoundingBoxBlock// dimensions of the font bounding box @StrikeBody// the actual strike @WidthBody// table of width data ]structure StrikeHeader: [ format word = [ oneBit bit// always =1, meaning new style'' index bit// =1 means StrikeIndex, =0 otherwise fixed bit// =1 if all characters have same value of Wx, else =0 kerned bit// =1 if KernedStrike, =0 if PlainStrike blank bit 12 ] min word// mimimum character code max word// maximum character code maxwidth word// maximum spacing width of any character = max{Wx} ]structure BoundingBoxBlock: [ FBBox// as defined above FBBoy// as defined above FBBdx// as defined above FBBdy// as defined above ]structure StrikeBody: [ length word// total number of words in the StrikeBody ascent word// number of scan-lines above the baseline, which is// normally max{BBdy+BBoy} over the chars in this strike descent word// number of scan-lines below the baseline, which is// normally max{(BBoy)} over the chars in this strike xoffset word// always =0 [used to be used for padding schemes] raster word// number of words per scan-line in the strike bitmap word raster*height// the bit map, where height=ascent+descent=FBBdy xinsegment ^ min, max+2 word// pointers into the strike, indexed by code ]structure WidthBody: [ gfpXG _ ]n [?$ Z ? Xv U& S~ Q?$ P.?& N ? L ? K6 G F> D B AF ?# ??& =?6 $,  F  W<]Font Representations and Formats16 widthtable ^ min, max+1 @WidthEntry// spacing information, indexed by code ]structure WidthEntry: [ spacing word =// the entire spacing word will be =(1) (both bytes =377b)// to flag a non-existent character, else the bytes are:[offset byte// =BBoxFBBoxwidth byte// =Wx] ]The bitmap'' entry is one large bit map; there are height=ascent+descent scanlines in thebitmap, each of which is raster words long. Unless something funny is going on, ascent will besimply FBBdy+FBBoy, while descent will be simply (FBBoy).The font includes characters for some of the ASCII codes from min through max inclusive. Thebitmap includes a dummy character associated with the charcter code (max+1), which can bedisplayed for any non-existent character. A PlainStrike works as follows: Given a character code c, in the range [min, max], we firstcompute:xLeft _ xinsegment ^ c;xRight _ xinsegment ^ (c+1);.If xLeft=xRight, then c is a non-existent character in the current font, and should be replaced bythe raster with code (max+1). Otherwise, the columns of the bitmap from xLeft through(xRight1) inclusive contain the raster for character c, and the width of charcter c isWx=(xRightxLeft).A KernedStrike works a little differently. We first compute xLeft and xRight as above, and alsocomputeSpacing _ WidthTable ^ c;.If Spacing=(1), then c is a non-existent character in the current font, and should be replaced bythe dummy character at (max+1). Otherwise, the columns of the bitmap from xLeft through(xRight1) constitute the bounding box of the raster of character c. In this case, we decomposethe Spacing value into its two bytes:Offset _ Spacing< pairs, dummy at max+1 bodies ^ 1, nStrikeBodies @StrikeBody// the strike bodies themselves ]structure KernedStrikeIndex: [ @StrikeHeader// common header @BoundingBoxBlock// bounding box data for the entire font maxascent word// maximum ascent of all the strikes// [probably =FBBdy+FBBoy] maxdescent word// maximum descent of all the strikes// [probably =(FBBoy)] nStrikeBodies word// the number of strike bodies map ^ min,max+1 @mapEntry// table of pairs, dummy at max+1 bodies ^ 1, nStrikeBodies @StrikeBody// the strike bodies themselves @WidthBody// table of width data ]structure mapEntry: [ missing bit 1// =1 if character is non-existent, else =0 strike bit 7// which strike, a number in the range [0:127] code byte// which character code in that strike ]In a StrikeIndex font, all of the StrikeBodies have implicit min values of zero; the max value isunimportant, as the map will never generate a reference outside the range. The individualStrikeBodies do not have separate pictures for illegal characters; instead, the (max+1) entry in theglobal map defines a single dummy picture. Non-existent characters in the range [min, max] areindicated in the global map by a mapEntry that specifies a strike number larger than 127=177b,that is, by the sign bit of the map entry being 1. In KernedStrikeIndex fonts, non-existentcharacters will also be indicated by having a WidthEntry of (1). gfpXG _9+ ]n"B [7) Z P Xv P VI SY Q NX L K8$ I$$,G F@$%,D B$ AH$0 ?($ = : 9 7X$ 5$( 4$$,2` 0$%,/ -h$ +$0 *($ (p $ & #x ! (?, ?/  ?& 0 R 9C R +4 AC D A =Z`Font Representations and Formats18In StrikeIndex fonts, the ascent and descent words in each StrikeBody give the dimensions of thatparticular StrikeBody; thus, they probably are the y dimensions of the bounding box of thosecharacters that are included in that StrikeBody, rather than of the entire font. Note on BitBlt modes:There are evidently lots of programs in the world that paint charcters on the screen by calling BitBltin Replace mode, in which the new bits simply smash whatever used to be at the destination. Ifyou want to handle characters that kern, you simply can't do this! The bounding boxes ofsuccessive characers may actually overlap, and hence a Replace Blt might overwrite valuable bits. Ifyou want kerning specified in a KernedStrike font to work, you must use one of the other BitBltmodes: Paint, Erase, or Invert. 7.3 Compact ("Orbitized") format for raster representationsBoth the PRESS and the SPRUCE printing systems use dictionaries whose font formats have beencompacted by eliminating the requirement that scan lines begin on word boundaries. The storagefor a character can be thought of as a stream of bits, with the first bit of each scan line followingthe last bit of the preceding one, irrespective of word boundaries. The encoding is identical to theAC format encoding of section 5.2, except for the type and the raster definition. For convenience,we repeat the entire specification here. An index entry that points to a compacted, or "Orbitized",character segment is:structure CompactedCharacterIndexEntry: // identical to type 3 except for type[@STDIX//Standard header with type=5.resolutionX word//Resolution in scan-lines/inch * 10resolutionY word//Resolution in bits/inch * 10]This index entry points to a CompactedCharacterSegment:structure CompactedCharacterSegment: // identical to type 3 format except raster encodings[charData ^bc,ec @CharacterData//Useful data about each characterdirectory ^bc,ec @relFilePos//Relative file positions of rastersrasters ^bc,ec @compactedRasterDefn//The actual raster encodings (These vary in length,// thus could not actually be indexed)]structure CharacterData: // identical to standard type 3 AC format[Wx @Fraction//X Width (scan-lines)Wy @Fraction//Y Width (bits)BBox word//Bounding box offsetsBBoy wordBBdx word//Width of bounding box (scan-lines)BBdy word//Height of bounding box (bits)]A compactedRasterDefn is:structure compactedRasterDefn:[negHeight//Negative of the character height, in bits gfpXG _H ]nP [S Xwr U(pF SE Q9 P0.7 N1. L! Ir; Fpspsp? EA C~O A] @tsp8) >c =j :>N874s(`p5(` 4*(` 2 /y7 ,M4&*)C(`'(` &9#(` !(`$'#/ %Bsp (`spsp (`sp sp(`  spsp(`sp(`    (`+ T=]FFont Representations and Formats19widthMinus1//Width of the character, less 1, in bitsraster word n//The actual raster bits!]The value of n, the number of words occupied by raster bits, is the floor of (height*width+15)/16.7.4 Compacted rasters with multiple width specificationsIn order for the producer and the printer of a PRESS format file to agree on the appearance of eachpage, they must agree on the widths of the characters to be printed. This agreement is achieved byproviding the producer programs with WIDTHS format files corresponding to the raster files used bythe printers.On infrequent occasion, the widths specified for existing characters in existing fonts must bechanged. Once the new WIDTHS and raster files have been promulgated, all newly-created PRESSformat files will again print correctly, but older files will no longer be rendered accurately.To improve this situation, it is possible to create a font dictionary whose entries include for eachfont a single set of raster definitions, along with a collection of width specifications, eachaccompanied by an expiration date. The printer spaces characters based on the widths that were ineffect at the time indicated by the PRESS file's creation date (stored in its document directory). Ifthe new rasters are predominantly narrower, or at least not too much wider, than the characters theyreplace, the result of printing an old PRESS file is usually satisfactory.The PrePress system contains a special command for introducing a new set of rasters for a font,retaining both all of the old widths along with the new ones. The administrators at a site maychoose to support this capability, or to ignore it.This format requires modification of the STDIX structure. Its rasters are in the compactedrepresentation described in the preceding section. A font file for a printer may contain anycombination of type 5 (compacted) and type 6 (compacted, multiple widths) font formats. Theindex entry for a font with multiple widths is:structure MultipleCharacterIndexEntry:[@IX//Header, type=6.family byte//Family name, using a name codeface byte//Encoding of the face propertiesbc byte//Code for the "beginning character"ec byte//Code for the "ending character"size word//Size of the font segmentrotation word//Rotation of the font segmentresolutionS word//Resolution in scan-lines/inch * 10resolutionB word//Resolution in bits/inch * 10numSegs word//Number of width segmentssegs^1,numSegs://Arranged in order from newest to oldest [// Only the newest entry includes rasters segmentSA word 2//Starting address in file of the font segment segmentLength word 2//Length of the segment expirationDate word 2//Date after which these widths are no longer valid,// in Alto file date format ]]The segment corresponding to segs^1 is a CompactedCharacterSegment, as described in the gfpXG_ (`)] r(`p\ X rpR Ur8 Rpsp/ Qc O~%sp" M JG IH sp;s GpS D_ C3+ A T @ sp= >13 <'sp 9rp"1 8ML 63 3(sp- 2Q 0G / / +X&*\(s(`p'R (`%(`!$H(`$"(`!!>(` (`4(`$(` (` (`)(`)(`.(` (`4(` } Q(/ ( =^JFont Representations and Formats20preceding section. Its widths represent the current values; its expiration date is set well into thefuture. Segments corresponding to segs^2 through segs^numSegs represent increasingly older widthvalues; they have the form:structure OldWidthSegment:[charData^bc,ec @CharacterData//Useful data about each character]The raster-specific information in this specification is identical for all segments; the width entriesthat define the spacing characteristics will differ.7.5 EL and EP format for EARS fonts (obsolete)Font formats for the EARS system are compressed (all other raster representation formats mentionedin this document use no compression). The extension .EP is used, by convention, to denote"portrait" fonts (font strings will run horizontally on the page if it is oriented as a portrait). The ELextension is used for "landscape" fonts.Both sorts of font have the same format (remember that EARS scans in mode 8):structure ELEP:[@Record0//General information@Record1//Character informationRecord2 word howEverMany//Actual character encodings@Record3//Font specification table]structure Record0:[MRLILength word//Length of Record2 (in words)maxWidth word//Maximum character width (scan-lines)// max (over all Record1Entry's) of WidthmaxHeight word//Maximum character height (bits) FBBdyTTYTab word//How many bits or scan-lines for a tabdefaultFSN word//Default font set number (PSPOOL)reserved word 3//Used by PSPOOLblank word 56]structure Record1:[characterData ^0,127 @Record1Entry//Descriptions of each character]structure Record1Entry:[FontAddress word//Address (in words) into Record2 of encoding// (relative to beginning of Record2)FontLength word//Number of words of encoding in Record2Width word//"Width" of character (amount to "space" over)W word//Width of bounding box BBdxH word//Height of bounding box BBdybaseline word// BBoy (portrait) or BBox (landscape)codingType word//(see below) gfpXG _S ])8 \  XXW[U(`"TQ Q%G O4 Ltrtrtr tr IHp spI G6sp" F>@(s Dp( A7sp >a sp<;W(`9,(`)8M(`6(`5C 290//sp (`- (`(`,%)* (`s)sp(`"'(`sp&(`s$p # x"(` n dZ(`$(`%P(` (`#Fsp(`s sp(`s 0 if the encoding is a matrix (in this case, the valueof codingType is the height of the matrix in bytes). Record2 contains the encodings of the rasters for the individual characters (as pointed to byRecord1 and Record3 entries). If the encoding is a matrix, the entry in Record2 in anuncompressed raster for the character (scanning mode=8), with (1) the height rounded up to thenext multiple of 8 bits, and (2) a possible 1-byte padding at the end of the matrix encoding to makethe entry an integral number of 16-bit words long. For example, the K of Figure 4 would have amatrix encoding of:100004b(first scan-line, rounded up to 16 bits high)177777b(second scan-line, ...)177777b103004b001400b003600b006300b014140b130064b160034b140014b100004b(last scan-line)Most characters will be encoded in Record2 with a more economical scheme: RLI. This is acompression scheme that reduces font storage for high-resolution characters (compression of 3.5:1 istypical for a 12-point font at 500 bits/inch). We shall describe RLI by referring to Figure 4. Eachscan-line could be coded as a series of number pairs, where the first number of each pair representsa number of "white" bits to be followed by the number of "black" bits specified by the secondnumber of the pair. With this scheme, the first scan-line of the K would be represented by the twopairs (0,1) and (12,1). We can omit the parentheses and write simply 0,1,12,1. The entire K isencoded into runs as follows:Scan-lineRunsRLI00,1,12,1(R)0,1,12,110,14(R)0,1420,14(I)0,030,1,4,2,6,1(R)0,1,4,2,6,146,2(R)6,255,4(I)1,264,2,2,2(R)4,2,2,273,2,4,2(I)1,0,2,080,1,1,2,6,2,1,1(R)0,1,1,2,6,2,1,190,3,8,3(R)0,3,8,3100,2,10,2(I)0,1,2,1110,1,12,1(I)0,1,2,1The second column gives simply the runs. The third column gives the run-length-increment format:a given scan-line is represented as increments on the runs for the previous scan-line, provided thereare the same number of runs as in the previous scan-line. Thus scan-line 10 is represented by theincrements 0,1,2,1, which are added to the runs for scan-line 9 (0,3,8,3) to yield runs 0,2,10,2for scan-line 10. For high resolution characters (our example is not high resolution), the gfpXG_ (`sp] Ze)? X sp8 W[6 T/Z R!5 Q%%9 O22 NR LI(`-H(`FDCxA@n>=d;:Z8(` 5Jsp  4FR 2 7sp 1<L /@ .2O ,Q +(@'6s@$p26@#m26@!26@ c 26 @26@Y26@26@O26@26@E26@26@;26 :rp ^ 9) ,6 A =]VvFont Representations and Formats22incremental mode (I) dominates.The RLI information is encoded as follows. The character encoding starts in Record2 at the locationspecified by Record1 and Record3 entries; RLI information is recorded for each scan-line (startingwith the left-most scan-line, scan-line 0 in our example). Runs appear in 8-bit bytes, where the firstbit of a byte is a flag which is set to mark the last run for a scan-line. Thus, scan-line 9 isrepresented by the 4 8-bit bytes 0, 3, 10b and 203b; these are packed into words as 3b and 4203b.Because of this encoding, runs are limited to the range 0-127; if a longer run is needed, two runsmay be spliced with a zero-length connector (e.g., 100,0,100,10 is equivalent to 200,10). A limit of 8runs is imposed for each scan-line (characters requiring more than 8 runs can be represented inmatrix format).The increments for RLI are specified in 4-bit groups in which the first bit is used as a flag and theremaining 3 bits are 2's complement increments (range 4 to 3). As with runs, the flag bit for thelast increment of the scan-line is set. In addition, the flag bit of the first increment on the scan-lineis set (this allows runs to be differentiated from increments, because there are always at least 2 runsper scan-line). For example, the increments to scan-line 10 are encoded as the 4-bit quantities 10b,7b, 2b, 17b; these are packed into 8-bit bytes as 207b, 57b; or into a 16-bit word as 103457b. Notethat if increments do not fall in the range 4 to 3, you can always use a run representation ratherthan an increment representation.This encoding will produce an integral number of 8-bit bytes for each character. Consequently, acharacter may be followed by a 1-byte padding in order to stard the subsequent character at a word(16-bit) boundary.Record3 is a very compact description of each character, and is actually examined by the RCGhardware:structure Record3:[fontSpecTable ^0,127 @CharSummary]structure CharSummary:[baseline bit 13//Two's complement baseline (0 for landscape)matrix bit//True if encoding is a matrix (not RLI)endOfPage bitnotEndOfLine bitWidth word//Amount to space over to next characterW bit 10//Bounding box width 1Hb bit 7//k(Height+7)/8l 1fontAddress bit 15//Relative address in Record 2 of encoding]7.6 XH format XGP fonts for XPRINT (excruciatingly obsolete)The XH format was devised to simplify the inner loop of XPRINT, a program for printing text on theXGP. The XGP scans in mode 3. The file has the format:structure XH:[nChars word//The number of characters in the fontnData word//Number of words of font dataH word//Height of the font (in scan-lines)W word//Maximum width (in words) of any character gfpXG _ [spB Ze*sp4 X)> W[N U.3 TQ X R\ QG=" O LspK KN I91 H>) FV D] Cx.rp Arp >_ =BR ; 88!s 7 p 32[0!/Q ,G*)=(` 6' (`sp&3 $#) (`!sp(`   (`up up(`  rtrtr t psp2sp 8spsp+  sp (`! } (` sp(` ssp(`" ,>]qFont Representations and Formats23pointers ^0,nChars1 word//Self-relative pointers to charData (see below)widths ^0,nChars1 word//Width to space to next characterdata word nData//Character encodings (see below)]nChars is usually 128 or 256. The height H must be > FBBdy. A width of zero identifies a non-existent character; any width up to 12 W is legal.The character encodings are represented as follows:structure charData:[ ^1,k(width+11)/12l @block//Each block defines up to 12 bits]structure block:[ ^1,H [ bitData bit 12//Up to 12 bits of character data validBits bit 4 ]//Number of bits in bitData that are valid]Thus a character is defined by successive blocks of H words; each block defines up to 12 horizontalbit positions of the character. The first word in the block defines the top scan-line, the next wordthe next scan-line, etc. Words of the block define up to 12 bits of character data: the validBits fieldcontains the number of valid bits in the word (1 is minimum; 12 is maximum). All blocks exceptthe last have validBits=12. gfpXG_(` 9?% ](`\ (` Z W[rp spusp" U'sp R3 ONLup up(`K HFDsp(`Cx(`"A >!sp. =B6/ ;T :8B 8 5@=2Font Representations and Formats24Character Codes of First Generation Fonts (somewhat obsolete) (For the up-to-date story about character code assignments, see the memo[Maxc1]SpecialCharacters.Press)underline30bA101ba141bspace40bB101bb142b!41bC103bc143b"42bD104bd144b#43bE105be145b$44bF106bf146b%45bG107bg147b&46bH110bh150b'47bI111bi151b(50bJ112bj152b)51bK113bk153b*52bL114bl154b+53bM115bm155b,54bN116bn156b-55bO117bo157b.56bP120bp160b/57bQ121bq161b060bR122br162b161bS123bs163b262bT124bt164b363bU125bu165b464bV126bv166b565bW127bw167b666bX130bx170b767bY131by171b870bZ132bz172b971b[133b{173b:72b\134b|174b;73b]135b}175b<74b^136b~176b=75b_137b>76b' (left quote)140b?77b@100b gfpXG~_q>[pHJZe& W9#$-:D} U#$-:D} T/#$-:D} R#$-:D} Q%#$-:D} O#$-:D} N#$-:D} L#$-:D} K#$-:D} I#$-:D} H#$-:D} F#$-:D}E- D#$-:D} Cx#$-:D} A#$-:D} @n#$-:D} >#$--:D} =d#$-:D} ;#$-:D} :Z#$-:D} 8#$-:D} 7P#$-:D} 5#$-:D} 4F#$-:D} 2#$-:D} 1<#$-:D} /#$-:D} .2#$-:D} ,#$-:D} +(#$-:D} )#$- (#$ - & % $;C=4:{{{{{{{{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx{{{{{{{{9qqq998pp88pp8`y  B!B{B!B{B!B{B!B{ B!B{B!B{B!B{B!B{ B!B B!B B!B B!B B!B B!B B!B B!B B!Bx B!Bx B!Bx B!Bx B!Ax B!Ax B!Ax B!Ax B!A B!A B!A B!A B!A B!A B!A B!A B!A B!A B!A B!A B= B= B= B= B = B = B = B = B= B = B = B =  B B B B B! B! B! B! B  B  B  B  B  B  B  B  B  B  B  B  B B B B BB BB BB BB BB BB BB BB BB BB BB BB ~}{B }{B }{B }{B @}{B }{B }{B }{B @?Ax!B Ax!B Ax!B Ax!B Figure 1. Outline representationOriginOrigin of next characterWidth = Figure 2. Raster representationBBdxBBoxBBdyBBoyFigure 3. Bounding box conventions.In the example, BBdx=13, BBdy=24,BBox=4, and BBoy=13Figure 4. RLI coding example./(^P &@||4:^P @||  p d M|{p%d,K|{p:d2I|{p *dJ G|{ptdV,@M|{p!du'|{pZdy@%|{p:d}@|{prd 6|{p#id# |{@p!d!`|{p d|{psd. |{MATH  TIMESROMAN LOGOL TIMESROMAN  TIMESROMAN  TIMESROMAN TIMESROMAN TIMESROMAN TIMESROMAN  TIMESROMAN  TIMESROMAN  TIMESROMAN TIMESROMANMATH  TIMESROMANLOGOL TIMESROMAN  TIMESROMAN  TIMESROMAN  TIMESROMAN TIMESROMANSIGMA TIMESROMAN HELVETICA  HELVETICA  HELVETICA  Y #*29L@GmOU[b lqyP&4~ Wp p<`@| e ?Rn = ?< : ' %  j/j foo.pressRamshaw 1-Oct-80 15:37:05 PDT