adobe type 1 font format

8/3/2019 Adobe Type 1 Font Format

http://slidepdf.com/reader/full/adobe-type-1-font-format 1/111

Adobe Type 1Font FormatAdobe Systems IncorporatedAdobe Systems Incorporated

Addison-Wesley Publishing Com pany, Inc.

Readin g, Massachu setts • Men lo Park, California • New York

Don Mills, Ontario • Wokin gham , En gland • Amsterdam

Bonn • Sydney • Singapore • Tokyo • Madrid • San Juan



Library of Con gress Catalogin g-in-Publicatio n D ata

Adobe typ e 1 font form at / Adobe System s In corporated.

p. cmIncludes in dex

ISBN 0-201-570 44-0

1. PostScript (Com puter program language) 2. Adobe

Type 1 fon t (Com pu ter program ) I. Adob e Systems.

QA76.73.P67A36 19 90

686.2’2544536—dc20 90-42516

Copyright © 1990 Adobe Systems Incorporated.

All rights reserved. No part of this publication may be reproduced, stored in a

retrieval system, or transmitted, in any form or by any means, electronic,

mechanical, photocopying, recording, or otherwise, without the prior written

perm ission of Adob e Systems Incorp orated an d Add ison-Wesley, In c.

Printed in the United States of America.

Published simultan eously in Can ada.

The information in th is book is furn ished for inform ational use on ly, is subject to

change without n otice, and shou ld not be construed as a comm itment by Adobe

Systems Incorporated. Adobe Systems Incorporated assumes no responsibility or

liability for any errors or in accuracies th at m ay app ear in th is boo k. Th e software

described in th is book is furn ish ed un der license and m ay on ly be used or copied

in accordance with th e terms of such license.

Please remember that existing font software programs that you may desire to

access as a result of information described in th is book may be protected un dercopyrigh t law. Th e un auth orized use or m odification of any existing fon t software

program cou ld be a violation of th e righ ts of the au th or. Please be sure you ob tain

any p ermission required from such au th ors.

PostScript, th e PostScript logo, Display PostScript, Adob e, and th e Adob e logo are

trademarks of Adobe Systems Incorporated registered in the U.S. Adobe Type

Man ager is a tradem ark of Adob e Systems In corporat ed. IBM is a registered trade-

mark of International Business Machines Corporation. Macintosh and

LaserWriter are registered trademarks of Apple Computer, Inc. Helvetica and

Op tim a are tradem arks of Lino type AG an d/ or its subsidiaries. ITC Ston e is a reg-

istered trademark of Intern ational Typeface Corporation. Oth er brand or produ ct

names are the trademarks or registered trademarks of their respective holders.

3456789-MU-96959493

Third prin tin g, February 1993 , Version 1.1



i

Chapter 1: Introduction .................. ..................... ...................... .... 1

1.1 Wh at Is a Type 1 Fon t Program ?.................................................... 2

1.2 Wh at This Docu m en t Does............................................................ 3

1.3 Version s and Com pat ibility ........................................................... 4

1.4 Cop yright s for Type 1 Fon t Program s............................................ 5

Chapter 2: Font Program Organization .......................................... 7

2.1 Buildin g Ch aracters ........................................................................ 7

2.2 Fon t Diction ary .............................................................................. 9

2.3 Exp lanation of a Typical Fon t Program ....................................... 10

2.4 Inside th e En crypted Portion ....................................................... 14

2.5 Un ique Ident ification Num bers an d Fon t Nam es .......................17

Chapter 3: Character Outline Considerations ............................... 21

3.1 Ch aracter Geograph y ................................................................... 21

3.2 Align m en ts and Overshoo ts ........................................................ 23

3.3 Ch aracter Coord inate Space ........................................................ 25

3.4 Ch aracter Path s ............................................................................ 26

3.5 Direction of Path s ........................................................................ 27

3.6 Over lapp in g Path s........................................................................ 28

Chapter 4: Technical Design Considerations ................................. 29

4.1 Poin ts at Ext rem es........................................................................ 29

4.2 Tangen t C on tin uity ..................................................................... 30

4.3 Con cisen ess.................................................................................. 31

4.4 Con sisten cy .................................................................................. 32

Contents



ii Adobe Type 1 Font Format

Chapter 5: Private Dictionary ....................................................... 35

5.1 Declarative Hin ts.......................................................................... 35

5.2 Fon t Level Hin ts ........................................................................... 36

5.3 BlueValues .................................................................................... 36

5.4 Ot h erBlues.................................................................................... 38

5.5 Fam ilyBlues and Fam ilyOt h erBlues ............................................. 38

5.6 BlueScale....................................................................................... 395.7 BlueShift ....................................................................................... 40

5.8 BlueFuzz ....................................................................................... 41

5.9 Stem Wid th Inform ation ............................................................. 42

5.10 ForceBold...................................................................................... 43

5.11 Lan guageGroup ............................................................................ 44

5.12 len IV............................................................................................. 45

5.13 Com pa tibility En tries ................................................................... 45

5.14 Exp an sion Facto r........................................................................... 45

Chapter 6: CharStrings Dictionary ................................................ 47

6.1 Ch arstring Encodin g .................................................................... 476.2 Ch arstring Num ber En codin g...................................................... 48

6.3 Ch arstring Com m an d En codin g.................................................. 48

6.4 Ch arstring Com m an d List ........................................................... 49

6.5 Ch aracter Level Hin ts................................................................... 56

6.6 En cod in g Exam ple ....................................................................... 58

Chapter 7: Encryption .................................................................. 61

7.1 En cryption Meth od ...................................................................... 61

7.2 eexec En cryption .......................................................................... 63

7.3 Ch arstrin g En cryption ................................................................. 64

Chapter 8: Using Subroutines ....................................................... 67

8.1 Ch an ging Hin ts With in a Ch aracter ........................................... 69

8.2 Dot Section s ................................................................................. 71

8.3 Flex ............................................................................................... 72

8.4 First Fou r Subrs En tries................................................................. 78

Chapter 9: Special Font Organizations ......................................... 79

9.1 Syn th etic Fon ts ............................................................................ 79

9.2 Hybrid Fon ts ................................................................................ 80

Chapter 10: Adobe Type Manager Compatibility .......................... 83

10 .1 Sim ple Values ............................................................................... 84

10 .2 Arrays ........................................................................................... 84

10 .3 Keywords ...................................................................................... 85



Contents iii

Appendix 1: Private Dictionary Entries ......................................... 87

Appendix 2: Charstring Command Values .................................... 89

Appendix 3: OtherSubrs Programs ............................................... 91

Appendix 4: Changes ................................................................... 97

Index .................. ..................... ..................... ..................... ........... 99



iv Adobe Type 1 Font Format



1

CHAPTER1

This document describes the organization of the Adobe Type 1

font format and how to create a Type 1 font program. A Type 1

font program is actually a special case of a PostScript ® language

program . The PostScript interpreter ren ders th e fon t in telligent ly,

in a d evice-ind epen den t m an n er. Th is allows a fon t developer to

create on e fon t program th at can be rend ered on a wide variety

of devices an d at m an y different resolution s.

• A Type 1 font program con sists of a clear text (ASCII) portion ,

and an en coded an d encrypted port ion .

• Th e PostScript language comm and s used in a Type 1 fon t pro-

gram must conform to a much stricter syntax than do

“n orm al” PostScript language p rograms.

• Type 1 fon t programs can in clude special “hints” that m ake

their representation as exact as possible on a wide variety of

devices and pixel densities.

Th is docum ent explain s the required conten ts of the clear and

encrypted portions of a Type 1 font program, reveals the font

encryption and decryption algorith m s, provides syntax informa-

tion, and explains how to declare hints when creating Type 1

font p rograms.

• Chap ter 1 discusses som e backgroun d issues about Type 1 fon t

program s and th eir differences from Type 3 fon t pro grams.

• Chap ter 2 explain s th e differen t parts of the PostScript lan-guage program th at m akes up a font p rogram .

• Chap ter 3 describes gen eral terminology and h ow the differen t

features that m ake up th e characters in a fon t program are con-

structed.

Introduction



2 Adobe Type 1 Font Format

• Chapter 4 provides several tips on m anagin g the tech n ical part

of design aesthetics.

• Chapter 5 expla ins the contents of the Private dictionary.

• Chapter 6 expla ins the contents of the CharStrings dictionary,

explain s ch arstrin g nu m ber an d com m and encoding, and lists

th e comm and s used in Type 1 charstrin gs and th eir encodings.

• Chapter 7 discloses the m ethod of en crypt in g and decrypt ing

Type 1 fon t program s.

• Chapter 8 sh ows h ow subrout ines can be used for fon t pro-

gram space requirement reduction and h int substitution .

• Chap ter 9 describes th e special organ ization of synth etic an d

h ybrid fon t program s.

• Chapter 10 provides n ecessary in formation to ensure compat-ibility with Ado be Type Man ager™ (ATM™) software.

• Th e appen dices contain lists of dictionary en tries, comm and s,

an d PostScript lan guage code th at you m ay wish to in clud e in

your own fon t program s.

1.1 What Is a Type 1 Font Program?

Th e PostScript language h as ch an ged th e way com pu ters display

and print docum ents. Th is lan guage un ifies text an d graph ics by

treating letter shapes as general graphic objects. Since letters are

used so frequen tly in prin ted im ages, th e PostScript language h as

special operators to handle collections of letter shapes conve-

niently. These collections are called fonts; each font usually

consists of letters and symbols whose shapes share certain stylis-

tic properties.

Th e com plete specification for th e PostScript language, includin g

information o n h ow font program s are organized, appears in th e

PostScript Language Reference Manual, published by Addison-

Wesley. In addition to the font format that is described in the

PostScript Language Reference Man ual (com m on ly known as “Type

3 font format” or “user-defined font format”), the PostScript

interpreter also accepts a font format, called the Type 1 font

format , that is not part of th e PostScript lan guage defin ition an d

is n ot fully described in th e PostScript Language Reference Manual.



Chapter 1: Introduction 3

Type 1 fon t p rograms h ave several advan tages over Type 3 fon t

programs.

• Type 1 fon t program s are m ore compact.

• Th e PostScript in terpreter uses special rasterization algorithm s

for Type 1 font p rograms th at result in better looking ou tpu t—

especially at sm all sizes an d low resolut ion s.

• Type 1 font programs conta in hints that indicate special fea-

tures of character shapes not directly expressible by the basic

PostScript language operators.

The special rasterization algorithm and the hints for the Type 1

font format that the rasterization algorithm uses are directed at

features common to collections of letter shapes. The special ras-

terization algorithm and the hints aim to preserve baselines,

letter heights, stem weights, and other such features. Thus, the

Type 1 format is excellent for characters intended to be read astext. Company logotypes and other symbols are candidates for

th e Type 1 font format on ly in sofar as th ey are letter-like. Wh ile

a graph ic symb ol m ay benefit from bein g m ade into a character

in a fon t, extrem ely com plicated graph ic con struction s are better

served by the Type 3 font format as described in the PostScript

Language Reference Manual.

1.2 What This Document Does

The Type 1 font format is a subset (and extension) of the Post-

Script language, with its own syntactical rules. This document

explain s h ow to create a Type 1 fon t program th at will run prop -

erly in the PostScript interpreter and with other Type 1 font

rendering software such as Adobe Type Manager. It also gives a

developer the information n ecessary to decrypt and un derstand

the organization of existing Type 1 font programs (such as the

font software included in the Adobe® Type Library). This docu-

ment assumes familiarity with the PostScript Language Reference

Manual, especially th e in formation abou t font p rograms.

Note Although Type 1 font format elements are fully explained here, this

document does not include any algorithms that achieve the results

specified; for example, it does not include details of the rendering algo-

rithm used by Adobe’s PostScript interpreter.




Som e person al com pu ter file system s require special form ats for

disk files that differ from the ASCII text format described here.

The Apple Macintosh ® and the IBM® PC are two such systems.

This document does not discuss the details of formats used by

such file systems; these formats can be derived from the ASCII

font program inform ation described h ere. Special file formats for

these and other file systems are discussed in Technical Note

#5040, Supporting Downloadable PostScript Fonts, available fromth e Adob e System s developer sup port group.

1.3 Versions and Compatibility

The PostScript interpreter has undergone continual enhance-

ment since its debut in late 1984. During this time, Adobe

Systems has changed both the PostScript interpreter implemen-

tation an d th e features of the Type 1 fon t format. Th ese ch an ges

are gen erally com pat ible with all version s of th e PostScript in ter-

preter.

Th ere are several n otes in th is docu m ent abou t h ow specific fon t

program features are treated in older versions of the PostScript

interpreter. In som e cases, inform ation th at was requ ired by o lder

version s of th e PostScript interpreter for op tim al ren dering is no

longer needed because more sophisticated algorithms are avail-

able in newer versions of the interpreter. In general, the

rendering of typefaces described in the Type 1 font format will

con tinu e to look bett er with succeeding version s of the PostScript

interpreter (with ou t ch an gin g existin g Type 1 fon t software at all)

as Adob e System s con tinu es im provin g th e PostScript interpreter.

Any future extensions of the Adobe Type 1 font format will be

design ed so th at th ey may be ignored by th e current gen eration

of interpreters. Th ese n ew features will often take th e form of n ew

diction ary entries; oth er exten sion s may invo lve subrou tine calls

th at can be skipped safely. As lon g as in terpret ers for Type 1 fon t

software are written to ign ore such po ssible future features, th ese

features will not cause trouble. Future extensions will be thor-

ou ghly described in revised version s of th is docu m en t.



Chapter 1: Introduction 5

Some Type 1 font rendering software (such as the Adobe Type

Manager product) take advantage of a particular stylized use of

the PostScript language. As a result, a Type 1 font program must

also ad h ere to th ese PostScript language usage con vent ion s. Th e

language resulting from these conventions is considerably more

restricted than the PostScript language; a Type 1 font program

can b e read an d executed b y a PostScript interpreter, but n ot all

PostScript lan guage usage is acceptable in a Type 1 fon t p rogram .Th ese restriction s will be n oted wh erever n ecessary in th is docu-

ment, particularly in Chapter 10, “Adobe Type Manager

Compatibility.”

1.4 Copyrights for Type 1 Font Programs

Since Type 1 font s are expressed as com pu ter program s, they are

copyrigh table as is an y oth er com pu ter software. For som e time,

the copyright status of some types of typeface software was

unclear, since typeface designs are not copyrightable in theUn ited States. Because Type 1 font s are com pu ter program s rather

than mere data depicting a typeface, they are clearly copyright-

able.

A copyright on a Type 1 font program confers the same protec-

tion against unauthorized copying that other copyrightable

works, including computer software, enjoy. The ideas expressed

by copyrighted works are not protected; only the particular

expression is. In t h e case of Type 1 fon t p rograms, th e typeface

shap es are not protected, but t h e program t ext is. A copyrigh t on

a Type 1 font program that generates a particular typeface does

not preclude anyone from independently creating a different

program for that sam e typeface.

Th e activity prevent ed by copyright is copyin g. Copying includes

obvious acts such as verbatim copying and distribution. It also

covers less obviou s activities such as m odification an d tran slation

into different forms. If th e copyrighted work, in th is case a Type

1 fon t p rogram, is the sou rce of th ese activities, th en th e activities

are illegal if no t au th orized by t h e copyrigh t h older.




Ado be System s’ Type 1 fon t p rogram s are licensed for u se on on e

or m ore devices (depen din g on th e terms of particular licen ses).

These licenses would permit the use of a licensed program in a

system that translates a Type 1 font program to some other

format in th e process of rend erin g, as lon g as a copy of th e pro-

gram (even in tran slated form) is n ot pro du ced.

The personal computer software industry has benefitted greatlyfrom copyright protection. Competition is keen, and users bene-

fit from the efforts software developers have found to be

worthwhile. Copyright protection gives the developer of a Type

1 font program the incentive to create excellent typeface pro-

grams. In turn, the user of Type 1 font programs can expect to

h ave available th e fin est typ eface software to ch oose from .



7

CHAPTER2

A font program written in the PostScript language is a program

th at is an o rganized collection of procedures describin g character

shap es. Elemen ts of th is collection are accessed by ch aracter code

with the show operator, as described in the PostScript Language

Reference Manual. Different font programs contain different

amounts of diverse information, this information is collected

into a dictionary. The dictionary contains required and optionalen tries, an d is th e data ob ject th at th e PostScript interpreter ref-

erences for all fon t o peration s.

2.1 Building Characters

Every Type 3 (user-defined) font program requires a font dictio-

nary entry named BuildChar, as described in the PostScript

Language Reference Manual . Th e value associated with th is n am e is

a procedu re th at th e PostScript int erpreter calls when ever it n eeds

to h ave a character built. Th e Type 3 BuildChar pro cedu re is free

to u se wh atever m eth od it ch ooses to supp ly the PostScript in ter-

preter with graph ics com m an ds to paint th e ch aracter associated

with a character code. Generally, BuildChar procedures operate

by selectin g a p articular procedu re for building a ch aracter from

an array or from a dictionary of such procedures stored in the

font d iction ary.

In contrast, Type 1 font programs implicitly reference a special

BuildChar pro cedu re called Type 1 BuildChar th at is in ternal to the

PostScript interpreter. Consequently, there is no explicit entry

named BuildChar in a Type 1 fon t diction ary; th e fact th at it is a

Type 1 font program implies that it uses Type 1 BuildChar. In

essen ce, th e description of th e Type 1 fon t form at is th e explana-

tion of th e fun ctions of Type 1 BuildCh ar.

Font ProgramOrganization




Type 1 BuildCh ar begin s by usin g th e character code as an ind ex

into th e Encoding array in th e fon t dictionary to obtain th e nam e

of th e character to be built. Th is step is explain ed in th e PostScript

Language Reference Manual; am on g oth er advantages, it enables a

user to re-encode a Type 1 font program by changing the

Encoding array without changing anything else. Type 1 Build-

Char then uses the name of the character to be built as a key in

th e CharStrings dictionary (con tain ed in th e font dictionary) toobtain a binary string. The string is an encoded and encrypted

represen tation of a PostScript language program for th at ch arac-

ter’s outline. Finally, Type 1 BuildChar calls a special version of

stroke or fill, depen ding on th e value of PaintType in th e fon t dic-

tion ary, to create th e ch aracter.

Note Because Type 1 font program s were originally produced and were care-

fully checked only within Adobe Systems, Type 1 BuildChar was

designed with the expectation that only error-free Type 1 font programs

would be presented to it. Consequently, Type 1 BuildChar does not pro-

tect itself against data inconsistencies and other problems. For exam ple, Type 1 BuildChar does not issue error m essages. As long as

you follow the rules and suggestions given in this m anual, your font

programs will work. Deviations from the suggestions in this docum ent

are somewhat risky. Many problems are likely to be caught w ith an

invalidfont error; m ore subt le problems m ay result in incorrect behavior

by Type 1 BuildChar. Of course, any Type 1 font program produced

should be thoroughly tested at m any siz es and rotations, on several

devices, and with Adobe Type Manager software before release.



Chapter 2: Font Program Organization 9

2.2 Font Dictionary

Con structin g a Type 1 fon t program m eans con structin g a special

type of font dictionary. As with any PostScript language data

object, a PostScript language program constructs this dictionary.

A list of the required entries in a Type 1 font program is given in

th e PostScript Language Reference Manual, and includes the

CharStrings an d Private diction aries, wh ich are requ ired in everyType 1 fon t program .

Figure 2a is a conceptual overview of a Type 1 font program;

figure 2b sh ows the d ictionary structure th at th e font program

creates when it executes. The items contained in the figures are

explain ed in th is docum ent.

Figure 2a. Organization of a Type 1 font program

%!FontType1-1.0

eexec

/Private dictionary

/OtherSubrs

/Subrs 43 array

dup 0 15 RD ~15~binary~bytes~ ND

Type 1 Font Program

/CharStrings 190 dict dup begin

/ .notdef 9 RD ~9~binary~bytes~ ND

/A 186 RD ~186~binary~bytes~ ND

end end readonly put noaccess put

dup / FontName get exch definefont pop

mark currentf ile closefile

00000000000000000

00000000000000000

cleartomark

ASCII

Binary onlycharstringencryption

ASCII

eexecencryption

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Binary onlycharstringencryption




Figure 2b. Typical dictionary structure of a Type 1 font program

2.3 Explanation of a Typical Font Program

Th e program code th at follows is a generalized exam ple for a typ-

ical Adobe Type 1 font program. It is derived from the Symbol

font program . Because man y parts of a fon t defin ition are repeti-

tive, much of the repetition in the following example has been

om itted. Th e omitted portion s are docum ented with comm ents.

Items not explicitly discussed here are covered in the PostScript

Language Reference Manual.

/FontInfo

/FontName

/Encoding

/PaintType

/FontType

/FontMatrix

/FontBBox

/UniqueID

/Metrics

/StrokeWidth

/Private

/CharStrings

(/FID)

dictionary

name

array

integer

integer

array

array

integer

dictionary

number

dictionary

dictionary

fontID

/version

/Notice

/FullName

/FamilyName

/Weight

/ItalicAngle

/isFixedPitch

/UnderlinePosition

/UnderlineThickness

string

string

string

string

string

number

boolean

number

number

/RD

/ND

/NP

/Subrs

/OtherSubrs

/UniqueID

/BlueValues

/OtherBlues

/FamilyBlues

/FamilyOtherBlues

/BlueScale

/BlueShift

/BlueFuzz

/StdHW

/StdVW

/StemSnapH

/StemSnapV

/ForceBold

/LanguageGroup

/password

/lenIV

/MinFeature

/RndStemUp

procedure

procedure

procedure

array

array

integer

array

array

array

array

number

integer

integer

array

array

array

array

boolean

integer

integer

integer

array

boolean

/A

/B

/.notdef

charstring

charstring

charstring

.

.

.

.

.

.

/ CharStr ings dict ionary

/ Font Info dict ionary / Private dict ionaryfont dictionary




Example 1.

%!FontType1-1.0: Symbol 001.003

%%CreationDate: Thu Apr 16 1987

%%VMusage: 27647 34029

% Copyright (c) 1985, 1987 Adobe Systems

% Incorporated. All rights reserved.

11 dict begin

/FontInfo 8 dict dup begin /version (001.003) readonly def

/FullName (Symbol) readonly def

/FamilyName (Symbol) readonly def

/Weight (Medium) readonly def

/ItalicAngle 0 def

/ isFixedPitch false def

/UnderlinePosition -98 def

/UnderlineThickness 54 def

end readonly def

/FontName /Symbol def

/PaintType 0 def

/FontType 1 def /FontM atrix [0.001 0 0 0.001 0 0] readonly def

/Encoding 256 array

0 1 255 {1 index exch /.notdef put } for

dup 32 /space put

% . . .

% . . . repetitive assignments to Encoding array omitted

% . . .

dup 254 /bracerightbt put

readonly def

/FontBBox {-180 -293 1090 1010} readonly def

/UniqueID 6859 def

currentdict endcurrentfile eexec

05f3acf73b42a65ec11a12df4c6e26

5306f37b5075f007986cdacc4cd13a

49703465ba20c83c12707f179c0586

3d27adc72767ec06a47e733401fa8d

% . . .

% . . . thousands of eexec-encrypted bytes omitted

% . . .

000000000000000000000000000000

000000000000000000000000000000

% . . .

% . . . many zeros omitted% . . .

000000000000000000000000000000

000000000000000000000000000000

cleartomark




As seen in th e precedin g examp le, a Type 1 fon t pro gram is a pro-

gram written in the PostScript language. It begins with

com m en ts, som e of wh ich shou ld be self-explanat ory.

All Type 1 fonts m ust begin with th e comm ent:

%!

This enables a file containing a PostScript program to be easily

identified as such. It is important that every Type 1 font pro-

gram—in deed, every PostScript language p rogram—start with a

“%!” comment; otherwise, it may not be given the appropriate

h and lin g in som e operating system en vironm ents.

Th e remain der of th e first line (after th e “%!”) sh ou ld ident ify th e

file as a con formin g Type 1 fon t p rogram. A Type 1 fon t p rogram

con forms to th e specified version of th e Type 1 fon t format if th e

first line consists of the following characters:

%!FontType1-SpecVersion : FontName FontVersion

where the n um ber SpecVersion is th e version of th e Ado be Type 1

font form at to which t h e fon t program con form s (this docum ent

describes Version 1.1 of th e Adobe Type 1 Font Format ), FontName

is th e nam e of th e fon t un derstood by th e PostScript in terpreter,

an d FontVersion is th e version n um ber of the font program . For

example, the font program shown as an example in this docu-

m ent begin s with:

%!FontType1-1.0: Symbol 001.003

Note Application programs should also look for the form used by font pro-

gram s from Adobe: “%!PS-AdobeFont-1.0: FontNam e version”.

Th e comm ent:

%%VMusage

is useful for application programs, not for the PostScript inter-

preter itself. The application program can use the information

before downloading a font program to decide whether a given

PostScript interpreter has enough VM storage remaining to

accommodate this particular font program. A Type 1 font pro-gram manufacturer can determine the VM usage values by

issuing a vmstatus command before and after downloading a

font, and th en again after downloading th e same font a secon d

time. The difference between the first and second numbers

(before and after the first downloading) yields the second argu-




ment in t he %%VMusage comm ent; th e differen ce between th e

secon d an d th ird (after the secon d do wn load) give the first argu-

ment .

Th e larger nu m ber on th is l in e indicates the am oun t of VM stor-

age this font program will consume if it is the first to be

downloaded; the smaller number indicates the minimum

amo un t of VM th is fon t program will need. Th e nu m bers are n otequal because som e items, such as nam es, can sh are VM storage

in som e version s of th e PostScript int erpreter. In syn th etic font s,

th ese n um bers can be very different from each oth er. See section

9.1, “Syn th etic Fon ts,” for m ore inform ation .

After the comments, the program allocates a dictionary with a

capacity of 11 elem en ts; th is dictionary will becom e a fon t d ictio-

nary. The program inserts eight items (FontInfo, FontName,

PaintType, FontType, FontMatrix, Encoding, FontBBox, and

UniqueID) in to th e diction ary. Th e 1000 to 1 scalin g in th e Font-

Matrix as sh own is typical of a Type 1 fon t p rogram an d is highlyrecommended.

Also h igh ly recom m en ded is th at th e values for th e FontBBox be

as accurat e as possible. Th e PostScript in terpret er uses th is in for-

m ation in m akin g decisions about fon t cach ing and clipping. Th e

FontBBox m ust be accurate (n ot all zeros) if the fon t pro gram u ses

th e seac com m an d for creatin g accented ch aracters. In th is situ-

ation, an accurate FontBBox is critical to forming unclipped

characters. If the font program does not make use of accented

characters defined by the seac command, then FontBBox can

consist of all zeros.

FontType must be set equal to 1 for all Type 1 fon t p rograms.

UniqueID is a value impo rtant to font ident ification an d in h elp-

ing t h e PostScript interpreter p roperly cach e ch aracters between

jobs. UniqueID is discussed later in this chapter.

Next in the example program is the Encoding array. The

Encoding array determin es which character codes are associated

with wh ich character nam es in th e fon t program. Th is character

encoding can be changed without altering anything else in thefont program .




The clear text portion of the font program is followed by an

eexec-encrypted portion. The clear text portion ends with an

invocation of the eexec operator, after which the font program

con tains ASCII h exadecim al encrypted text:

currentfile eexec

05f3acf73b42a65ec11a12df4c6e26

5306f37b5075f007986cdacc4cd13a

. . . thousands of eexec-encrypted bytes left out . . .

When eexec begin s operation, it p erform s a begin operation on

systemdict to en sure that t h e operators that follow will be taken

from systemdict. When eexec terminates, it automatically per-

forms an end operation to remove the systemdict th at i t begin s

here.

Th e text encrypted by eexec m ust b e followed by 512 ASCII zeros.

There may be white space characters (blank, tab, carriage return

or line feed) interspersed among these zeros. Some zeros will be

consumed by the eexec command; the remainder will be

encountered by the PostScript interpreter and pushed onto the

op erand stack. A mark operator with in th e en crypted text m arks

th e operan d stack, and th e final cleartomark operator cleans the

m ark an d th e extran eous zeros off th e operand stack.

2.4 Inside the Encrypted Portion

In th e en crypted portion of the font program are th e CharStringsand the Private dictionaries. The CharStringsdictionary con tain s

th e en coded com m and s that draw the ou tlin es of the charactersincluded in the font. The Private dictionary contains hin ts an d

subroutines. The hints in the Private dictionary apply to the

en tire font . Th e Private diction ary m ay also cont ain various Post-

Script language procedures that can modify the behavior of the

font program in some version s of th e PostScript interpreter. See

Ch apter 5, “Private Diction ary,” for m ore in formation abou t th e

h inting system and Type 1 fon t form at h ints.

Th e character string values in t h e CharStringsdictionary m ust be

encoded an d en crypted; decryptin g and decodin g th e strin g is an

intrin sic part of Type 1 BuildCh ar. Th ese encod ed an d en cryptedcharacter outline strings are called charstrings. When decoded,

each charstrin g bears a resem blance to a PostScript language pro-

gram, in that an operand stack and postfix syntax are used.

However, th e set of com m an ds in clud ed in th e ch arstrings is spe-

cial to Type 1 BuildCh ar, an d t h eir op erand s are restricted in type




an d ran ge. Th e operan d stack for ch arstring op eration is separate

from th e general PostScript language op erand stack. Som e com -

m an ds are similar to bu ilt-in op erators in th e PostScript language.

Oth er com m and s, such as th ose th at give hints to th e ch aracter

rendering algorithm, are unique to Type 1 BuildChar’s input

language.

Note Th e word “encoding” is used to describe two situations in the Type 1 font format. Charstring encoding refers to the particular form of char-

string contents, with com mands and operands represented by short

code sequences. Encoding vector refers to an assignm ent of character

nam es to character codes for use in character identification to the show com mand. The m eaning of the word “encoding” used in various places

in this document should be clear from its context.

By decrypting the eexec-encrypted portion of the Symbol font

program, the following simplified code appears. In this code, a

sequence of n binary bytes is indicated by the form

~n~binary~bytes~.

Example 2.

dup / Private 8 dict dup begin

/RD {string currentfile exch readstring pop} executeonly def

/ND {noaccess def} executeonly def

/NP {noaccess put} executeonly def

/BlueValues [-17 0 487 500 673 685] def

/MinFeature {16 16} def

/password 5839 def

/UniqueID 6859 def

/Subrs 43 arraydup 0 15 RD ~15~binary~bytes~ NP

% . . .

% . . . 41 subroutine definitions omit ted

% . . .

dup 42 23 RD ~23~binary~bytes~ NP

ND

2 index /CharStrings 190 dict dup begin

/Alpha 186 RD ~186~binary~bytes~ ND

% . . .

% . . . 188 character definitions omitted

% . . .

/.notdef 9 RD ~9~binary~bytes~ NDend

end

readonly put

noaccess put

dup / FontName get exch definefont pop

mark currentfile closefile




Two ad dition al item s (Private an d CharStrings) are added to th e

font d ictionary. In th e exam ple fon t program, Private is associ-

ated with a dictionary of eight items, RD, ND, NP, BlueValues,

MinFeature, password, UniqueID, an d Subrs. CharStrings is asso-

ciated with a dictionary of 190 items in the example; each of

these items in turn associates a character name (such as Alpha)

with an encoded and encrypted charstring. Type 1 BuildChar

interprets each charstrin g wh en th e character is sh own for thefirst time. The Subrs entry in the Private dictionary contains

charstrin g portion s th at can be referen ced mu ltiple tim es by sub-

rout ine calls from oth er charstrin gs.

Ch arstrings in actual Type 1 font program s use th e RD, ND , an d

NP PostScript lan guage procedures show n in th e preceding exam -

ple to reduce the size of the font program. In some fonts, these

names might be defined in userdict, or they might be nam ed -|,|-, and | respectively (constructed with hyphen and vertical bar

characters) in th e Private dictionary. Note that a character name

in th e CharStringsdictionary can n ot be either RD or ND or what-ever names are substituted for these names, because that would

redefine these critical procedures.

While ND an d NP are m erely abbreviation s th at save som e bytes

of PostScript language code each time th ey are used, RD is m ore

complicated. Each use of RD is followed by exactly one blank

character followed by a sequence of binary bytes that are the

charstrin g con ten ts. Th is ch arstring is n ot given in ASCII h exa-

decim al form —it is binary. RD itself is preceded by an integer th at

tells exactly h ow m an y binary bytes follow th e RD (n ot in cludin g

th e single blan k th at follows th e RD).

Note The RD , NP , and ND functions must be implemented by PostScript lan-

guage procedures and m ust be invoked by a single nam e as shown in

the program example. These functions may not be implemented by

equivalent in-line code.

Both the Private dictionary and all of the charstrings are given

th e noaccess attribute. Thus, a user of the PostScript interpreter

cannot read or write their contents. This is not necessary in a

Type 1 font p rogram; it h as been in clud ed in th is particular exam-

ple only to protect the contents of these items from casualreading. Note that while a user of the PostScript interpreter

can n ot access th ese item s, th e PostScript in terp reter itself (partic-

ularly, Type 1 BuildCh ar) can access th em .




Finally, th e definefont operator makes the first dictionary into a

font dictionary. It adds one more item, FID, to this font dictio-

n ary. Th e mark is provided so th at th e cleartomark operator that

follows the 512 zeros can remove extra zeros from the operand

stack.

Th e final currentfile closefile sequence terminates the operation

of the eexec comm and. When eexec term inates, it au tom aticallyperforms an end operation to remove the systemdict that i t

began.

Note Th e preceding exam ple shows a character nam ed “.notdef” defined in

the CharStrings dictionary. A Type 1 font program must have a

“.notdef” character defined in its CharStrings dictionary, even if it is

not referenced by the encoding vector.

2.5 Unique Identification Numbers and Font Names

Th e UniqueID is an optional entry that helps identify the font

program to th e in terpreter. Its prim ary purp ose is un iquely iden -

tifying bitmaps already created and cached from that font

program ; having a UniqueID allows the PostScript interpreter to

cache bitmaps across jobs.

Th e UniqueID is specified with th e entry n ame UniqueID both in

the font d ict ion ary and in the Private diction ary. Type 1 fon t dic-

tionaries presented to the definefont operator that differ in any

way except in the values of FontName, FontInfo, or Encodingmust have different UniqueID values. If the UniqueID values are

n ot present in both th e fon t dictionary an d Private diction ary, or

if th ey have different values, th en t h e fon t program is treated by

the interpreter as if it had no UniqueID at all: caching will then

be efficient for the immediate job, but the interpreter will not

cach e bitm aps for th at fon t across jobs.

If the UniqueID value in a font program is not unique, a subse-

quent application referencing a font program with the same

UniqueID can inadverten tly obtain bitmaps th at were cach ed by

the previous job. This is a particular problem for service bureaus

wh ere th e cached ch aracters m igh t be written to d isk and remain

th ere durin g subsequen t jobs.

Adobe Systems maintains a registry of UniqueID numbers and

font names for font programs created in the Type 1 format. The

UniqueID n um ber is an integer in th e range from 0 to 16,777,215




(224 -1). Each FontType has its own independent space of

UniqueID values. Th erefore, a Type 1 an d a Type 3 fon t p rogram

could have the same UniqueID number and be safely used

together without causing caching conflicts.

Th e nu m bers from 4,000,000 to 4,999,999 form an “open” range

for Type 1 font p rograms used in a “con trolled en viron m ent .” An

individual, company, or service bureau can create its own fontprograms—such as font programs with extra characters, with

logos, or with transformations—and assign numbers from the

open range. ID conflicts should not occur if all other font pro-

grams in use are from vendors whose UniqueID numbers have

been allocated by Adobe Systems.

Fon t vend ors wh o plan to widely distribut e Type 1 fon t program s

should obtain a UniqueID number for each font program. In

return for receiving UniqueID n um bers, the vendo r m ust agree to

pro vide Adobe System s with AFM (Ado be Fon t M etric) files for a ll

font programs released. This is necessary to register the fontname and to keep the database of font names and UniqueIDnumbers accurate and up-to-date. If you wish to obtain more

information or to request UniqueID n um bers for Type 1 fon t pro-

gram s, please write to :

UniqueID Coordin ator

Adobe Systems Incorporated

P.O. Box 7900

Mountain View, CA 94039-7900

Not all Type 1 font programs require a UniqueID. To determine

whether a font program needs one, consider the following

options:

• Published or widely-distributed fon t programs:

A vend or with a Type 1 font p rogram th at will be pu blished or

distributed should obtain a UniqueID number assignment

from Adob e System s and register th e fon t p rogram’s nam e.

• Limited-distribution o r private-use font program s:

Wh ether a UniqueID is required depen ds on on e of two p ossi-

bilities:

1. Controlled environm ent: If the font program is going to be

used only within a single department or company and the

user would like bitmaps created by the font program to

remain cached across subsequent jobs, insert a randomly-

selected number from the “open” range in both of the

dictionaries.




2. Uncertain distribution: If th e fon t program is to be sent to a

service bureau or if the distribution and printing environ-

ment is uncertain, Adobe encourages you not to use any

UniqueID number. Within a given job, caching still per-

forms well, but the chance of UniqueID conflict with oth er

jobs is elimin ated.

Type 1 fon t program s shou ld also have un ique n am es. To n am e afont p rogram , use the definefont op erator. In th e exam ple above,

the value associated with FontName is the argument for the

definefont operator. definefont takes the n ame an d a dictionary,

checks that t h e diction ary is a well-formed font diction ary, m akes

th e diction ary’s access read-on ly, and associates the fon t pro gram

n ame with th e dictionary in th e global dictionary FontDirectory.

(It also in serts an addition al en try wh ose nam e is FID and wh ose

value is an o bject of type fon tID; th is en try serves intern al pur-

poses in the font machinery. For this reason, a font dictionary

presented to definefont must have room for at least one addi-

tion al key-value p air.)

However, wh ile th e FontName key in th e fon t diction ary sh ould

be th e nam e of the font program , it is n ot n ecessarily the n ame

that identifies the font program to the findfont operator. The

n ame supplied to the definefont operator is th e nam e un derstood

by the findfont op erator. For t h is reason , Ado be System s will also

register fon t program n am es as part of th e UniqueID num ber and

font n ame data base.



21

CHAPTER3

Character description is the heart of any Type 1 font program.

Each character sh ape com prises a path drawn by a series of Post-

Script language programming statements. Each character in a

Type 1 fon t can con sist of no m ore than on e such path . Of course,

th is on e path m ay con tain several subpaths.

3.1 Character Geography

Altho ugh th ere are typograph ic term s for a wide variety of char-

acter features, discussion here will be limited to those features

relevant to Type 1 fon t characters an d th e Type 1 hin tin g mech -

anism.

Th e m ain vertical strokes of a character are gen erally kno wn as

vertical stem s, an d th e ho rizon tal strokes are kn own as h orizon -

tal stems. Stems can be straight or curved; see Figure 3a that

follows. For example, in a Type 1 font character, the top and

bottom curved strokes of an “O” can be considered horizontal

stems, and the left and right sides can be considered vertical

stems.

In addition to obvious stem-like features of a character, it is also

imp ortan t to ident ify serif shapes. For Type 1 h intin g pu rposes,

th e serifs on an “I” are considered h orizon tal stem s. Sim ilarly, th e

vertical serifs on th e cross stroke of a “T” are con sidered vertical

stems.

Character OutlineConsiderations




Figure 3a. Horizontal stems, vertical stems, and serifs

Th e rest o f th is discussion of character geograph y app lies main ly

to rom an alph abet typefaces. Wh ile oth er alph abets (sym bol setsand non-roman alphabets, such as Chinese and Arabic) share

many of these features, a detailed discussion of their differences

is beyond th e scope of th is docum ent.

Several h orizon tal measuremen ts help to defin e a character in th e

PostScript lan guage.

• A character’s origin is its initial reference point. The origin is

m ade to coin cide with th e current po int wh en th e ch aracter is

shown.

• A character’s width is a vector, generally ho rizon tal to th e righ t,

from the origin to the coordinate at which the current point

will be set after sho win g th is ch aracter.

• Th e left sidebearing is a vector, gen erally ho rizon tal to th e righ t,

from th e origin to a point wh ose x coordin ate coincides with

th e x coordin ate of th e leftmo st filled p art of th e character.

• Th e left sidebearing point is th e coordinate at wh ich th e left side-

bearing vector terminates. The y coordinate of the left

sidebearing p oin t is alm ost always 0. (There are always excep-tions in font program design, and there can be conditions

where th e y coordin ate of the left sidebearin g poin t is n ot 0—

but very few.) Th e first poin t in th e definin g path is m easured

relative to th e left sidebearing poin t; sub sequ en t path coordi-

n ates are measured relative to th e preceding path coordin ate.

vertical stemvertical stem

horizontal stem

horizontal stemserif

serif



Chapter 3: Character Outline Considerations 23

Figure 3b. Origin, width, left sidebearing and left sidebearing point

3.2 Alignments and Overshoots

Type 1 font h ints include m any vertical measuremen ts that apply

to an entire typeface. (Chapter 5, “Private Dictionary,” describes

Type 1 fon t h ints in greater detail.) Som e of th ese m easurem ent s

help to accurately represent the slight differences in alignment

between flat ch aracters an d rou n d ch aracters. In Type 1 font t er-

minology, the round characters are said to overshoot the flat

characters (at both top an d botto m ).

Type 1 BuildChar accepts alignment and overshoot information

in p airs of nu m bers. One n um ber in dicates th e flat position , or th e y coordin ate that flat ch aracters reach; the oth er nu m ber is the

overshoot position, or the y coordinate that curved characters

reach . Th e pair of n um bers is called an alignm ent zone. Th e differ-

ence between the numbers in an alignment zone is called the

alignment zone height ; this height is typically between 1 0 an d 20

un its. All coord inates in th ese description s are in character space

un its, and assum e th e 1000 to 1 ch aracter space to u ser space scal-

ing that is typical of the Type 1 font format. There is one

alignm en t zone of each type app licable across th e entire fon t pro-

gram . Several align m en t zon es are illustrated in Figure 3c.

• Th e baseline is th e y coordin ate of th e typograph ic baselin e of

th e fon t (th e line on wh ich m ost flat characters sit). Th e base-

lin e is typ ically zero.

nleft sidebearing

character width

next characterorigin

left sidebearing pointorigin




• Th e baseline overshoot position is the minimum y coordinate

just below the baseline that round parts of characters at the

baselin e reach . A value of -15 is typ ical. Note th at curved ch ar-

acters typically extend slightly below the baseline; as a result

th is value is typically n egative.

• Th e cap-height is th e y coordin ate of th e top o f flat capital let-

ters. A value of 700 is typical.

• Th e cap-height overshoot position is th e maximum y coordinate

just above the cap-height that the round parts of characters

reach . A value 10 to 2 0 greater than cap-height is typical.

• Th e x-height is th e y coordin ate of the top of flat, n on -ascen d-

ing lower case letters. A value n ear 450 is typical.

• Th e x-height overshoot position is the maximum y coordinate

just above th e x-height th at th e roun d p arts of lower case letters

reach . A value 10 to 2 0 greater than x-height is typical.

Figure 3c. Vertical measurem ents: baseline and baseline overshoot

position, x -height and x-height overshoot position, cap-height and cap-

height overshoot position

Alignment zones for the tops of character features are called top-

zones, and align m ent zon es for th e bottom s of ch aracter features

are called bottom-zones. For examp le, th e cap-height an d x-height

zones are top-zones, while the baseline zone is a bottom-zone.Top-zones and bott om -zon es are discussed furth er in Ch apter 5,

“Private Diction ary,” an d Ch apt er 6, “Ch arStrin gs Diction ary.”

baseline overshoot position

x-height overshoot position

x-height

cap-height overshoot position

cap-height

baseline




Nearly all rom an Type 1 fon t p rograms use baselin e, cap-height

and x-h eight align m ent zones. Som e of th ese fonts include o th er

alignm en t zon es as well. Th ese zon es may describe figure-h eight ,

ascender-height, descender-depth, superior baseline, ordinal

baseline, and so on. The particular set of zones is chosen

accordin g to th e design of the font; th ere is no requiremen t th at

an y particular set of zon es be used. For m ore inform ation , see the

definition of BlueValues in section 5.3, Chapter 5, “PrivateDictionary.”

3.3 Character Coordinate Space

In th e PostScript lan guage, characters h ave their own coordin ate

system distinct from the coordinate system used by a specific

device. Th e coordin ate system in wh ich characters are defined is

called character space, th e coord inate system u sed by a device is

called device space, and th e coordin ate system used in PostScript

language programs for placing objects on a page is called user space.

Type 1 fon t p rograms generally use a 1000 to 1 scalin g m atrix for

th e defin ition of th e relation ship of character space un its to u ser

space units. The FontMatrix value in these fonts is typically

[0.001 0 0 0.001 0 0]. Th us, 1000 ch aracter space un its will scale

dow n to 1 u ser space un it (before app lication of th e makefont or

scalefont operators in a PostScript language program). This

allows character space coordinates to be expressed in integer

values witho ut significant loss of precision for m ost fon t d esign s.

If add ition al precision is n ecessary, expression s such as 145 10 divm ay be used to provide a n um ber (in th is case, 14.5) that can n ot

be expressed d irectly in t h e charstrin g form at.

Figure 3d sh ows h ow two characters are situated in th e character

space coordinate system. Notice that the value of 1000 is not a

lim it of any kind —it simp ly provides a coordin ate system an d a

ratio for scaling ch aracters to th e on e un it m aster size.




Figure 3d. Character space coordinate system

The only exceptions to the standard 1000 to 1 scaling matrixinvolve obliquing, narrowing, and expanding transformations

applied to a font th at h ad been originally defined by a 1000 to 1

scalin g m atrix. Even in t h ese cases, at least on e dim en sion of th e

FontMatrix will be a simple 1000 to 1 scale. Coordinates and

width s sh ou ld be defin ed for the n orm al 1000 to 1 scale. If a dif-

ferent font matrix is applied, for example, to make an oblique

font from a n orm al fon t, th e new fon t m atrix will tran sform all

these coordinates and widths together.

Type 1 BuildChar expects that the absolute coordinate values

th at define a ch aracter outlin e do n ot d eviate too far outside of th e on e user space un it to which th e ch aracter space coord inates

will be tran sform ed. Absolute coordin ate values in both x an d y

direction s mu st be b etween -2000 an d +2000. (Wh en coordin ate

values are comp uted usin g th e div comm and, its operands m ay be

ou t of this ran ge; th e final result of such a com pu tation h owever,

m ust be with in th is range.)

3.4 Character Paths

A character is mad e up of PostScript language code th at draws th e

character in character space. Th e first step in p reparin g th e con-tents of a charstring is to develop a PostScript language program

that defines the character outline in character space. An outline

is defined by building a path with the moveto, lineto, curveto,

closepath, rlineto, etc. operators. On ly ch aracters defin ed by ou t-

lin es m ay be in clud ed in Type 1 fon t program s; for exam ple, the

Å712

961

y500

-250




image an d imagemask operators are no t allowed. On ce th e path

has been expressed using only integer constants (and operations

on them) for coordinates, it is a simple matter to translate from

th e pu re PostScript language op erators to th e special set o f com-

m an ds recogn ized by Type 1 BuildCh ar. Th e charstrin g encod ing

allows on ly in tegers as n um eric constan ts; h owever, n on -integer

values can be created as a result of arithmetic operations and

passed to the commands. See Chapter 6, “CharStrings Dictio-n ary,” for th e com plete list of allowable charstrin g com m an ds.

Man y version s of the PostScript interpreter h ave an intern al limit

of 1500 flattened path elements per character; exceeding this

bound results in a limitcheck error. Each character outline in a

given font design must not exceed this l imit when rendered.

Each Type 1 font program shou ld be tested sufficien tly to verify

th at th e fon t program b ehaves well with respect to th is lim it. Th e

upper limit can be checked by testing at least the more compli-

cated characters in a given font (the ch aracters with th e greatest

n um ber of path com m an ds) at a reason ably large size, for exam-ple, 200 points. The characters should be tested on a high-

resolution device set to its highest resolution, where flattening

results in th e m ost segm ent s. Th e fon t sho uld, of course, also be

tested with th e Adob e Type Man ager software produ ct. Kan ji font

characters n eed on ly be tested on Kan ji prin ters sin ce these prin t-

ers have significantly increased limits for the number of path

elem en ts allowed.

Sh ou ld a ch aracter result in a limitcheck error, th e on ly ch oice is

to t ry to reduce the nu m ber of path comm ands or to con vert the

font in to th e Type 3 fon t format.

Note A Type 1 font character is filled as one path; complicated characters

can produce a limitcheck error. You must experiment to find the flat-

tened path limit for any particular combination of device and version

of the PostScript interpreter. This is why Adobe Systems encourages

extensive font program testing before release. Generally, your font pro-

gram either will run acceptably or it will generate a limitcheck error.

3.5 Direction of Paths

A subpath that is to be filled must be defined in a counterclock-

wise orientation in character space. A subpath that is to be left

un filled m ust be defin ed in a clockwise orien tation . If you im ag-

ine walkin g alon g a subp ath in th e direction it is defined, th en a

filled area should be on your left. This convention allows Post-




Script language programs to create combinations of paths

involving characters with reliable winding number orientations.

On som e im plem ent ation s of Type 1 BuildCh ar, th is orientation

is expected; some ren dering algorith m s depen d on it.

Figure 3e. Construct subpaths in the correct direction

3.6 Overlapping Paths

A single closed outline should not intersect itself; this can cause

winding number problems. If two filled subpaths in a character

overlap, there may be no problem when the character is filled.

However, a Type 1 fon t p rogram can also be stroked alon g its out -

line when the user changes the PaintType entry in the font

diction ary to 2. In th is case, overlappin g subpath s will be visible

in the output; this yields undesirable visual results in outlined

characters. Always construct the character paths with outlined

output in mind.

Figure 3f. Avoid overlapping subpaths

Filled ch aracter St roked ch aracter: in correct St roked ch aracter: correct



2

CHAPTER4

At first it m ay seem th at character outlines need n ot d iffer m uch

from oth er graph ic ou tlin es. However, th e requ irem en ts of letter

form s im pose mo re strin gen t requirem ents on a character outlin

if it is to loo k good . Makin g a PostScript language im plem en ta

tion of a typeface design involves two essen tial con sideration s:

• Th e ch aracter paths must accurately express th e true analo

shap es of th e original design.

• Certain conven t ion s m ust be observed to h elp th e in terprete

accurately scale for all sizes.

Failure to observe either of these conventions can result in

uneven stems, unwanted pixels, poor curve shapes, and poo

transitions from straight to curved sections. While there are n

hard and fast rules for font outline design in a Type 1 font pro

gram, paying atten tion t o th e guidelin es discussed in th is chap te

will help ensure pleasing results.

4.1 Points at Extremes

An endpoint (first or last point of a lineto or curveto) sh ould b

placed at m ost h orizon tal or vertical extrem es. Th is imp lies tha

m ost curves shou ld n ot in clud e mo re than 90 degrees of arc. Th

placement of extreme points aids the rendering algorithms in

prop erly reprodu cin g th e m ajor features of ch aracters. Of course

points may be placed anywhere else on the character outline, a

lon g as th e im portan t extremes are defin ed as well. It is n ot n ec

essary to place an end poin t at extremes of very sm all curves such

as th e tips of curved serifs.

Technical DesignConsiderations




Figure 4a. Place endpoints at m ost extremes (arrow indicates a possible

exception)

4.2 Tangent Continuity

Th e sm ooth , curved path elemen ts that form th e lines of a type

face are particularly hard to represent well when the outpu

technology is raster-based. Tangent continuity describes th

method that well-designed fonts use to produce outlines with

sm ooth transitions.

Wh enever on e path element sh ould m ake a sm ooth t ran si tion t

the next element (for example, straight line to curve, curve to

straight line, or curve to curve) th e end poin t joinin g th e two ele

ments and the Bézier control points (the off-curve points

associated with th at end point (for curves) or th e oth er endp oin

(for lines) should all be collinear. This is especially important a

h orizon tal and vertical extremes, wh ere sligh t deviation s ten d t

be m agnified b y interaction with th e pixel grid.



Chapter 4: Technical Design Considerations 3

Figure 4b. Make smooth transitions between path elements

4.3 Conciseness

Character outline definitions should be as concise as possible

without breaking the other rules. This achieves minimum

m emo ry usage and m axim um speed in th e rend ering system, an

sim plifies the task of addin g hin ts.

• Use the fewest Bézier curve segmen ts th at accurately represen

a shape.

• Do no t use consecutive collin ear straight l in e segm ents.

• Do n ot draw straight l in es by using col lin ear curveto defini

tion s (for examp le, “0 0 moveto 0 10 0 20 0 30 curveto”).

• Whenever possible , use the closepath comm and to draw on

of the straight line segments, rather than closing a characte

with a closepath th at results in a zero-length lin e segmen t.

• In gen eral, fin d th e sm allest sequence of comm ands that accu

rately d escribe th e ch aracter shap e.

Correct

60,100 80,100 100,100

120,0

120,60

120,85

52,75 65,75 78,75

Incorrect

60,10280,100 100,101

120,0

120,60

121,8

52,74 65,75 78,75




Figure 4c. Paths should be concise

4.4 Consistency

The key to getting the best possible results is consistency. Th

original designs of most typefaces include many repeatin

weigh ts, align m en ts, an d sh apes. Often, h owever, th e process o

creating d igital outlin es in trod uces sm all errors th at can obscur

the repeating nature of these features. Seemingly insignifican

differences can become exaggerated on digital devices. Whereve

po ssible, th ese errors sho uld b e elim inated .

• All stems whose width s are in tended to be th e same shoul

h ave exactly the same width .

• All characters th at are in tend ed to align sh ould align at exactl

the sam e y coordinate.

• All sh apes that are intended to be the sam e sh ould be exact l

th e same.

• All spacin g characteristics (sidebearin gs) th at are int en ded t

be th e same sh ould be exactly the same.

Correct In correct



Chapter 4: Technical Design Considerations 3

It is possible to carry consistency too far. It is important to kee

in m ind th at Type 1 fon t program s are used to set type at any siz

on a wide ran ge of digital devices. Type 1 fon t p rograms can b

used on all PostScript language devices. Th e resolution an d m ark

ing characteristics of these devices vary widely. They includ

display monitors, laser printers, typesetters, thermal transfe

color printers, film recorders and many others. The resolution

range from about 75 d pi to 3000 dpi or mo re.

Consistency should be applied only as long as it accuratel

reflects the original design. Some trade-off between the result

obtain able at low an d h igh resolution s is in evitable. It is possibl

to achieve high quality on a particular device by adjusting th

outlines to optimize for its resolution and imaging characteris

tics, for exam ple, for 300-dp i write-black laser prin ters. However

such font software may give unsatisfactory results on device

with very different characteristics and much higher resolution

Th ere are n o requirem ents in th e Type 1 font form at th at shoul

cause fon t d esign com prom ises in th e interests of consisten cy.



35

CHAPTER5

Th e Private dictionary contains hints that apply across all the

characters in th e fon t, subro utin es, and several oth er item s such

as a password. Refer to Appendix 1 for a complete listing of the

required and option al entries in th e Private dictionary.

Th e hin ts used in character outlines help to preserve properties of

shapes wh en rend ered at limited resolutions. Wh en th e nu m berof pixels in a character increases, as with very large characters or

on high-resolution output devices, the hints become less impor-

tant. When a stem is rendered at 100 pixels wide, a 1-pixel

differen ce matters m uch less th an wh en th e stem is rendered at

only 2 pixels wide. Thus, the implementation of hints mostly

concerns rasterization properties at low resolutions and small

sizes. With the hints in place, Type 1 BuildChar can produce

results that are as close as possible to the original design even

though the shape is reproduced by a relatively small number of

pixels.

5.1 Declarative Hints

As with an y software, th ere are m an y po ssible ways to d esign a

system to compensate for low resolutions and small character

sizes on a raster out pu t d evice. Som e m eth od s are m ore efficien t

th an oth ers for mo difying ch aracter outlines at variou s sizes an d

rotations, for requiring minimal storage, and for allowing inde-

pen den ce from an y given level of rend erin g tech n ology.

Adobe Systems has created a predominantly declarative hint

system for Type 1 font programs. Declarative hints state con-

straints on the size and positioning of character features, for

example, the width of a stem or the location of an extremity.

These declarative hints are stated in two distinct locations in a

font p rogram. The Private dictionary contains a nu m ber of fon t

Private Dictionary




level hin ts th at app ly across all characters represen ted in th e font

program ; th e ind ividu al charstrin gs in th e CharStringsdictionary

con tain ch aracter level h ints th at describe im portan t typograph ic

features about a particular character.

A declarative hint system depends on an intelligent rasterizing

algorith m to rend er character outlines correctly. Adob e h as built

such an algorithm into the PostScript interpreter and its otherrendering software, such as the Adobe Type Manager program.

Consequently, the appearance of font characters created with

declarative hin ts will con tinu e to im prove as h int h an dling algo-

rith m s im prove, withou t m odifyin g th e Type 1 font program s.

5.2 Font Level Hints

Hint s that app ly across an ent ire fon t are declared by settin g cer-

tain values in th e Private diction ary. Man y of th ese h ints d eclare

con straint s on th e vertical position s of character features acrossthe entire font. This helps to maintain consistency across the

font, especially when rendered at low resolution. For historical

reason s, th ese h ints are indicated by n ames th at contain th e word

“Blue.”

For example, Type 1 BuildChar uses the information in the

BlueValues an d OtherBlues arrays to adjust th e renderin g of ch ar-

acter features that fall within alignment zones. This adjustment

is called alignm ent control, which at small sizes includes overshoot

suppression . At sm all sizes, wh en on ly a few pixels m ust represen t

a character, a on e-pixel oversh oot ap pears too p rom inen t.

5.3 BlueValues

The value associated with BlueValues is an array containing an

even n um ber of integers taken in pairs, and w h ich follow a sm all

n um ber of rules:

• Th e first integer in each pair is less th an or equal to th e secon d

integer in th at pair.

• Th e first pair is th e baseline oversh oot position and th e base-lin e. Th is is a bot tom -zone.



Chapter 5: Private Dictionary 37

• All subsequent p airs describe top-zones, that is, align m ent

zones for th e top s of ch aracter features, for exam ple, x-h eigh t

and x-height overshoot position, ascender-height and

ascender-height overshoot position, cap-height and cap-

height overshoot position, figure-height and figure-height

overshoot position.

• Up to seven pa irs may be given in the BlueValues array; thefirst p air mu st be th e baselin e pair.

• Differen t pairs m ust be at least 3 un its apart from each oth er

and from pairs in OtherBlues, as described in the following

section. (This minimum distance can be modified by the

opt ional BlueFuzz entry in th e Private diction ary; see th e def-

inition of BlueFuzz, that follows.)

• The m axim um difference between values in one pair is con-

strained as described under the description of BlueScale, that

follows.

For example, an array for the baseline, cap-height and x-height

alignm en t zon es in a typ eface m igh t be defin ed as follows:

/BlueValues [-15 0 700 715 547 559] def

Despite the names given to the various alignment zones

described by the BlueValues, Type 1 BuildChar has no built-in

notions of which parameters apply to which characters. Each

zone helps to control the alignment of any and all characters

with ch aracter level h ints th at fall within th e zon e.

Th e BlueValues array is required in the Private dictionary. If no

alignm en t zon es are necessary, use an em pty array for the value

of BlueValues:

/BlueValues [ ] def




5.4 OtherBlues

Th e option al OtherBlues entry in the Private diction ary is associ-

ated with an array of pairs of integers similar to the BlueValuesarray. However, the OtherBlues array describes bottom-zones

only. For example, these may include: descender-depth over-

shoo t position an d descend er-dept h , superior baselin e oversh oot

position and superior baseline, and ordinal baseline overshootpo sition an d o rdin al baseline. Up to five pairs (10 integers) may

be specified in the OtherBlues array. Numbers in a pair must be

in ascendin g order, with th e same restriction on th e m axim um

difference in a pair. Pairs must be at least 3 units apart from all

oth er pairs, in cludin g tho se in th e BlueValues array. (This mini-

m um d istance can be m odified by th e option al BlueFuzz entry

in th e Private dictionary.)

5.5 FamilyBlues and FamilyOtherBlues

Wh en d ifferent styles of th e sam e fon t family are mixed in text,

it is often desirable to coordinate their x-heights, cap-heights,

an d ot h er align m ent s so th at th ey will be th e sam e at sm all sizes.

For example, at 72 pixels per inch, the x-height of a 10-point

rom an face might b e 5.4 pixels wh ile th e boldface x-h eight m igh t

be 5.6 p ixels. If th e rom an face is th e stand ard for th e fam ily, Type

1 BuildChar in recent versions of the PostScript interpreter can

render both faces with an x-height of 5 pixels instead of letting

th e boldface jum p to 6 wh ile th e rom an is still at 5. However, at

100 poin ts, th e roman x-h eight will be 54 pixels and th e bold x-

h eight will be 56.

You can include in form ation about th e dom inan t align m ent

zones in a font family so that this consistency can be enforced.

Wh en en abled, if the differen ce between a fon t’s align m ent an d

its fam ily’s stan dard align m en t is less than 1 pixel, th en Type 1

BuildCh ar will use th e stan dard alignm en t in stead of the n orm al

alignment for that font program. Thus at 10 points in the

previous example, the difference is 5.6 − 5.4 = 0.2 pixels so the

stand ard is used. At 100 poin ts, th e differen ce is 56 − 54 = 2, so

th e specific x-heigh t for th e font is used. Fam ily alignm ent values

are identical to individual font alignment values; i.e., they are

things like x-height, x-height overshoot, etc. The Privatediction ary en tries are as follows.




The value associated with FamilyBlues is an array containing an

even number of integers taken in pairs. The rules governing the

contents of this array are analogous to those of the BlueValuesarray.

The value associated with FamilyOtherBlues is an array contain-

ing an even number of integers taken in pairs. The rules

governin g th e conten ts of this array are analogous to th ose of th eOtherBlues array.

Typically, the FamilyBlues an d FamilyOtherBlues entries will

sim ply be copied from th e BlueValuesan d OtherBluesof the stan -

dard face in t h e fam ily. Each fon t program in a fam ily (except th e

stand ard face) mu st h ave th ese ent ries if it is to h ave fam ily align-

m en t p roperties. Of cou rse, if th ese ent ries are n ot p resen t, th en

on ly a fon t program ’s own alignm en t h ints will be considered.

Th e FamilyBlues an d FamilyOtherBluesen tries are relatively n ew

add ition s to th e Type 1 h int ing system . Currently, th ey are in ter-preted by ATM software version 1.2 (and later). These features

will also be recogn ized by fut ure versions of the PostScript in ter-

preter.

5.6 BlueScale

The optional BlueScale entry in the Private dictionary controls

th e poin t size at wh ich oversh oot suppression ceases. Th is po int

size varies with th e n um ber of device pixels per in ch available on

th e device wh ere th e fon t program is being rend ered.

• For point sizes th at occupy fewer device pixels th an th e

BlueScale value results in for a given device, overshoot sup-

pression is performed. All features falling in an alignm ent zon e

are rend ered at th e sam e pixel heigh t.

• For poin t s izes that occupy th e same n um ber or a greater

number of device pixels than the BlueScale value results in,

oversh oot sup pression is turn ed off, thu s allowin g overshoo ts

to occur. (This behavior may be modified by the optional

BlueShift settin g; see th e definition of BlueShift , that follows.)




Th e BlueScale value is a nu m ber directly related to th e nu m ber of

pixels tall th at on e character space un it will be before overshoo t

suppression is turned off. The default value of BlueScale is

.039625, wh ich correspon ds to 10 p oin ts at 300 dpi. A sim ple for-

m ula th at relates poin t size as rend ered on a 300-dpi device to th e

BlueScale value is:

BlueScale = (pointsize−

0.49)÷

240

The formula provides a convenient number that font program

designers can use to determine at what integer point size over-

shoo t supp ression shou ld be off. However, th e exact po int size at

wh ich oversh oo t suppression ceases is actually 0.49 po in ts less (at

9.51 points using the default value of BlueScale) than the value

of pointsize used in the formula. Adobe recommends using the

adjustment shown in the formula so that the change in over-

shoo t supp ression beh avior occurs at an exact poin t size un likely

to b e used in p ractice.

For exam ple, if you wish oversh oot supp ression to tu rn off at 11

points on a 300-dpi device, you should set BlueScale to

(11 − 0.49) ÷ 240 or 0.04379. With this one setting of BlueScale,

overshoot suppression will turn off at proportionately smaller

point sizes on higher resolution output devices or larger point

sizes on lower-resolution devices such as displays. A typical

BlueScale statemen t is:

/BlueScale .04379 def

Note There is a mandatory restriction on the BlueScale value and the

maximum height of an alignment zone that is best described in rela-tion to the 300-dpi point size discussed above. The product of

(pointsize − 0.49) × (maximum alignment zone height) must be less

than 240. For example, if the maximum alignment zone height is 23

in som e font program, then the overshoot suppression turnoff point size

at 300 dpi can be 10 but n ot 11 . This restriction ensures that overshoot

suppression will turn off before the overshoot reaches a full device pixel.

5.7 BlueShift

The optional BlueShift entry in the Private dictionary adds

ano th er capability to th e treatm ent of oversh oot behavior.

The value of BlueShift is an integer that indicates a character

space distance beyond the flat position of alignment zones at

wh ich oversh oot en forcemen t for character features occurs. Th e




default value of BlueShift is 7. The single setting of BlueShiftapplies to all alignment zones, regardless of where their over-

shoo t po sition s lie.

Wh en a character’s size is less than th at exp ressed by BlueScale,

character features that fall within alignment zones have their

overshoots suppressed. For characters larger than the BlueScale

size, character features that fall beyond the flat position of analignm en t zon e (above for top-zon es, below for botto m -zon es) by

a character space distance equal to or greater than the value of

BlueShift will overshoo t, wh ile character features closer to th e flat

posi t ion than the BlueShift value will overshoot only if their

device space d istan ce is at least on e-h alf pixel.

Th e BlueShift value m ust ob ey a restriction if th e Flex m echan ism

is used. For details, see section 8.3, “Flex,” in Chapter 8, “Using

Subroutines.”

5.8 BlueFuzz

Th e option al BlueFuzz ent ry in th e Private diction ary is an in te-

ger value that specifies the number of character space units to

exten d (in both direction s) th e effect of an align m ent zon e on a

h orizon tal stem . If the top of a horizont al stem is within BlueFuzzunits (in character space) outside of a top-zone, the interpreter

will act as if the stem top were actually with in t h e zon e; th e sam e

h olds for th e bottom s of h orizon tal stems in b ottom -zones. Th e

default value o f BlueFuzz is 1.

BlueFuzz has been a convenient means for compensating for

sligh tly inaccurate coordin ate data. Th e effect of a n on -zero value

for BlueFuzz can usually be better ach ieved by ad justin g th e sizes

of the alignment zones. Adobe suggests that new font programs

not rely on it and disable the feature by explicitly setting

BlueFuzz to 0 in th e Private dictionary. For example:

/BlueFuzz 0 def

Note Because a non-zero value for BlueFuzz extends the range of alignment

zones, alignment zones must be declared at least (2 × BlueFuzz + 1)

units apart from each other. Therefore, a default BlueFuzz value of 1implies that alignm ent zones should be at least 3 units apart from each

other.




5.9 Stem Width Information

There is a mechanism to tell Type 1 BuildChar about standard

stem widths in a font so that Type 1 BuildChar can ensure con-

sistency at small sizes. If a particular stem is slightly wider or

n arrower than stand ard, eith er by design or as a result of a sm all

error in creating the font program, then at small sizes where a

single pixel difference would be very noticeable, Type 1 Build-Char can render the stem as though it had the standard width.

However, at large sizes where a single pixel difference will pro-

duce only a subtle visual effect, the stem will be allowed to

deviate from th e stand ard.

Wh en t h e difference between a stand ard stem width and a partic-

ular stem width is small, th e stan dard width is used. For exam ple,

if at 10 points a standard stem width corresponds to 1.4 pixels

wide and a particular stem is 1.6 pixels wide, both can be ren-

dered as a 1-pixel wide stem. Ho wever, at 100 p oin ts th e stan dard

stem wo uld b e rend ered as 14 pixels wide and th e particular stemwou ld be rend ered as 16 pixels wide. Th e in formation th at Type

1 BuildChar needs appears in the following Private dictionary

entries.

The entry StdHW is an array with only one real number entry

expressing the dominant width of horizontal stems (measured

vertically in ch aracter space un its). For exam ple:

/StdHW [32] def

The entry StdVW is an array with only one real number entry

expressin g the do m inan t width of vertical stem s (measured ho ri-

zon tally in ch aracter space un its). Typically, th is will be th e width

of straigh t stem s in lower case letters. (For an italic fon t p rogram ,

give the width of the vertical stem m easured at an an gle perpen -

dicular to th e stem direction .) For exam ple:

/StdVW [85] def

Th e entry StemSnapH is an array of up to 12 real nu m bers of th e

m ost comm on width s (including th e dom in ant width given in

th e StdHW array) for horizontal stems (measured vertically).

Th ese width s m ust be sorted in increasing o rder. For exam ple: /StemSnapH [32 41] def




Th e entry StemSnapV is an array of up to 12 real n um bers of th e

m ost comm on width s (including th e dom in ant width given in

th e StdVW array) for vertical stems (measured horizontally).

These widths must be sorted in increasing order. For example,

you m igh t include width s for straight an d curved stems in u pper

and lower case letters. For an italic font, this array should be

em pty. For exam ple:

/StemSnapV [85 102] def

If th ese stem h ints are no t present in th e Private diction ary, th en

each stem is rendered according to its own definition (as modi-

fied by any oth er hints present in th e fon t program ).

Th e StdHW, StdVW, StemSnapH, an d StemSnapV en tries are rel-

atively new additions to the Type 1 hinting system. Currently

they are interpreted by ATM software version 1.2 (and later).

These features will also be recognized by future versions of the

PostScript in terpret er.

5.10 ForceBold

At sm all sizes on low-resolut ion devices (such as display screens),

features of bold characters may be rendered at only 1 pixel of

thickness. Since this is the minimum thickness possible on a

raster output device, normal (non-bold) characters also appear

with 1-pixel wide features. If th e boldn ess property is so imp or-

tant at these small sizes that bold characters should continue to

appear thicker than normal characters, some Type 1 font inter-

preters may apply special techniques to thicken bold characterfeatures.

If th e Private dictionary con tain s an entry n amed ForceBold, this

behavior can be controlled explicitly. The value associated with

ForceBold must be the Boolean value “true” or “false.” If the

value is “true,” then in situations where character stems would

normally be rendered at 1-pixel thick, a Type 1 font interpreter

m ay th icken th e stem . If th e value is “false,” then a Type 1 fon t

interpreter will n ot perform a special th ickenin g operation . To set

ForceBold, use the statemen t:

/ForceBold true def

Adob e stron gly advises fon t p rogram develop ers to use ForceBoldto direct font interpreters as to which bold thickening behavior

is desired.




5.11 LanguageGroup

Certain groups of written lan guages share broad aesth etic charac-

teristics. Identification of such language group s can prove u seful

for accurate ch aracter rend erin g.

The value of the entry LanguageGroup is an integer that indi-

cates the language group of the font program. If the Privatediction ary does n ot con tain th is en try, or if th e given value is n ot

recognized by Type 1 BuildChar, then the value of

LanguageGroup defaults to zero. At this time, Type 1 BuildChar

recognizes only two language groups, identified as group zero

and group on e. Th e futu re iden tification of oth er values for the

LanguageGroup en try is reserved by Adob e System s.

Language group 0 consists of languages that use Latin, Greek,

Cyrillic, and similar alphabets. Since the value of the

LanguageGroup entry defaults to 0, a font program correspond-

ing to o n e of these languages does not n eed to contain th is entry.

Language group 1 consists of Chinese ideographs and similar

character sets, in clud ing Japan ese Kan ji and Korean Han gul. Fon t

program s correspond ing to on e of these languages sh ould con -

tain th e Private diction ary en try:

/LanguageGroup 1 def

For compatibility with older PostScript interpreters, creators of

font program s specifying language group 1 m ust also include th e

RndStemUp ent ry in th e Private diction ary:

/RndStemUp false def

Th e RndStemUp entry has been superseded by the

LanguageGroup entry. No reference at all to the name

RndStemUp should be made in any font program unless i t

belon gs to language group on e.




5.12 lenIV

Th e lenIV entry is an integer specifying the number of random

bytes at the beginning of charstrings for charstring encryption.

Th e default value o f lenIV is 4.

To b e com patible with version 23.0 of th e PostScript interpreter

(fou n d in th e origin al LaserWriter®), th e value of lenIV sh ould beset to 4. If com patibility with version 23.0 prin ters is no t n eces-

sary, lenIV can b e set to 0 or 1 to save storage.

5.13 Compatibility Entries

Th e MinFeature an d password entries must be included in the

Private dictionary to allow Type 1 BuildChar to function

properly.

All Type 1 font programs should include the following assign-ments in the Private dictionary:

/MinFeature {16 16} def

/password 5839 def

5.14 ExpansionFactor

Th e option al ExpansionFactor ent ry is a real n um ber th at gives a

limit for changing the size of a character bounding box during

th e processin g th at adjusts th e sizes of coun ters in fon ts of Lan-guageGroup 1. Th e default value o f ExpansionFactor is 0.06. At

small point sizes or low resolutions, the system may have to

accept irregular coun ters rath er th an violate th is lim it. Bar code

fonts or logos that n eed coun ter con trol may ben efit by settin g

LanguageGroup to 1 an d increasing th e ExpansionFactor lim it to

a larger am ou n t such as 0.5 or m ore. For exam ple:

/ExpansionFactor 0.5 def



47

CHAPTER6

Th e CharStringsdiction ary ho lds a collection of nam e-procedu re

pairs. Th e procedures to wh ich th e n am es refer produ ce the fon t’s

character out lin es. Ch aracter procedu res can also call subro utin es

(located in th e Private dictionary) that produce similar parts of

characters, thus reducing storage requirements. The charstring

procedu res also con tain character level h ints.

6.1 Charstring Encoding

A charstring is an encrypted sequence of unsigned 8-bit bytes

that encode integers and commands. Type 1 BuildChar, when

interpretin g a ch arstring, will first decrypt it an d th en will decode

its bytes on e at a time in sequ en ce. Th e value in a byte ind icates

a comm and , a nu m ber, or subsequent b ytes th at are to be inter-

preted in a special way.

Once the bytes are decoded into numbers and commands, the

execution of these numbers and commands proceeds in a

m an n er similar to th e operation of th e PostScript language. Type

1 BuildCh ar uses its own op erand stack, called th e Type 1 Build-

Char operand stack , th at is distinct from th e PostScript interpreter

operand stack. This stack holds up to 24 numeric entries. A

number, decoded from a charstring, is pushed onto the Type 1

BuildChar operand stack. A command expects its arguments in

order on this operand stack with all arguments generally taken

from th e bottom of the stack (first argum ent bo ttom -m ost); h ow-

ever, some commands, particularly the subroutine commands,

n orm ally work from th e top of the stack. If a comm and return s

results, th ey are push ed on to th e Type 1 BuildCh ar operan d stack

(last result top m ost).

In the following discussion, all numeric constants are decimal

numbers.

CharStrings Dictionary




6.2 Charstring Number Encoding

A charstring byte containing the values from 32 through 255

inclusive indicates an integer. These values are decoded in four

ranges.

1. A charstrin g byte con tain ing a value, v, between 32 and 246

inclusive, ind icates th e in teger v − 139. Th us, th e integer values

from −107 th rough 107 inclusive m ay be encoded in a sin gle

byte.


inclusive, indicates an integer involving the next byte, w,

accordin g to th e form ula:

[(v − 247) × 256] + w + 108

Thus, the integer values between 108 and 1131 inclusive can

be encoded in 2 bytes in th is m ann er.


inclusive, indicates an integer involving the next byte, w,

accordin g to th e form ula:

− [(v − 251) × 256] − w − 108

Th us, th e int eger values between −1131 and −108 in clusive can

be encoded in 2 bytes in th is m ann er.

4. Finally, if the ch arstrin g byte con tain s the value 255, the n ext

four bytes indicate a two’s complement signed integer. The

first of these four bytes contains the highest order bits, the

secon d byte contains th e next h igh er order bits and th e fourth

byte contains the lowest order bits. Thus, any 32-bit signed

integer m ay be en coded in 5 bytes in th is m ann er (th e 255 byte

plus 4 m ore bytes).

Note Num bers with absolute values greater than 32,000 m ust be followed

by a div operator such that the result of the div is less than 32,000.

6.3 Charstring Command Encoding

Ch arstrin g com m and s are encoded in 1 or 2 bytes.

Single byte commands are encoded in 1 byte that contains a

value between 0 and 31 inclusive. Not all possible command



Chapter 6: CharStrings Dictionary 49

en codin g values are listed. Th e com m an d values th at are om itted

are special purpose commands that are not used in any down-

loadable Type 1 fon t p rogram, o r th ey are reserved.

If a com m and byte con tain s th e value 12, then th e value in th e

n ext byte in dicates a com m an d. Th is “escape” mech an ism allows

many extra commands to be encoded. These 2-byte commands

are not used as often as the 1-byte commands; this encodingtechnique helps to minimize the length of charstrings. Refer to

Appen dix 2 for a sum m ary of th e ch arstrin g com m and s an d th eir

en codin g values.

6.4 Charstring Command List

The Type 1 font program charstring commands are divided into

five groups by fun ction :

• Comm ands for start ing an d fin ish in g a character’s out lin e

• Pa th const ruct ion comm ands

• Hin t com m an d s

• Arit hm e tic com m a nds

• Subrou tine com m a nds

Th e followin g definition s use a format similar to th at used in th e

PostScript Language Reference Manual. Parentheses following the

comm and n ame either include th e com m and value th at repre-

sents this command in a charstring byte, or the two values

(begin n ing with 12) that represen t a 2-byte com m and .

Many commands take their arguments from the bottom-most

entries in the Type 1 BuildChar stack; this behavior is indicated

by the stack bot tom symbol ( ) appearin g to the left of the first

argum ent. Com m and s that clear the op eran d stack are indicated

by the stack bottom symbol ( ) in th e resul t posit ion of the com -

m and definition.

Because of th is stack-clearing beh avior, in gen eral, op eran ds m ay

not be piled up on the Type 1 BuildChar operand stack for later

remo val by a sequ ence of com m an ds. Operan ds generally m ay

be supplied only for the next command. Notable exceptions

occur with subroutin e calls and with th e div command.




Commands for Starting and Finishing

endchar – endchar (14)

fin ish es a charstrin g outlin e definition and m ust be th e last com -

m an d in a ch aracter’s outline (except for accented characters

defined usin g seac). Wh en endchar is executed , Type 1 BuildCh ar

performs several tasks. It executes a setcachedevice operation,

using a bounding box it computes directly from the character

outline and usin g the width information acquired from a previ-

ous hsbw or sbw operation . (Note th at th is is n ot th e same order

of events as in Type 3 Fonts.) BuildChar then calls a special ver-

sion of fill or stroke depending on the value of PaintType in th e

font dictionary. The Type 1 font format supports only PaintType0 (fill) an d 2 (outline). Note th at th is sin gle fill or stroke implies

th at th ere can be on ly on e path (possibly cont ainin g several sub-

paths) that can be created to be filled or stroked by the endcharcommand.

hsbw sbx wx hsbw (13)

sets the left sidebearing point at (sbx , 0) and sets the character

width vector to (wx, 0) in character space. This command also

sets the curren t poin t to (sbx , 0), but d oes not p lace the poin t in

the character path. Use rmoveto for the first point in the path.

The n ame hsbw stand s for h orizon tal sidebearin g an d width ; h or-

izon tal in dicates th at th e y component of both the sidebearing

an d width is 0. Eith er sbw or hsbw m ust be used on ce as th e first

comm and in a character outlin e definition . It m ust be used on ly

on ce. In n on -m arkin g characters, such as th e space ch aracter, th e

left sidebearin g poin t sh ou ld be (0, 0).

seac asb adx ady bchar achar seac (12 6)

for standard encoding accented character , makes an accented char-

acter from two other characters in its font program. The asb

argument is the x component of the left sidebearing of the

accen t; th is value m ust be th e sam e as the sidebearing value given

in th e hsbw or sbw comm and in th e accen t’s own charstrin g. Th e

origin of th e accent is placed at (adx , ady) relative to th e origin of

the base character. The bchar argument is the character code of

the base character, and the achar argument is the character code

of th e accen t ch aracter. Both bchar an d achar are cod es th at th esecharacters are assigned in the Adobe StandardEncoding vector,

given in an Appen dix in th e PostScript Language Reference Manual.

Furth ermo re, th e characters represen ted by achar an d bchar must

be in th e sam e position s in th e fon t’s en codin g vector as the p osi-

tions they occupy in the Adobe StandardEncoding vector. If the




name of both components of an accented character do not

app ear in th e Adob e Stan dardEncodin g vector, the accen ted ch ar-

acter cann ot be bu ilt u sing th e seac command.

Th e FontBBox entry in t h e fon t diction ary mu st be large en ough

to accomm odat e both parts of th e accented ch aracter. Th e sbw or

hsbw command that begins the accented character must be the

same as the corresponding command in the base character.Fin ally, seac is the last command in the charstring for the

accen ted ch aracter because the accent an d b ase ch aracters’ char-

strin gs each already end with t h eir own endchar commands .

The use of this command saves space in a Type 1 font program,

bu t its use is restricted t o t h ose characters wh ose parts are defined

in t h e Adob e Stan dardEn codin g vector. In situation s where use of

th e seac comm and is n ot p ossible, use of Subrs subrou tines is a

m ore general mean s for creatin g accent ed ch aracters.

sbw sbx sby wx wy sbw (12 7)

sets th e left sidebearin g poin t to (sbx , sby) and sets the ch aracter

width vector to (wx, wy) in character space. Th is com m an d also

sets the curren t poin t to (sbx , sby), but d oes n ot place th e point

in th e character path. Use rmoveto for the first point in th e path.

The n ame sbw stand s for sidebearin g and width ; th e x an d y com-

pon ents of both th e left sidebearing and width m ust be specified.

If th e y comp on ents of both th e left sidebearin g an d th e width are

0, then th e hsbw comm and sh ould be used. Either sbw or hsbwmust be used once as the first command in a character outline

definition. It mu st be used on ly on ce.

Path Construction Commands

closepath – closepath (9)

closepath closes a subp ath . Adob e stron gly recom m en ds th at all

character subpaths end with a closepath command, otherwise

wh en an ou tlin e is stroked (by setting PaintType equal to 2) you

m ay get un expected behavior where lines join . Note that, un like

th e closepath command in the PostScript language, this com-

mand does not reposition the current point. Any subsequent

rmoveto m ust be relative to th e curren t po int in force before th eType 1 fon t form at closepath comm and was given.

Make sure that any subpath section formed by the closepathcomm and inten ded to be zero len gth, is zero length . If n ot, the

closepath command may cause a “spike” or “hangnail” (if the

subpath dou bles back on to itself) with un expected results.




hlineto dx hlineto (6)

for horizontal lin eto. Equ ivalen t to dx 0 rlineto.

hmoveto dx hmoveto (22)

for horizontal m oveto. Equ ivalen t to dx 0 rmoveto.

hvcurveto dx1 dx2 dy2 dy3 hvcurveto (31)for horizontal-vertical curveto. Equivalent to dx1 0 dx2 dy2 0 dy3

rrcurveto. This command eliminates two arguments from an

rrcurveto call when th e first Bézier tan gent is ho rizon tal and th e

secon d Bézier tan gen t is vertical.

rlineto dx dy rlineto (5)

beh aves like rlineto in the PostScript language.

rmoveto dx dy rmoveto (21)

beh aves like rmoveto in th e PostScript language.

rrcurveto dx1 dy1 dx2 dy2 dx3 dy3 rrcurveto (8)

for relative rcurveto. Whereas the arguments to the rcurvetoop erator in th e PostScript language are all relative to th e current

point, the arguments to rrcurveto are relative to each other.

Equ ivalent to dx1 dy1 (dx1+dx2) (dy1 +dy2 ) (dx1+dx2+dx3) (dy1+

dy2 +dy3) rcurveto.

vhcurveto dy1 dx2 dy2 dx3 vhcurveto (30)

for vertical-h orizon tal curveto. Equivalen t to 0 dy1 dx2 dy2 dx3 0

rrcurveto. This command eliminates two arguments from anrrcurveto call when the first Bézier tangent is vertical and the

secon d Bézier tan gent is horizont al.

vlineto dy vlineto (7)

for vertical lineto. Equivalent to 0 dy rlineto.

vmoveto dy vmoveto (4)

for vertical moveto. This is equivalent to 0 dy rmoveto.

Hint Commands

dotsection – dotsection (12 0)

brackets an ou tlin e section for th e do ts in letters such as “i”,“ j”,

and “!”. Th is is a h int com m and th at indicates th at a section of a

charstring should be understood as describing such a feature,




rath er th an as part of th e m ain o utlin e. For m ore details, see sec-

tion 8.2, “Dot Section s,” in Ch apter 8, “Usin g Subro utin es.”

hstem y dy hstem (1)

declares th e vertical ran ge of a h orizon tal stem zon e (see th e fol-

lowing section for more information about horizontal stem

h ints) between th e y coordinates y an d y+dy, where y is relative t o

th e y coordinate of the left sidebearing point. Horizontal stem

zones within a set of stem hints for a single character may not

overlap other horizontal stem zones. Use hint replacement to

avoid stem hint overlaps. For more details on hint replacement,

see section 8.1, “Ch an gin g Hin ts With in a Ch aracter,” in Ch apter

8, “Using Subroutines.”

hstem3 y0 dy0 y1 dy1 y2 dy2 hstem3 (12 2)

declares the vertical ranges of three horizontal stem zones

between the y coordinates y0 an d y0 + dy0 , y1 an d y1 + dy1 , an d

between y2 an d y2 + dy2 , where y0 , y1 an d y2 are all relative toth e y coordinate of the left sidebearing point. The hstem3 com-

mand sorts these zones by the y values to obtain the lowest,

middle and highest zones, called ymin, ymid an d ymax respec-

tively. The correspon din g dy values are called dymin, dymid an d

dymax. These stems and the counters between them will all be

con trolled. These coordinates m ust ob ey certain restriction s:

• dymin = dymax

• The d ist ance from ymin + dymin /2 to ymid + dymid /2 must

equal th e distan ce from ymid + dymid /2 t o ymax + dymax /2. In

oth er words, the distance from th e cen ter of th e bottom stem

to th e cen ter of th e m iddle stem m ust be th e same as the dis-

tance from th e center of the m iddle stem to th e center of the

top stem .

If a ch arstring u ses an hstem3 comm and in the h ints for a char-

acter, the ch arstring m ust n ot u se hstem comm ands an d i t m ust

use the sam e hstem3 comm and consistently if hint replacemen t

is perform ed.

Th e hstem3 command is especially suited for controlling the

stems and counters of symbols with three horizontally oriented

features with equal vertical widths and with equal white space

between these features, such as the mathematical equivalence

symbo l or th e division sym bol.




vstem x dx vstem (3)

declares th e h orizon tal range of a vertical stem zon e (see th e fol-

lowing section for more information about vertical stem hints)

between the x coordinates x an d x+dx , where x is relative to t h e x

coordinate of the left sidebearing point. Vertical stem zones

with in a set of stem h ints for a single ch aracter may n ot overlap

other vertical stem zones. Use hint replacement to avoid stem

h int overlap. For m ore details on h int replacem ent , see section

8.1, “Ch an gin g Hin ts With in a Ch aracter,” in Ch apter 8, “Using

Subroutines.”

vstem3 x0 dx0 x1 dx1 x2 dx2 vstem3 (12 1)

declares the horizontal ranges of three vertical stem zones

between the x coordinates x0 an d x0 + dx0, x1 an d x1 + dx1, an d

x2 an d x2 + dx2, where x0, x1 an d x2 are all relative to t h e x coor-

din ate of th e left sidebearin g poin t. Th e vstem3 comm and sorts

these zones by the x values to obtain the leftmost, middle and

rightmost zones, called xmin, xmid an d xmax respectively. Thecorresponding dx values are called dxmin, dxmid an d dxmax.

These stems and the counters between them will all be con-

trolled. These coordinates must obey certain restrictions

described as follows:

• dxmin = dxmax

• The d ist ance from xmin + dxmin /2 to xmid + dxmid /2 must

equal th e distan ce from xmid + dxmid /2 t o xmax + dxmax /2. In

other words, the distance from the center of the left stem to

th e center of the m iddle stem m ust be the same as th e distance

from th e center of the m iddle stem to th e center of the right

stem.

If a ch arstring u ses a vstem3 comm and in th e hints for a charac-

ter, th e charstrin g m ust n ot u se vstem comm ands and i t mu st use

the same vstem3 command consistently if hint replacement is

performed.

Th e vstem3 command is especially suited for controlling the

stems an d coun ters of ch aracters such as a lower case “m .”

Arithmetic Command

div num1 num2 div (12 12) quot ient

beh aves like div in th e PostScript language.




Subroutine Commands

callothersubr arg1 . . . argn n othersubr# callothersubr (12 16) –

is a mechanism used by Type 1 BuildChar to make calls on the

PostScript interpreter. Arguments argn through arg1 are pushed

on to t h e PostScript interpreter op erand stack, and th e PostScript

lan guage procedure in th e othersubr# position in th e OtherSubrsarray in th e Private dictionary (or a built-in function equivalent

to th is procedure) is executed . Note that th e argum en t order will

be reversed wh en p ush ed on to th e PostScript in terpreter op erand

stack. After the arguments are pushed onto the PostScript inter-

preter op erand stack, th e PostScript interpreter performs a beginoperation on systemdict followed by a begin operat ion on the

font dictionary prior to executing th e OtherSubrs entry. Wh en

th e OtherSubrs entry completes its execution, the PostScript

interpreter performs two end operations prior to returning to

Type 1 BuildChar charstring execution. Use pop commands to

retrieve results from the PostScript operand stack back to the

Type 1 BuildChar operand stack. See Chapter 8, “Using Subrou-

tines,” for d etails on using callothersubr.

callsubr subr# callsubr (10) –

calls a charstring subroutine with index subr# from the Subrsarray in th e Private diction ary. Each elemen t of th e Subrsarray is

a charstring encoded and encrypted like any other charstring.

Argum ent s pu shed o n th e Type 1 BuildCh ar operand stack prior

to callin g th e subroutine, and results pushed on th is stack by the

subroutine, act according to th e man n er in wh ich th e subroutin e

is coded. These subroutines are generally used to encode

sequences of path commands that are repeated throughout the

font program, for example, serif outline sequences. Subroutine

calls m ay be n ested 10 d eep. See Ch apter 8, “Usin g Sub rout ines,”

for oth er uses for subrout ines, such as ch an gin g hin ts.

pop – pop (12 17) number

remo ves a nu m ber from th e top of th e PostScript in terpreter op er-

and stack and pushes that number onto the Type 1 BuildChar

operand stack. This command is used only to retrieve a result

from an OtherSubrs procedu re. For m ore details, see Ch apter 8,

“Using Subroutines.”

return – return (11) –

returns from a Subrs array charstring subroutine (that had been

called with a callsubr comm and) and con t in ues execut ion in th e

calling charstring.




setcurrentpoint x y setcurrentpoint (12 33)

sets the current point in the Type 1 font format BuildChar to

( x, y) in absolute ch aracter space coord inates with ou t performin g

a charstrin g moveto comm and . Th is establish es the curren t p oint

for a subsequent relative path building command. The

setcurrentpoint command is used only in conjunction with

results from OtherSubrsprocedures.

6.5 Character Level Hints

With in a ch aracter, fon t program develop ers can ad d d eclarative

h ints to in dicate to Type 1 BuildCh ar th at a h orizon tal or vertical

stem occurs between certain coordinates. These same hints are

used to indicate stem-like round features, such as the leftmost,

rightm ost, topm ost, an d b ottom -m ost parts of th e letter “o”. It is

important to communicate to Type 1 BuildChar exactly where

such features occur so that it can apply special techniques to

th ese parts of the ou tlin e.

Th e vstem hint, for each vertical stem (such as the legs of the

letter “n” or th e leftm ost and righ tm ost section s of th e letter “o”)

takes two x values (expressed as x an d delta-x) as argum en ts. Th ese

two x values ind icate th e h orizon tal range th at th e vertical stem’s

width occupies in character space. Similarly, the hstem h int, for

each horizontal stem (such as the arms of the letter “E” or the

topmost and bottom-most sections of the letter “o”) takes two y

values (expressed as y an d delta-y) that ind icate th e vertical ran ge

th at th e ho rizon tal stem ’s width occupies in ch aracter space. Th e

vstem an d hstem h in ts are called stem hints; th ey are typically th em ost n um erous hints in a fon t program.

Stem hint zones of the same direction (e.g. two hstem hints)

shou ld no t overlap each oth er with in a character. See section 8.1,

“Ch an gin g Hin ts With in a Ch aracter,” in Ch apter 8, “Using Sub-

routines,” for a description of how to use hint replacement to

avoid stem h int overlaps.




Figure 6a. Character level stem hints (horizontal, vertical, and ghost

stem hints)

Some hstem hints are necessary for interaction with the align-

ment zones declared through the BlueValues an d OtherBluesh in ts. In order for a ch aracter’s vertical features to be con sidered

for alignment control, that character must have an hstem hin tspecified at or in an alignm ent zon e. In som e ch aracters th is h ap-

pens naturally. For example, in a capital letter “E,” there are at

least th ree hstem hints declared for the three horizontal stems.

The top stem ’s hstem h int shou ld reach up to t h e cap-h eight, and

th e bottom stem’s hstem h in t sh ould extend down to th e base-

line. These two hstem hints interact naturally with normal

align m ent zones.

In a sans serif capital letter “I”, however, there are no horizontal

stems for th ese hstem h ints. In order to have th e cap-h eight an d

baselin e alignm en ts apply to th is character as well, th e characterneeds hstem hints for non-existent horizontal stems at these

positions also. These so-called “ghost” stems must be created

with a stem h eigh t of 20 o r 21—either is acceptable. Th ey m ust

describe a y coordin ate ran ge th at is inside the y coordin ate range

of the character, not above a top n or below a bottom .

An hstem h int m ay not h ave its top at or in a top-zone and have

its bottom at or in a bottom-zone. In the capital “I” example,

th ere can n ot be just one hstem hint that stretches from baseline

to th e cap-height l in e; instead on e hstem sh ould be at th e cap-

h eight an d an oth er should be at th e baseline.

hstem

vstem

hstem

hstem

vstem

vstem

hstem

hstem

hstemhstem

Horiz on tal an d vertical stem s Gh ost stem s




6.6 Encoding Example

To illustrate th e com position an d en codin g of a charstrin g, con -

sider the following example of a block letter “C”. In character

space this letter m easures 700 un its by 700 un its. Its width is 800

units (horizontal), and it is centered within this width; thus its

left sidebearing is 50 un its wide. Each stem is 100 u n its wide. This

example shows how to declare these stem widths as characterlevel h ints.

The charstring definition begins by writing an outline in the

PostScript language in character space integer coordinates:

50 0 moveto 700 0 rlineto 0 100 rlineto -600 0 rlineto

0 500 rlineto 600 0 rlineto 0 100 rlineto -700 0 rlineto

closepath

Next, add sidebearing, width and hint information. Since the

moveto comm and is n ot in th e ch arstrin g com m and set, chan ge

it to rmoveto, taking advantage of the hsbw com m an d’s settin g

of Type 1 BuildCh ar’s curren t p oin t. Note th at th e vstem an d

hstem argum en ts are relative to th e left sidebearing p oin t.

50 800 hsbw 0 100 vstem 0 100 hstem 600 100 hstem

0 0 rmoveto 700 0 rlineto 0 100 rlineto -600 0 rlineto

0 500 rlineto 600 0 rlineto 0 100 rlineto -700 0 rlineto

closepath

Th e initial rmoveto command (or its equivalent) is required, as

th e hsbw comm and o n ly sets th e current poin t but does not actu-

ally place th at point in th e character path. In th is example, th e

first p oint on th e path is th e sam e as the left sidebearing poin t,

th us the two zero argum ents to the rmoveto comm and. In other

character outlines, the initial rmoveto point need not be the

same as th e left sidebearin g poin t.

Note that there are many horizontal and vertical rlineto com-

m and s. Modify them to hlineto an d vlineto comm and s for space

efficiency. Finish the character with an endchar command.

50 800 hsbw 0 100 vstem 0 100 hstem 600 100 hstem

0 hmoveto 700 hlineto 100 vlineto -600 hlineto

500 vlineto 600 hlineto 100 vlineto -700 hlinetoclosepath endchar




En code th e integers according to charstrin g n um ber encoding:

189 249 180 hsbw 139 239 vstem 139 239 hstem 248 236 239 hstem

139 hmoveto 249 80 hlineto 239 vlineto 252 236 hlineto

248 136 vlineto 248 236 hlineto 239 vlineto 253 80 hlineto

closepath endchar

En code th e com m and s accordin g to ch arstrin g com m and en cod-

ing:

189 249 180 13 139 239 3 139 239 1 248 236 239 1

139 22 249 80 6 239 7 252 236 6

248 136 7 248 236 6 239 7 253 80 6

9 14

For pu rposes of illustrating th is examp le, th is sequ en ce of n um -

bers is rewritten in ASCII h exadecim al, and shown as a sequ ence

of PostScript lan guage code:

/ C <BDF9B40D8BEF038BEF01F8ECEF01

8B16F95006EF07FCEC06F88807F8EC06EF07FD5006

090E> def

All that remains is to apply charstring encryption to this hexa-

decimal-en coded bin ary string, and th is charstrin g is com plete.

Remember that the actual format required by Type 1 BuildChar

is n ot t h is ASCII h exadecim al form of charstrin g, but th e binary

form of the charstrin g in th e following m ann er:

/C 37 RD ~37~binary~bytes~ ND



61

CHAPTER7

Type 1 font p rograms in corporate two types of en cryption : char-

string encryption and eexec encryption.

Th e en coded charstrin gs are en crypted first. Th is level of en cryp-

tion is called charstring encryption; Type 1 BuildChar works only

with en coded an d en crypted charstrin gs. A section o f the Type 1

font program, in cludin g the Private an d CharStringsdictionaries,is again encrypted using an oth er layer of encryption called eexec

encryption. Th is layer of en cryption is inten ded to protect som e of

the hint information in the Private dictionary from casual

inspection, an d it coin ciden tally provides an ASCII h exadecim al

form of this part of the font program so that it can be passed

th rough comm un ication chan n els that accept on ly 7-bit ASCII.

7.1 Encryption Method

Both eexec and charstrin g en cryption emp loy the same en cryp-

tion m ethod . Th is m ethod is a com bination of three techn iques.

• A pseudo-random n um ber gen erator generates a sequence of

keys that are combined with the plaintext to produce the

ciphertext.

• Ciph er feedback is emp loyed in th e generation of th ese keys;

in other words, each byte of ciphertext is used in the produc-

tion o f the n ext key.

• Each plain text sequen ce h as a semi-rando m sequence of bytes

inserted at th e beginn ing, so th at repeated encryption of the

sam e plaintext will prod uce differen t ciph ertexts.

Encryption




The following algorithms for encryption and decryption are

nearly identical, but they differ subtly because it is always the

ciph ertext byte th at is used to generate th e n ext key. It is neces-

sary to use two separate procedures to handle encryption and

decryption.

To Encrypt a Sequence of Plaintext Bytes to Produce aSequence of Ciphertext Bytes

1. Generate n random bytes to be additional plaintext bytes at

the beginning of the sequence of plaintext bytes, for some

value o f n.

2. Initialize an u n signed 16-bit int eger variable R to the encryp-

tion key.

3. For each 8-bit byte, P, of plaintext (beginning with the newly

added ran dom bytes) execute th e followin g steps:

a. Assign th e high order 8 bits of R to a tem porary variable, T .

b. Exclusive-OR P with T , produ cin g a ciph ertext byte, C .

c. Compute the next va lue of R by th e form ula ((C + R) × c1 +

c2) mod 65536, where c1 is 52845 (decim al) an d c2 is 22719

(decimal).

This encryption step can be performed by the following C lan-

guage program , where r is initialized to th e key for th e encryption

type:

unsigned short int r;

unsigned short int c1 = 52845;


unsigned char Encrypt(plain) unsigned char plain;

{unsigned char cipher;

cipher = (plain ^ (r>>8));

r = (cipher + r) * c1 + c2;

return cipher;

}



Chapter 7: Encryption 63

To Decrypt a Sequence of Ciphertext Bytes to Produce theOriginal Sequence of Plaintext Bytes

1. Initialize an u n signed 16-bit int eger variable R to the encryp-

tion key (th e sam e key as used to en crypt).

2. For each 8-bit byte, C , of ciph ertext th e followin g steps are exe-

cuted:

a. Assign th e high order 8 bits of R to a tem porary variable, T .

b. Exclusive-OR C with T , produ cin g a plain text byte, P.

c. Compute the next va lue of R by th e form ula ((C + R) × c1 +

c2) m od 65536, where c1 an d c2 are th e same con stants th at

were used to en crypt.

3. Discard th e first n bytes of plaintext; these are the random

bytes added d uring en cryption. The rem ain der of th e plain text

bytes are the o rigin al sequen ce.

The decryption step can be performed by the following C lan-

guage program , where r is initialized to th e key for th e encryption

type:

unsigned short int r;



unsigned char Decrypt(cipher) unsigned char cipher;

{unsigned char plain;

plain = (cipher ^ (r>>8));

r = (cipher + r) * c1 + c2;return plain;

}

7.2 eexec Encryption

In eexec encryption, the initial key for the variable R is 55665

(decimal). The number of random bytes, n, is 4.

Th e eexec operator is capable of decryptin g in pu t in eith er bin ary

or ASCII hexa decim al form . There are several restriction s:

• To distinguish between bin ary and ASCII h exadecim al inpu t,

the first 4 ciphertext bytes must obey certain restrictions.

Rem em ber th at tw o ASCII h exadecim al characters represen t 1

ciphertext byte, while 1 binary byte represents 1 ciphertext

byte.




• Th e first ciph ertext byte must no t be an ASCII wh ite space

character code (blank, tab, carriage return or line feed).

• At least on e of the first 4 ciph ertext bytes must not be on e of

th e ASCII hexadecim al character codes (a code for 0-9, A-F, or

a-f). These restrictions can be satisfied by adjusting the initial

rand om plaintext bytes as n ecessary.

If th e eexec-encrypt ed text is supp lied in b inary form, th en every

byte is con sidered part of th e ciph ertext. If the eexec-encrypted

text is supplied in ASCII hexadecimal form, then ASCII white

space ch aracters (blank, tab, carriage return an d lin e feed) m ay be

freely interspersed within the encrypted text, except in the first

eigh t characters.

Note It is possible not to use eexec encryption; however, part of the file would

then be in binary, and m ight cause difficulty when transferring the font

program over a comm unications line.

7.3 Charstring Encryption

In ch arstring en cryption , th e initial key for th e variable R is 4330

(decimal). Th e nu m ber of rand om bytes, n, is set within th e fon t.

By default, n is 4. However, if an entry name lenIV is present in

th e Private dictionary, then n is the value associated with lenIV.

(Version 23.0 of th e PostScript in terpret er requires n to be 4.)

Unlike eexec encryption, charstring encryption imposes no

restriction s on th e values of th e initial ciph ertext bytes.

A continuation of the encoding example in section 6.6 shows

how the charstring can be encrypted. Recall that the charstring

looked like

BDF9B40D8BEF038BEF01F8ECEF018B16F9

5006EF07FCEC06F88807F8EC06EF07FD5006090E

in ASCII hexadecimal notation. These 74 ASCII hexadecimal

characters represent 37 plaintext bytes of charstring. Generate

four ran dom plain text bytes to in sert at th e front of this plaintext

ch arstring. Th is exam ple uses four zeros (for ease of exp lanation ),resulting in t h is plaintext:

00000000BDF9B40D8BEF038BEF01F8ECEF018B16F9

5006EF07FCEC06F88807F8EC06EF07FD5006090E



Chapter 7: Encryption 65

App ly charstrin g encryption to pro du ce th e followin g 41 bytes of

ciph ertext exp ressed in ASCII h exadecim al:

10BF31704FAB5B1F03F9B68B1F39A66521B1841F14

81697F8E12B7F7DDD6E3D7248D965B1CD45E2114

When this encoded and encrypted charstring is expressed in

binary form, it is ready for inclusion in a Type 1 font program.Th e ch arstring wou ld be inserted in t h e CharStringsdiction ary as

follows:

/C 41 RD ~41~binary~bytes~ ND

If eexec encryption is to be used, it still remains to be applied

over th e whole of th e Private an d CharStrings dictionaries. This

example does not sh ow th is addition al en cryption step.



67

CHAPTER8

A Type 1 fon t p rogram uses two arrays of subrout ines, Subrsan d

OtherSubrs. Uses for subroutines include:

• Reducin g the storage requirements of a fon t program by

combin ing the program statem ents that d escribe comm on

elemen ts of the ch aracters in th e font.

• Subrs0 th rough 2 work with th e Flex feature.

• Subrs3 works with h int replacemen t.

• Subrs4 an d h igh er work with charstrin g calls.

• OtherSubrs0 th rough 2 imp lem ent th e Flex feature.

• OtherSubrs3 im plem ents hin t replacemen t.

Th e Subrs array contains sections of outlines encoded anden crypted as charstrin gs, an d, wh en h int replacem ent is required,

sequences of stem hint commands. When a font contains

repeated elem en ts, such as serifs, equ al sized bowls, an d so forth ,

th ey may be can didates for charstrin g subro utin es.

Note that the charstring command set includes only relative

forms of path building commands. For example, rmoveto an d

rlineto are included, but moveto an d lineto are n ot. Usin g rela-

tive motion commands facilitates the reuse of subroutines for

sections of character outlines, regardless of their absolute place-

m ent with in th e ch aracter.

An element of the Subrs array is a charstring, encoded and

encrypted separately in the same way as charstrings in the

CharStrings dictionary. A charstring subroutine must end with

th e return command. These subroutines are called with the

Using Subroutines




callsubr comm and, usin g the in dex in the Subrsarray as th e argu-

ment. Charstring subroutines may call other subroutines, to a

dept h of 10 calls.

Using charstring subroutines is not a requirement of a Type 1

font program . However, th eir use con tributes greatly to redu cin g

storage space.

Th e Ado be® Type Library u ses th e OtherSubrs m ech anism for the

hint replacement function and the Flex function. These

OtherSubrs procedures work by using some coordinated Subrsentries as well. All Adobe Type 1 font programs that use these

functions use them in precisely the same way. As a result, the

sem an tics of th e PostScript language procedures in clud ed in th e

OtherSubrsarray h ave stabilized to th e poin t wh ere th e first four

OtherSubrs entries and the first four Subrs entries have fixed

meanings. Some Type 1 font rasterization programs such as the

Adob e Type Man ager software produ ct ignore t h e PostScript lan-

guage definitions of the OtherSubrs entries, choosing internalcode for the particular functions according to the entry number.

However, in order to work with the Type 1 BuildChar in Post-

Script interpreters, som e PostScript language im plemen tation of

th e OtherSubrsen tries m ust be in clud ed in an y Type 1 fon t pro-

gram that uses these functions. The PostScript language code

used in Adobe Type 1 font programs is listed in Appendix 3,

“OtherSubrs Programs.”

OtherSubrs entries beyond the first four are reserved for future

exten sion s. Each n ew OtherSubrs en try will be design ed so th at

it can b e safely treated by an interpreter th at does no t un derstandits semantics. However, the first four OtherSubrs entries cann ot

be so ignored; igno ring th em w ill result in im prop er execution o f

the charstring.

An OtherSubrs entry is invoked by th e callothersubr command.

Th is com m an d takes (from th e top of th e Type 1 BuildCh ar oper-

and stack down) the in dex nu m ber of th e OtherSubrsentry, th e

n um ber of argum ents th at entry expects, and th e actual nu m eric

arguments.

Th e com plete callin g sequ ence for an OtherSubrsprocedure is:

arg1 arg2 . . . argn n othersubr# callothersubr pop . . . pop



Chapter 8: Using Subroutines 69

Th e pop com m an ds followin g th e sub routin e call tran sfer results

from th e PostScript operan d stack to th e Type 1 BuildCh ar oper-

and stack. Th e nu m ber of pop comm and s following th e call m ay

not exceed the number of arguments, n . Th e pop comm ands, if

any, must immediately follow the callothersubr command with

n o interven ing comm ands.

If the entry number, othersubr# , is not one that a Type 1 fontinterpreter recognizes, then the results for the pop commands

must be taken from the arguments. In this case, the first popcomm and receives arg1, the secon d pop comm and receives arg2 ,

etc., with extra arguments discarded. If the Type 1 font inter-

preter has access to a PostScript language interpreter, it can

invoke the OtherSubrs entry with the arguments as described

under the callothersubr command, and the pop commands, if

an y, receive th eir values from th e PostScript operan d stack. In an y

case, th e first four OtherSubrsentries mu st be h and led according

to th eir seman tics as defin ed in th is docum ent.

8.1 Changing Hints Within a Character

Th e stem h ints, vstem an d hstem, affect th e treatmen t of all sub-

sequent coordinates in a charstring. Occasionally a character

outline may require certain stem hints for some part of its out-

lin e, but d ifferent stem h int s for ot h er parts of its out lin e. After

executing the coordinate commands for the current set of stem

h ints, these h ints m ay be discarded an d n ew stem h ints given in

mid-outline.

To discard old stem hints and insert new ones, the new stem

hints must be placed in a charstring subroutine in the Subrsarray. This subroutine may be placed at any index in the Subrsarray except 0 through 3. Call this subroutine index subr# . This

subrout ine must contain only stem hint commands and their

argum ents. Th en, at th e point in th e ch aracter outlin e where the

old h ints are discarded an d th e new on es inserted, insert the fol-

lowing charstrin g sequen ce:

subr# 1 3 callothersubr pop callsubr

This sequence of code operates as follows. Entry 3 in the Other-Subrs array is called with on e argum ent, th e entry in th e Subrsarray that con tain s th e new hint com m and s. Th e subr# is pu shed

on to t h e PostScript interpreter op erand stack, and th e PostScript

interpreter executes th e h int-chan gin g procedure. Th e earliest




versions of the PostScript interpreter are not capable of dis-card-

ing h ints in m id-outlin e, so th e hin t-chan gin g procedure checks

if the PostScript interpreter is capable of performing this action.

If so, it leaves subr# on th e PostScript int erpreter operand stack. If

n ot, i t removes subr# and i t pushes the n um ber 3 on the operan d

stack. Back in the charstring, the pop command transfers the

number (either 3 or subr# ) from th e PostScript int erpreter oper-

and stack to the Type 1 BuildChar operand stack. Finally thissubrout ine is called by t h e callsubr command.

En try 3 in th e Subrsarray is a charstrin g th at does no th ing. If th e

Type 1 BuildCh ar version is n ot capable of discardin g old h ints in

m id-outlin e, th en th is m ech anism ign ores th e new hin ts.

In ch arstring en codin g (decimal) th e above code sequ ence (with

the en codin g of subr# sh own as enc(subr#)) is:

enc(subr#) 140 142 12 16 12 17 10

Figure 8a. Changing hints within a character definition

Specifically, for th e “E” sh own in Figure 8a, th e charstrin g defin i-

tion would con sist of th e charstrin g com m and s in th e following

example. Note where hint replacement is performed because of

th e overlappin g hstem h ints for th e serifs and stem s. (Th e stem

h ints for the serifs are narrower th an th ose for th e stem s.)

vstem

hstem

vstem

vstem

hstem

hstem

vstem

hstem

hstem

Hints for f irst port ion of path Hints for second port ion of path




Example 1.

40 575 hsbw Set left sidebearing point and width

0 32 hstem Stem hint for bottom stem

350 32 hstem Stem hint for middle stem

668 32 hstem Stem hint for top stem

421 36 vstem Stem hint for top vertical serif

359 26 vstem Stem hint for middle vertical serif

86 97 vstem Stem hint for main vertical stem 0 hmoveto Move to first point in character path

% ...commands omit ted... Define first portion of character path

4 1 3 callothersubr pop callsubr Change hints

% ...commands omit ted... Define second portion of character

path with new hints in place

closepath Close character path

endchar End charstring outline definition

Subroutine index number 4 in the Subrs array contains the fol-

lowin g charstrin g sequen ce for defin ing n ew stem h ints:

0 26 hstem Stem hint for bottom serif 674 26 hstem Stem hint for top serif

86 97 vstem Stem hint for main vertical stem

return Return to charstring execution

8.2 Dot Sections

In older PostScript interpreters not capable of performing hint

replacem en t, a special feature was em ployed for d ot sections of a

character outline. These dot sections occur in letters such as “i”,

“j”, an d “!”. Occasion ally, th e h ints for ch aracter stems an d align -

ment zones would interact poorly with these dots. Today, thesefeatures are best h an dled by h int replacem ent as described abo ve.

How ever, for com pat ibility with o lder PostScript int erpreters and

older Type 1 font programs, the dotsection hint remains avail-

able, and current font programs still use dotsection for

com patibility with th e oldest PostScript int erpreters.

Th e dotsection h int com m and m ust be used in pairs at particular

places in the charstring. The first dotsection comm and should

occur imm ediately after the first rmoveto th at begin s th e dot sec-

tion of a character. Th e secon d dotsection comm and should be

given im m ediately after th e closepath th at finish es th e dot.




Here is an example of how dotsection commands should be

placed in a comm and sequ ence. Th is dot section sequen ce con -

sists of four rrcurveto commands:

. . . 0 120 rmoveto dotsection

0 -55 45 -45 55 0 rrcurveto 55 0 45 45 0 55 rrcurveto

0 55 -45 45 -55 0 rrcurveto -55 0 -45 -45 0 -55 rrcurveto

closepath dotsection . . .

8.3 Flex

Very shallow cu rves that are n early h orizon tal or n early vertical

in o rien tation are especially difficult to app roximat e on a digital

device. Examples of such curves include cupped serifs and

tapered stems. These features can be controlled with the Flex

m ech anism , which uses OtherSubrsen tries 0, 1, and 2.

Th e m ain idea beh ind Flex is th at at small sizes sligh t h um ps an d

dents in an outline should disappear, while at larger sizes theyshould appear. Without Flex, a hump or a dent will be rendered

proportionately too large at small sizes to look right. These fea-

tures should appear when the subtle effect expected can be

rend ered app ropriately.

A particular curve sequence is a candidate for Flex only if the

arrangem ent of points on th at curve m eets certain con dition s.

• Th e sequence m ust be form ed by exactly two Bézier curve seg-

ments.

• The outer endpoints mu st be a t the same x (or y) coordinate;

in o th er words, they m ust be p recisely vertical or h orizon tal.

• The join in g endpoint between the two curves and th e control

points associated with this endpoint must all be positioned at

the horizontal (or vertical) extreme of the double curve sec-

tion. The joining point need not be equidistant from the

endpoints of the double curve section.

• The diffe rence in x (or y) coordinates between an outer end-

point and the center (joining) endpoint (the flex height ) mustbe 20 u n its or less.




Figure 8b. Appropriate and inappropriate curves for the Flex

mechanism

For best results on cupped serifs (and any other shallow curves

th at l ie with in an align m ent zon e), the joining (center) en dpoin t

shou ld be position ed precisely at th e “flat” edge of th e align m en t

zone.

horizontal alignment

verticalalignment

Correct Correct

Incorrect Incorrect

4 curve segments

Incorrect Incorrect

>20 units

not preciselyvertical

x=70

x=110




Figure 8c. Position joining endpoint at flat edge of alignment zone

Flex features must be coordinated with the Private dictionary

BlueShift value. Th e BlueShift value m ust be larger than th e m ax-

imu m Flex feature h eight . Since th e default value of BlueShift is

7, th is en try m ust be set explicitly if the m aximu m Flex feature

h eight is mo re than 6. For examp le, if th e maxim um Flex feature

h eight is 8, th en set BlueShift to 9. If th e m aximu m Flex featureheight is 6 or less, the BlueShift entry m ay be om itted.

Figure 8d. Set BlueShift value to maximum Flex feature height plus 1

The Flex mechanism chooses whether the two Bézier curves

should be used as defined, or whether a straight line segment

between the two outer endpoints should be used instead. The

method calculates whether the height of the Flex feature in

device space is less th an a h eigh t con trol param eter. If so, th en

th e two curves are replaced by a single straigh t line segmen t. If n ot, th e curve points are adjusted so th at th e curve features will

be ren dered ap prop riately.

Correct Incorrect

cap-height: 700

alignment zone

cap-height: 700

alignment zone

cap-heightovershootposition: 715


BlueShift

flex-height: 8

cap-height: 700

value set to 9 BlueShift should be left out

flex-height: 5

cap-height: 700






To encode two Bézier curve segments for Flex, several changes

must be made in the charstring. The following is an algorithm

th at accom plish es th ese ch an ges.

1. Note the coordinates of the curren t poin t in ch aracter space

wh ere the first curve begins. Call th is th e starting p oin t.

2. Com pute th e relative distance from th e startin g point to a ref-

erence point. For horizontally oriented curves, the reference

point will have the same x coordin ate as the join ing point an d

the sam e y coordin ate as th e startin g po int. For vertically ori-

ented curves, the reference point will have the same y

coordinate as the joining point and the same x coordinate as

th e startin g point.

3. Remove the two rrcurveto commands, leaving six coordinate

values (12 n um bers).

4. Recomp ute th e coordin ates of the first pair to be relative to th e

referen ce point .

5. In sert at the beginn ing of th e sequence the coordin ate of th e

reference point relative to the starting point. There are now

seven coord inate values (14 nu m bers) in th e sequen ce.

6. Place a call to Subrs entry 1 at th e beginn ing of this sequen ce

of coordinates, and place an rmoveto command and a call to

Subrs entry 2 after each of the seven coordinate pairs in the

sequence.

7. Place the Flex h eight control parameter and th e fin al coordi-

nate expressed in absolute terms (in character space) followed

by a call to Subrsentry 0 at the end.




Figure 8e. Calculat ing Flex

For example, consider a section of PostScript code that defines

two Bézier curves that m eet th e requ iremen ts for Flex. See Figure8e. Th is ou tlin e section begin s at th e poin t (100, -10) (in absolute

ch aracter space; relative to t h e character space origin ) and is to be

included in a fon t wh ose baseline is at zero.

100 -10 moveto

115 -10 125 0 150 0 curveto

175 0 185 -10 200 -10 curveto

Th e Flex h eight is 10, th e con trol poin ts closest to th e cen ter end -

poin t are at th e same y coordin ate, and th e two end points are at

the sam e y coordin ate. Th us, th is sequ en ce of two curves begins

at (100, -10), joins at (150, 0) an d en ds at (200, -10). Furth ermo re,th e join ing coordin ate is at the same y coordin ate as th e baseline.

This outline fragment can be expressed with rrcurveto com-

m an ds suitable for in clusion in a ch arstring as follows:

15 0 10 10 25 0 rrcurveto

25 0 10 -10 15 0 rrcurveto

To con vert th is charstrin g fragmen t to t h e Flex form, rem ove th e

rrcurveto comm and s and recom pute th e coordinates of the first

pair to b e relative to th e referen ce poin t (150, -10):

-35 0 10 10 25 0 25 0 10 -10 15 0

(100,-10) (115,-10)

(125,0)

(150,0)

(175,0)

(185,-10) (200,-10)

joining point

starting point

reference point

end point(150,-10)




Insert th e coordinat e of the reference poin t, relative to th e start-

ing poin t, at th e beginn ing of th is sequen ce an d start with a call

to th e Sub rs en try 1:

1 callsubr 50 0 -35 0 10 10 25 0 25 0 10 -10 15 0

Add th e rmoveto comm and s an d calls to Subrsentry 2:

1 callsubr50 0 rmoveto 2 callsubr

-35 0 rmoveto 2 callsubr

10 10 rmoveto 2 callsubr



10 -10 rmoveto 2 callsubr


Add the final parameters and call to Subrs entry 0. The first

number declares the size (in hundredths of a device unit) of the

rend ered Flex h eight at wh ich th e two curves will be expressed as

curves rath er th an as a straigh t line. For cup ped serifs or oth er fea-

tures that interact with overshoot zones, 50 (or one-half of a

device pixel) sh ou ld be u sed for th is con trol param eter. Th us, if

th e Flex h eight ren ders to 50 h un dredths of a pixel or more, the

curves will be u sed; if less, a straight line will be used. Th e secon d

and th ird n um bers are the fin al coordinate expressed in absolute

terms in character space (relative to the character space origin).

In th is examp le, they are 200 an d -10:

1 callsubr


-35 0 rmoveto 2 callsubr10 10 rmoveto 2 callsubr



10 -10 rmoveto 2 callsubr


50 200 -10 0 callsubr

In th is examp le, th e Flex feature h eight is 10. If th is is th e m axi-

mum Flex feature height for the entire font, then the value of

BlueShift shou ld be set to 11.




8.4 First Four Subrs Entries

If Flex or h int replacem ent is used in a Type 1 fon t program , th e

first four en tries in th e Subrsarray in th e Private dictionary m ust

be assigned charstrings that correspond to the following code

sequ ences. If n eith er Flex n or h int replacemen t is used in th e fon t

program, then this requirement is removed, and the first Subrs

en try m ay be a n orm al charstrin g subro utin e sequen ce. Th e firstfour Subrsentries contain:

Subrsentry num ber 0:

3 0 callothersubr pop pop setcurrentpoint return


0 1 callothersubr return


0 2 callothersubr return


return

These code sequences must be encoded and encrypted via char-

string encryption in accordance with the rest of the font

program . Th ey must th en be included in th e program using the

RD–NP format.

Th e Subrs entries 1 and 2 are merely abbreviations for callingOtherSubrsentries. This saves two charstring bytes on each call.

Subrs entry 3 does nothing; it is used when Type 1 BuildChar

cannot perform hint replacement. Subrs entry 0 passes the final

th ree argum ents in th e Flex m ech anism into OtherSubrsentry 0.

That procedure puts the new current point on top of the Post-

Script interpreter operand stack. Subrs entry 0 then transfers

these two coordinate values to the Type 1 BuildChar operand

stack with two pop comm ands and m akes them the current point

coordinates with a setcurrentpoint command.



79

CHAPTER9

Because Type 1 fon ts are PostScript lan guage program s, their con -

tents have sometimes been arranged in more complicated ways

than already described. This chapter describes two special forms

that have been used in Adobe Type 1 font programs: synthetic

an d h ybrid fon ts. Type 1 fon t p arsers must be able to recognize

these forms correctly. This chapter is intended primarily for

people who are parsing an existin g Type 1 font p rogram an d ren -dering it.

9.1 Synthetic Fonts

A synthetic font is a fon t program th at is a m odification of an oth er

font program by means of a different transformation matrix.

Obliqu ed, expan ded, and cond ensed fon ts are exam ples of fon ts

that may be constructed as synthetic fonts. True italic faces and

high-quality compressed and expanded faces should have com-

pletely new character outlines. However, a synthetic font

program may sometimes work almost as well, at typically large

savin gs in PostScript in terpreter VM u sage.

A synthetic font program associates its CharStrings dictionary

entry with the CharStrings dictionary from a font program

already loaded in th e PostScript in terpreter’s VM. Th us, th e add i-

tion al storage required for th e syn th etic fon t p rogram is on ly for

its font dictionary; the large CharStrings dictionary is shared

with t h e “basic” fon t program . A syn th etic font p rogram n eeds its

own UniqueID n um ber, so it m ust construct its own Private dic-

tion ary. Th is diction ary m ust be a clon e of the basic fon t’s Privatediction ary except for th e UniqueID entry.

Special FontOrganizations




Practically, ho wever, th ere is no guaran tee th at th e basic fon t pro-

gram for a particular synthetic font will actually be in VM when

th e synt h etic font is loaded. Th us, a synt h etic font m ust cont ain

a copy of the basic font program. The algorithm contained in

PostScript language code in t h e synth etic fon t p rogram checks for

th e existence of th e basic font p rogram in th e FontDirectory dic-

tion ary in th e PostScript int erpreter. It also ch ecks to see th at th e

basic font has a FontType equal to one, and if the UniqueID iskno wn , th at it is th e sam e as th at of th e synt h etic font. If th ese

conditions are met, then the synthetic font proceeds to discard

the basic font it contains (by using readstring on itself), and it

copies th e CharStringsdiction ary from th e pre-existin g basic fon t

program. If the basic font program doesn’t exist, then the syn-

thetic font program executes the basic font it contains and

con structs itself as before. In th is secon d case, two fon t diction ar-

ies, th e basic font and th e syn th etic font, are created in VM rather

than only the synthetic font being created.

The method for checking whether a basic font dictionary existsuses th e known operator on th e FontDirectory diction ary. A syn -

th etic font p rogram m ust use the token “Fon tDirectory” after the

first occurren ce of th e token “/Private”. This first occurren ce will

take place where the synthetic font program defines its Privatedictionary, not where the embedded basic font program defines

it s Private dictionary.

9.2 Hybrid Fonts

A hybrid font is a font p rogram th at con tains two sets of outlin es.

One set of outlines is chosen according to the resolution of the

device on wh ich th e fon t is being used. Hybrid fon t program s are

typically used for typeface designs with subtle curves that are

beyon d th e Flex mech an ism ’s capabilities. At h igh resolution s a

set of outlin es with full fidelity to th e design is used; at low reso-

lution s a set of out lines with straight er edges is used. An exam ple

of a hyb rid font program in t h e Ado be Type Library is Optim a*.

In a h ybrid font p rogram, th e Subrs entries an d th e CharStringsen tries occur several tim es. All th e Subrsent ries for th e set of ou t-

lin es in ten ded for low-resolution rendering occur in a group as in

a n orm al Type 1 font program; th ese are followed by all the Subrsentries for high-resolution rendering. These groups are separated

by PostScript language code that checks resolution and that



Chapter 9: Special Font Organizat ions 81

ign ores on e of th e groups by m eans of save an d restore operators.

Th e CharStrings ent ries (wh ich occur last in th e fon t program as

always), are grouped an d selected in t h e same way.

The PostScript language code that checks the resolution of the

output device sets a value in an identifier named hires. If the

token “hires” occurs in a Type 1 font program prior to the first

occurrence of “/Subrs”, it must be a hybrid font program in theform described above.



83

CHAPTER10

There are Type 1 font program interpreters, such as in Adobe

Type Manager software, that do not incorporate a complete

PostScript in terpret er. Th is kind of Type 1 fon t ren derin g software

parses th e Type 1 fon t pro gram in a particularly simp le fashion .

Type 1 fon ts m ust strictly con form t o th ese parsin g rules in add i-

tion to being legal PostScript language programs. The example

font p rogram shown in Ch apter 2, “Fon t Program O rganization,”exh ibits the prop erties th at a Type 1 fon t program m ust h ave.

Simp lified parsers can separate th e inp ut text of a Type 1 fon t pro -

gram into tokens according to PostScript language rules as

defined in the PostScript Language Reference Manual. (Comments

and binary contents of charstrings are ignored when looking for

tokens.) Simplified parsers can check tokens occurring at “top

level” (not contained within procedure bodies) for certain key-

words, th en take specific action s based on th ose keywords.

• In dividual token s and charstrings may not exceed 65,535 char-acters in length .

• Most keywords are nam es th at are associated with values in a

dictionary; the initial portion of a Type 1 font program is

assumed to contain names to be inserted in the font

dictionary.

• If t he keyw ord eexec appears, th en th e text following m ust be

encrypted. No assignments of values to names may occur in

th e plain text th at follows th e encrypted portion.

• All font dictionary assignm ents (except for CharStrings an d

Private) m ust take place before th e first o ccurren ce of th e key-

word / Private.

Adobe Type ManagerCompatibility




• All assign m ents followin g / Private (except for CharStringsconten ts) m ust be in th e Private dictionary.

• If th e eexec operator is used, it must occur before the first

occurrence of the token / Private. eexec is not a part of the

PostScript language, but is an add ition al operator un derstood

by the PostScript interpreter, whose purpose is to execute

encrypted fon t code.

10.1 Simple Values

Wh en a sim ple value (in teger, real, strin g, n am e, or Boolean) is

associated with a n am e in a diction ary, that value m ust follow th e

n ame imm ediately as th e next token.

Boolean values may only be the tokens true or false. Simple

values, such as integers, must be written explicitly following a

name; they may not be computed by a sequence of PostScriptlanguage constants and operators.

For exam ple,

/FontType 1 def

follows th e correct pattern , but

1 /FontType exch def

an d

/FontType 2 1 sub def

do n ot con form to Type 1 fon t parsing rules even th ough th ey are

legal and equivalent PostScript language code.

10.2 Arrays

Wh en an array is expected as a value, th e array m ust imm ediately

follow th e n am e to wh ich it is assigned . An array m ust begin with

either [ or { and term inate with th e correspon ding ] or }. Num eric

con ten ts mu st occur as single tokens with in th e array delim iters.



Chapter 10: Adobe Type Manager Compatibility 85

10.3 Keywords

Values for certain keywords must conform to their own rules as

described as follows:

• The tokens fo llowing / Encoding may be StandardEncodingdef, in which case the Adobe Standard Encoding will be

assigned to this font program. For special encodings, assign-m ents m ust be performed as sh own in th e exam ple in section

2.3, “Explan ation of a Typical Fon t Program,” u sin g th e repeti-

tive sequen ce:

dup index charactername put

where index is an integer corresponding to an entry in the

Encoding vector, an d charactername refers to a PostScript lan -

guage nam e token , such as / Alpha or / A, giving th e character

n am e assign ed to a particular character code. The Adobe Type

Manager parser skips to the firstdup

token after/ Encoding

to

fin d th e first character en codin g assignm en t. Th is sequ en ce of

assignm en ts mu st be followed by an in stance of th e token defor readonly; such a token m ay not o ccur within th e sequen ce

of assignm ent s.

• The on ly bin ary data that m ay occur in a font program are in

Subrsan d CharStrings entries.

• The integer im m ediately fol lowin g / Subrsm ust be exactly th e

n um ber of entries in th e Subrs array.

• On ly Subrsentries may be defin ed un til th e Subrsarray is com -

pleted. Each subrou tine is defin ed using th e sequen ce:

dup index nbytes RD ~n~binary~bytes~ NP

where RD is the name of the procedure performing the RDfunction as defined in section 2.4, “Inside the Encrypted Por-

tion.” This is usually either -| or RD. NP is the name of the

procedure performing the NP function as defined in section

2.4. This is usually either | or NP. There must be exactly one

blan k between th e RD token an d th e bin ary bytes.




• The integer im m ediately fol lowing / CharStrings must be

greater than or equal to the number of CharStrings entries.

Each ch arstring en try is defin ed using th e sequen ce:

charactername nbytes RD ~n~binary~bytes~ ND

where charactername is the name of the character defined by

th e charstrin g. RD is again th e n ame o f the p rocedure perform-in g th e RD fun ction as defin ed in section 2.4. ND is th e nam e

of the p rocedure perform ing th e ND fun ction as defined in sec-

tion 2.4. Th is is usually eith er |- or ND . Th ere mu st be exactly

one blank between the RD token and the binary bytes. Only

CharStrings entries may be defin ed un til th e CharStrings dic-

tion ary is com pleted.

• The sequence of charstrin g definit ion s in the CharStrings dic-

tion ary mu st be followed by an in stance of th e token end. An

end token m ay not occur with in th e sequen ce of CharStringsdictionary assignments. No assignments may occur in the

Type 1 font program after the CharStrings dictionary is com-

pleted.

• If t h e t oken FontDirectory occurs in th e fon t program after the

first occurrence of the token / Private, then the font program

must be a synthetic font, as described in section 9.1, “Syn-

thetic Fonts.” If the token hires occurs in the font program

after the first occurrence of the token / Private, th en th e fon t

must be a hybrid font, as described in section 9.2, “Hybrid

Fonts.”



87

APPENDIX 1

Entry Page Description

BlueFuzz 41 Exten ds th e ran ge of align m en t

zones. Optional.

BlueScale 39 Related to p oin t size at wh ich t o

deactivate oversh oot supp ression .Optional.

BlueShift 40 O versh o ot en fo rcem en t . If Flex

feature is used, then th e m axim um

Flex feature h eight plus 1. Op tion al,

bu t relevant even if th ere is n o Flex in

the font program .

BlueValues 36 Fo n t-w id e vert ical align m e n t zo n es.

Required.

ExpansionFactor 45 Pro vid es co n tro l o ver ren d erin g o f

coun ters. Option al.

FamilyBlues 38 Fam ily-wid e vert ical align m e n t

zones. Optional.

FamilyOtherBlues 38 Fam ily-wid e bo ttom align m en t

zones. Optional.

ForceBold 43 Set to tru e t o fo rce b old ap pearan ce at

sm all sizes. Set to false to in h ibit th isbehavior. Optional.

LanguageGroup 44 Id en t ifies lan gu age gro up o f fo n t.

Optional.

lenIV 45 Nu m ber of bytes at begin n in g of

charstring. Optional.

Private DictionaryEntries




Entry Page Description

MinFeature 45 O bso let e. Set t o {16 16}. Requ ired .

ND 16 Pro ced ure th at abbreviates noaccessdef. Required (may be n am ed | -).

NP 16 Pro ced ure th at abbreviates noaccessput. Required (may be n am ed | ).

OtherBlues 38 Ad ditio n al b ott om align m en t zo n es.

Optional.

OtherSubrs 67 Flex, h in t rep lacem en t, an d fu tu re

extensions. Required if Flex or hint

replacem en t are used.

password 45 Co m pat ib ilit y en t ry. Set to 5839.

Required.

RD 16 Pro ced ure th at read s a ch arstrin g

from th e inpu t stream. Required (may

be named -|).

RndStemUp 44 Co m pat ib ilit y en t ry. Use o n ly fo r

font p rograms in lan guage group 1.

Optional.

StdHW 42 Dom in an t horizon tal stem width .

Optional.

StdVW 42 Dom in an t vertical stem wid th .

Optional.

StemSnapH 42 Array of com m o n h orizon tal stem

widths. Option al.

StemSnapV 43 Array of com m o n vert ical stem

widths. Option al.

Subrs 67 Ch arstrin g su bro ut in es. O ptio n al.Requ ired if OtherSubrsare used.

UniqueID 17 Nu m ber u n iq ue to each Typ e 1 fon t

program . Option al, but stron gly

recommended.



89

APPENDIX 2

Value Com m and Value Com m and

1 hstem 12 0 dotsection

3 vstem 12 1 vstem3

4 vmoveto 12 2 hstem3

5 rlineto 12 6 seac

6 hlineto 12 7 sbw

7 vlineto 12 12 div

8 rrcurveto 12 16 callothersubr

9 closepath 12 17 pop

10 callsubr 12 33 setcurrentpoint

11 return

12 escape

13 hsbw

14 endchar

21 rmoveto

22 hmoveto

30 vhcurveto

31 hvcurveto

Charstring CommandValues



91

APPENDIX 3

The following PostScript language code creates four procedures

th at m ake up th e first four en tries in th e OtherSubrsarray in th e

Private dictionary. The first three procedures pertain to Flex and

th e fourth is used for h int replacem ent . Th e code is copyrigh ted

by Adobe Systems Incorporated, and may not be reproduced

except by p erm ission of Adob e Systems In corporat ed. Ado be Sys-

tems Incorporated grants permission to use this code in Type 1font programs, as lon g as the code is used as it appears in th is doc-

ument, the copyright notice remains intact, and the character

outline code included in such a font program is neither copied

nor derived from character outline code in any Adobe Systems

font program .

Th e PostScript language program defin ing th e Flex procedure h as

been m odified sin ce Version 1.0 (March 1990) of this docum ent .

Include this code in a font program if you want to use both the

Flex and hint replacement features. Another code segment for

fonts that require hint replacemen t on ly is broken out at th e endof this appen dix.

The two programs that follow are available on diskette for the

con ven ience of Type 1 fon t pro gram d evelop ers. To order th e dis-

kette, please use th e order form at th e back of this docum ent .

Th e following code should b e executed within th e Private dictio-

nary:

% Copyright (c) 1987-1990 Adobe Systems Incorporated.% All Rights Reserved.

% This code to be used for Flex and hint replacement.% Version 1.1 /OtherSubrs[systemdict / internaldict known{1183615869 systemdict /internaldict get exec /FlxProc known {save true} {false} ifelse}

OtherSubrs Programs




{userdict / internaldict known not {userdict /internaldict{count 0 eq{/internaldict errordict /invalidaccess get exec} ifdup type /integertype ne{/internaldict errordict /invalidaccess get exec} ifdup 1183615869 eq

{pop 0}{/internaldict errordict /invalidaccess get exec}ifelse}dup 14 get 1 25 dict putbind executeonly put} if1183615869 userdict /internaldict get exec /FlxProc known {save true} {false} ifelse}ifelse[systemdict / internaldict known not{ 100 dict /begin cvx /mtx matrix /def cvx } ifsystemdict /currentpacking known {currentpacking true setpacking} if{systemdict / internaldict known {1183615869 systemdict /internaldict get execdup /$FlxDict known not {dup dup length exch maxlength eq{ pop userdict dup / $FlxDict known not{ 100 dict begin /mtx matrix defdup /$FlxDict currentdict put end } if }{ 100 dict begin /mtx matrix defdup /$FlxDict currentdict put end }ifelse} if /$FlxDict get begin} ifgrestore /exdef {exch def} def /dmin exch abs 100 div def /epX exdef / epY exdef /c4y2 exdef /c4x2 exdef / c4y1 exdef /c4x1 exdef / c4y0 exdef /c4x0 exdef /c3y2 exdef /c3x2 exdef / c3y1 exdef /c3x1 exdef / c3y0 exdef /c3x0 exdef /c1y2 exdef /c1x2 exdef /c2x2 c4x2 def /c2y2 c4y2 def /yflag c1y2 c3y2 sub abs c1x2 c3x2 sub abs gt def /PickCoords {

{c1x0 c1y0 c1x1 c1y1 c1x2 c1y2 c2x0 c2y0 c2x1 c2y1 c2x2 c2y2 }{c3x0 c3y0 c3x1 c3y1 c3x2 c3y2 c4x0 c4y0 c4x1 c4y1 c4x2 c4y2 }ifelse /y5 exdef / x5 exdef / y4 exdef / x4 exdef / y3 exdef / x3 exdef /y2 exdef / x2 exdef / y1 exdef / x1 exdef / y0 exdef / x0 exdef} def



Appendix 3: OtherSubrs Programs 93

mtx currentmatrix popmtx 0 get abs .00001 lt mtx 3 get abs .00001 lt or{/flipXY -1 def }{mtx 1 get abs .00001 lt mtx 2 get abs .00001 lt or{/flipXY 1 def }{/flipXY 0 def }ifelse }

ifelse /erosion 1 defsystemdict / internaldict known {1183615869 systemdict /internaldict get exec dup /erosion known{/erosion get /erosion exch def}{pop}ifelse} ifyflag{flipXY 0 eq c3y2 c4y2 eq or{false PickCoords }{/shrink c3y2 c4y2 eq{0}{c1y2 c4y2 sub c3y2 c4y2 sub div abs} ifelse def /yshrink {c4y2 sub shrink mul c4y2 add} def /c1y0 c3y0 yshrink def /c1y1 c3y1 yshrink def /c2y0 c4y0 yshrink def /c2y1 c4y1 yshrink def /c1x0 c3x0 def / c1x1 c3x1 def / c2x0 c4x0 def / c2x1 c4x1 def /dY 0 c3y2 c1y2 sub rounddtransform flipXY 1 eq {exch} if pop abs defdY dmin lt PickCoordsy2 c1y2 sub abs 0.001 gt {c1x2 c1y2 transform flipXY 1 eq {exch} if /cx exch def /cy exch def /dY 0 y2 c1y2 sub round dtransform flipXY 1 eq {exch}if pop defdY round dup 0 ne{/dY exdef }{pop dY 0 lt {-1}{1} ifelse /dY exdef }ifelse /erode PaintType 2 ne erosion 0.5 ge and deferode {/cy cy 0.5 sub def} if /ey cy dY add def /ey ey ceiling ey sub ey floor add deferode {/ey ey 0.5 add def} ifey cx flipXY 1 eq {exch} if itransform exch popy2 sub / eShift exch def

/y1 y1 eShift add def /y2 y2 eShift add def /y3 y3eShift add def} if} ifelse}{flipXY 0 eq c3x2 c4x2 eq or




{false PickCoords }{/shrink c3x2 c4x2 eq{0}{c1x2 c4x2 sub c3x2 c4x2 sub div abs} ifelse def /xshrink {c4x2 sub shrink mul c4x2 add} def /c1x0 c3x0 xshrink def /c1x1 c3x1 xshrink def /c2x0 c4x0 xshrink def /c2x1 c4x1 xshrink def /c1y0 c3y0 def /c1y1 c3y1 def /c2y0 c4y0 def /c2y1 c4y1 def

/dX c3x2 c1x2 sub round 0 dtransformflipXY -1 eq {exch} if pop abs defdX dmin lt PickCoordsx2 c1x2 sub abs 0.001 gt {c1x2 c1y2 transform flipXY -1 eq {exch} if /cy exch def /cx exch def /dX x2 c1x2 sub round 0 dtransform flipXY -1 eq {exch} if pop defdX round dup 0 ne{/dX exdef }{pop dX 0 lt {-1}{1} ifelse /dX exdef }ifelse /erode PaintType 2 ne erosion .5 ge and deferode {/cx cx .5 sub def} if /ex cx dX add def /ex ex ceiling ex sub ex floor add deferode {/ex ex .5 add def} ifex cy flipXY -1 eq {exch} if itransform popx2 sub /eShift exch def /x1 x1 eShift add def /x2 x2 eShift add def /x3 x3 eShift add def} if} ifelse} ifelsex2 x5 eq y2 y5 eq or{ x5 y5 lineto }{ x0 y0 x1 y1 x2 y2 curvetox3 y3 x4 y4 x5 y5 curveto }ifelseepY epX}systemdict /currentpacking known {exch setpacking} if /exec cvx /end cvx ] cvxexecuteonlyexch{pop true exch restore}{systemdict / internaldict known not{1183615869 userdict /internaldict get exec

exch /FlxProc exch put true}{1183615869 systemdict /internaldict get execdup length exch maxlength eq{false}{1183615869 systemdict /internaldict get execexch /FlxProc exch put true}



Appendix 3: OtherSubrs Programs 95

ifelse}ifelse}ifelse{systemdict / internaldict known{{1183615869 systemdict /internaldict get exec /FlxProc get exec}}{{1183615869 userdict /internaldict get exec /FlxProc get exec}}ifelse executeonly

} if{gsave currentpoint newpath moveto} executeonly{currentpoint grestore gsave currentpoint newpath moveto} executeonly{systemdict / internaldict known not{pop 3}{1183615869 systemdict /internaldict get execdup / startlock known{/startlock get exec}{dup /strtlck known{/strtlck get exec}{pop 3}ifelse}ifelse}ifelse} executeonly] noaccess def

For h int replacemen t on ly, use th is code:

% Copyright (c) 1987 Adobe Systems Incorporated.% All rights reserved.% This code to be used for hint replacement only. /OtherSubrs[{} {} {}{systemdict / internaldict known not

{pop 3}{1183615869 systemdict /internaldict get execdup / startlock known{/startlock get exec}{dup /strtlck known{/strtlck get exec}{pop 3}ifelse}ifelse}ifelse} executeonly] noaccess def




The first listing of PostScript language code creates an array of

four elem ent s, each of wh ich is a procedure, and it associates th is

array with OtherSubrs. Some of this code is executed when the

font program is read. At th at tim e, a som ewhat com plicated selec-

tion of the correct procedure to place in slot 0 is made. This

selection is based on features that m ay or m ay no t be present in

various version s of th e PostScript in terpreter.

If th e Flex m ech an ism is n ot u sed in th e fon t program , entries 0,

1, and 2 m ay be replaced by n ull procedures ({ }). If hin t replace-

m ent is not u sed in th e fon t program, en try 3 may be eliminated.

If n eith er Flex n or h int replacem ent is used, the OtherSubrsarray

m ay be elim inated entirely.

The p receding code uses a special diction ary, internaldict for sev-

eral operators and values. This dictionary has limited capacity

an d t h e PostScript interpreter depen ds on its in tegrity for correct

operation. Do n ot use this diction ary for any pu rpose oth er than

as part of th e preceding code. Furth ermo re, if you write your owncode for th ese fun ction s, do n ot use the n ame FlxProc; th is m ay

interfere with other font programs that incorporate the preced-

ing code.



97

APPENDIX 4

This document describes Version 1.1 of the Adobe Type 1 Font

Form at . Chan ges to th e Adobe Type 1 Font Form at from Version 1.0

pu blished March 1990, are n oted in t h e paragraph s below.

Clearly documented default values for the BlueScale (.039625),

BlueShift (7), BlueFuzz (1), and ExpansionFactor (.06) en tries in

th e Private diction ary. See pages 40-41, an d 45 .

A n ew en try to th e Private dictionary, ExpansionFactor, provides

a font level h int th at is useful for in telligent rend erin g of ch arac-

ter glyph s such as bar codes an d logos that h ave a lot of coun ters.

See page 45.

Added warning to the description of the closepath command

about u sin g closepath to form a subpath section in tend ed to be

zero len gth . See page 51.

The Ado be Type Man ager parser skips to th e first dup token after/ Encoding to find the first character encoding assignment. See

page 85.

Th e PostScript language program defin ing th e Flex p rocedure in

Appen dix 3 has been m odified to p rotect against trying to pu t th e

$FlxDict into internaldict if internaldict is full. The old code could

lead to dictfull errors out of show in certain unlikely circum-

stances. The new code simply puts the $FlxDict in userdict if

internaldict is fu ll. See pages 91-95.

Changes



98



99

%!FontType1 12

%!PS-AdobeFont 12

%!VMusage

calculating values for 12

%%VMusage 12

-| 16

| 16

|- 16, 86

Aabsolute coordinate values 26

accent ed characters 50

Adobe Stan dardEn coding vector 50

Adob e Type Library 68, 80

Adobe Type Manager

comp atibility with 83

AFM files 18

algorithms

decryption 62en codin g Flex 75

encryption 62

alignm ent cont rol 36, 57

alignm ent zones 23, 36, 37, 41

dominant 38

for a font family 38

Rom an characters 25

Apple Macintosh

special file format 4

ascend er-h eight 25, 37

ascend er-h eight oversh oot position

37

Bbaselin e 23, 36

baseline oversho ot position 24, 36

Bézier cu rves

Flex 75

BlueFuzz 37, 38, 41

BlueScale 37 , 39

restriction on 40

BlueShift 39 , 40 , 74, 77

setting for Flex 74

BlueValues 16 , 36 , 37, 57

nu m ber of pairs 37

bold ch aracters

on display devices 43

bottom -zon es 24, 36

bounding box

FontBBox 13

BuildCh ar 7, 26, 38, 56

detectin g errors 8

differences between Type 1 and

Type 3 7

error checkin g 8

ho w it works 8

Type 3 7

when it interprets a ch arstring

16

buildchar 23

Ccaching 13

and UniqueID nu mber 17

callothersubr 55 , 6 8

callsubr 55 , 68, 70

cap-h eight 24, 37

cap-h eight oversh oot position 24, 37

changing hints 69

character

accented 50

coordinate values 26

geography 21

left sidebearing 22

left sidebearing poin t 22

Index




measurements 22

origin 22

scaling 25

scaling m atrix 25

terminology 21

width 22

ch aracter level h int s 56–57

character outline

and flatten ed path s 27

as PostScript path 26

en coded in Subrs array 67

character paths

and lim itcheck 27

con cisen ess of 31

direction of 27

lim itations of 26

overlappin g of 28

tangent continuity 30

ch aracter space 25

coordinate system 25

ran ge of coordin ate values 26

charstring 47

comm and list 49

comm and value table 89

description 47

encoding 47

encodin g examp le 58

encryption 64

charstring comm and encoding 48

charstring n um ber encodin g 48

Ch arStrin gs diction ary 47

diagram of 10

encoding 14

encrypting 14

Chin ese characters 44

clipping

accen ted characters 13

closefile 17

closepath 26 , 51 , 7 1

compatibility

with ATM 83

with older interpreters 4, 45

coordinate values

ran ge of 26

copyrights 5

advant ages of 5

cup ped serifs 72

current point 56

and closepath comm and 51

Cyrillic 44

Ddeclarative h ints 35, 56

decription

algorithm for 63

decrypting

eexec-en crypted text 15

definefont 19

descender-depth 38descend er-depth oversh oot position

38

developer support 4

device space 25

direction of path s 27

discarding stem hin ts 69

div 26, 49, 54

dotsection 52 , 7 1

Eeexec 83

decrypting 15encryption 63

operation of 14

encoding

charstring 47

charstrin g comm and s 48

charstrin g n um bers 48

comm and values 89

example of 58

En codin g array 13

changing 8

encryption 61

algorithms 62charstring 64

eexec 61, 63

method 61

end 86

endchar 50 , 51, 58

escape 49 , 8 9

ExpansionFactor 45

FFamilyBlues 38

FamilyOtherBlues 38

FID 17, 19figure-height 37

figure-height oversho ot position 37

fill 8, 50

filling a cha racter 27

findfont 19

flat position 23



Index 101

flattened path lim it 27

Flex 72

algorithm for 75

example 76

setting BlueSh ift 74

FlxProc 96

font cache 17

font dictionary 7, 9, 13

diagram of 10

required en tries 9

font level h ints 36

font nam e

registration of 19

font p rogram

encrypted portion 14–17

hybrid 80

naming 19

organization 7

sample code 11

special organ ization 79

synthetic 79

Fon tBBox 13, 51

accuracy 13

Fon tDirectory 19, 80, 86

Fon tInfo dictionary 13, 17

diagram of 10

Fon tMatrix 13, 25, 26

Fon tNam e 13, 17, 19

Fon tType 13, 18

ForceBold 43

G“ghost” stems 57

Greek cha racters 44

Hheight coordination 38

hint commands 52

h int replacemen t 53, 54, 56, 67, 68,

71

h ints 3, 14, 21, 35

changing 69

charact er level 56–57

declarative 35Flex 72

font level 36

for dot sections 52, 71

overlapping 56

stem 56, 69

uses of 35

where th ey appear 35

h ires 81, 86

hlineto 52 , 5 8

hmoveto 52

h orizon tal stem zones 53

h orizon tal stems 21, 56

hsbw 50 , 51, 58

hstem 53 , 5 6

hstem3 53

hvcurveto 52

h ybrid fonts 80

IIBM PC

special file format 4

ideographs 44

image 26

imagemask 27

internaldict 96

invalidfont 8

italicand StemSnapV 42

JJapan ese ch aracters 44

KKan ji ch aracters 27, 44

Kan ji prin ters 27

Korean charact ers 44

LLanguageGroup 44

LaserWriter 45

Latin charact ers 44

left sidebearin g 22

left sidebearin g poin t 22, 51, 53, 54,

58

lenIV 45

limitcheck 27

Mm atrix, scaling 25

MinFeature 16 , 45

Nnam ing a font program 19

ND 16 , 8 6

n oaccess attribute 16

NP 16 , 8 5




Ooperand stack

Type 1BuildCh ar 47

Optima 80

ordin al baselin e 25, 38

ordinal baseline oversh oot position

38

origin 22OtherBlues 36 , 38 , 5 7

nu m ber of pairs 38

OtherSubrs 55 , 67 , 72, 91

an d Flex 68

and hint replacemen t 69

program listing 91

overlap

of character path 28

of stem h ints 56, 69

oversh oot position 23

oversh oot suppression 36, 39, 40

overshoots 23

P, QPaintType 8, 13, 28, 51

support for 50

password 16 , 45

path construction comm ands 51–54

paths 27

see also character paths

points

at extremes 29

tangent continuity 30

pop 55 , 69, 78PostScript Langua ge Referen ce Man ual

3, 49, 83

Private diction ary 35, 87

RRD 16

use of 16

return 55 , 6 7

rlineto 26 , 52 , 5 8

rmoveto 50 , 52 , 58, 71, 77

RndStemUp 44

roman characters 44rrcurveto 52 , 72, 75, 76

Ssbw 50 , 51

scalefont 25

scaling m atrix 25

exceptions 26

seac 50 , 5 1

serifs 21

cupped 72setcachedevice 50

setcurrentpoint 56 , 7 8

standard en coding accented ch arac-

ter 50

StdHW 42

StdVW 42

stem

defin ition of 21

ghost 57

hin ts for 56

width information 42

stem hin ts 56, 69discarding 69

how they work 69

stem width 42

in italic ch aracters 42

StemSnapH 42

StemSnapV 43

stroke 8, 50

subroutines

OtherSubrs 68

Subrs 78

uses for 67

Subrs 51, 55, 67 , 68, 70, 75, 77, 80, 85

first four en tries 78

superior baseline 25, 38

superior baseline overshoot position

38

Symb ol font program 10

syn th etic fonts 79

Ttop -zon es 24, 37, 57

transformations

and scaling m atrix 26

Type 1 BuildCh ar 7, 23, 55error checkin g 8

ho w it works 8

operand stack 47



Index 103

Type 1 font format 2

definition 2

future extensions 4

version 12

Type 1 font p rogram

as program 5

comments 12

conceptu al overview 9

copyrights 5

diction ary structure 9

naming 19

obtainin g a UniqueID 18

sample code 10

UniqueID 18

Type 3 font format 7

UUniqueID 13, 16, 17 , 7 9

coordinator 18

obtaining 17"open " ran ge 17

range 17

uses for 17

user space 25

user-defin ed font format 2

userdict 16

Vversion, font format 12

vertical stem zon e 54

vertical stems 21, 42, 56

vhcurveto 52vlineto 52 , 5 8

VM 79

VM usage 79

determining 12

purpose 12

vmoveto 52

vstem 54 , 56, 58

vstem3 54

Wwh ite space ch aracters 14

width , character 22windin g rules 28

X, Y, Zx-heigh t 24, 37

x-heigh t oversho ot position 24, 37



This book was produced using FrameMaker 2.0 and other appli-

cation software packages that support the PostScript language

an d Type 1 fon t pro grams. Camera-ready film m asters were pro-

du ced on a h igh -resolution PostScript imagesetter.

Th e type used is ent irely from th e ITC Stone® fam ily, design ed at

Adobe Systems. Chapter headings are set in ITC Stone Sans Semi-bold 24 point an d th e body text is set in 10 on 12 point ITC Stone

Serif , ITC Stone Serif Italic an d ITC Stone Sans Sem ibold .

Authors—Dou g Brot z, Bill Paxt on , Jeff Walden

Editing—Jeff Walden , Jud ith Walth ers von Alten

Index—Minette No rm an , Sue Crism an , Laura Dower

Illustrations—Keala Hagman, Kim Isola, Rob Babcock

Cover Design—Nan cy Wint ers, Don n a Helliwell

Book Design—Nan cy Win ters, Eve Lyn es

Book Production—Andrea Bruno, Eve Lynes, Robin Edwards,

Lau ra Dow er, Lisa Kelly.

Technical Assistance—Dick Sweet, Andy Shore

Reviewers—Rob Babcock, Doug Brotz, Bill Paxton, Kathe Morris,

Terry O’Donnell, Linda Weinert, Linda Gass, Mike Byron, Peter

Hibbard , Dan Mills, David Lem on , Ed Taft, Matt Foley

Publication Management—Eve Lynes, Joan Delfino

Product Management—Rob Babco ck

Colophon



Diskette Order Form

If you sen d t h is coup on (or a copy of it) to Adob e System s, we willsen d you a diskette con tainin g th e PostScript lan guage programs

listed in Appen dix 3 th at pertain to Flex and h int replacemen t.

TYPE 1 DISKETTE OFFER - VERSION 1.1

Please sen d m e a copy of th e program diskette. I have en closed$10.00 to cover the costs of materials, handling, and postage.

Than k you.

t 3-1/2" Macintosh format t 5-1/4" PC form at

Nam e ____________________________________________________

Title _____________________________________________________

Organization ______________________________________________

Street_____________________________________________________

City ________________________ State ______ Z ip____________

Phone ______________________

adobe type 1 font format

Documents