1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
|
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.mathworks.com!zombie.ncsc.mil!newsgate.duke.edu!news-feed-1.peachnet.edu!paperboy.wellfleet.com!news3.near.net!amber.ora.com!not-for-mail
From: norm@ora.com (Norman Walsh)
Newsgroups: comp.fonts,comp.answers,news.answers
Subject: comp.fonts FAQ: NeXT Info
Supersedes: <font-faq-12_817479312@ora.com>
Followup-To: poster
Date: 14 Aug 1996 10:35:12 -0400
Organization: O'Reilly and Associates, Inc.
Lines: 515
Sender: norm@ruby.ora.com
Approved: news-answers-request@MIT.Edu
Distribution: world
Expires: 27 Sep 1996 14:34:08 GMT
Message-ID: <font-faq-12_840033248@ora.com>
References: <font-faq-1_840033248@ora.com>
Reply-To: norm@ora.com (Norman Walsh)
NNTP-Posting-Host: ruby.ora.com
Summary: This posting answers frequently asked questions about fonts.
It addresses both general font questions and questions that
are specific to a particular platform.
X-Web-Homepage: http://www.ora.com/homepages/comp.fonts/
Xref: senator-bedfellow.mit.edu comp.fonts:48309 comp.answers:20523 news.answers:79244
Archive-name: fonts-faq/part12
Version: 2.1.5
Subject: 7. NeXT Information
If you have any suggestions for this section, please forward your
suggestions to norm.
Subject: 7.1. Tell me about NeXTstep fonts
NeXTstep fonts are Adobe Type 1 fonts stored in ASCII (PFA) format.
There are several rules about how fonts must be installed before they
work.
I'd like to thank Henry for rewriting this section.
Basic Format
============
NeXTstep fonts live in one of three folders:
/NextLibrary/Fonts
Contains system fonts. In general, you will not install any
new fonts here.
/LocalLibrary/Fonts
Contains fonts which are accessible to every user on a system
or a network.
~/Library/Fonts
(where ~ is your home folder) means fonts which are private to
a specific user.
A NeXTstep font is actually a folder containing various components of
the font. Components are:
* the outline font file - REQUIRED
* the font metrics (AFM) file - REQUIRED
* one or more screen font (bitmap) files - OPTIONAL
Font Folder and Font Filename Requirements
==========================================
The name of the folder containing a font and the name of the font file
itself must follow strict rules - the names can NOT be any old name you
like. For a font to work correctly, the base folder and font filename
MUST BE THE SAME as the name of the outline font. This is usually the
same as the value of the FontName field in the AFM file or the value of
the /FontName key in the actual font itself. Suppose you have a font
called Headhunter. The Headhunter font must live within a folder called
Headhunter.font
within one of the three folders mentioned above. Within the
Headhunter.font folder, you must have the two files
Headhunter ( the outline file )
Headhunter.afm ( the AFM file )
If you have a bitmap file for Headhunter, it must live in a file
Headhunter.bepf ( the bitmap file )
Variations such as Bold, Italic, etc., should be their own font files
in their own folder. So if you have a font called Headhunter-Bold, you
need to create a folder called
Headhunter-Bold.font
within one of the three folders mentioned above. Within the
Headhunter.font folder, you must have the two files
Headhunter-Bold ( the outline file )
Headhunter-Bold.afm ( the AFM file )
If you have a bitmap file for Headhunter, it must live in a file
Headhunter-Bold.bepf ( the bitmap file )
For NeXTstep 1.0 ONLY, you also need to take the following steps:
-----------------------------------------------------------------
* If they do not already exist, create the following folders:
* ~/Library/Fonts/outline
* ~/Library/Fonts/afm
* ~/Library/Fonts/bitmap
* In each of these folders, create a symbolic link to the
corresponding component file in each font.
For NeXTstep 2.0 and up:
------------------------
The font description is taken from the font folder itself, so you don't
need to do this. It may be beneficial to simply create these folders
and put nothing in them, but I'm not sure it matters.
Certain "old" applications which haven't upgraded to the NeXTstep 2.0
scheme of fonts may depend on these folders being present.
The last step is to get the system to recognize the new font(s). You
may have noticed the existence of three files in the Fonts folder:
.fontdirectory, .fontlist, and .afmcache. These are files the system
looks at to see which fonts exist.
The easiest way to update them is to simply start up an application and
open the font panel. It should recognize that the update time stamp on
the Fonts folder has changed, and update the files accordingly. It is
probably a good idea to simply delete the three above files beforehand.
You should get a message window saying "incorporating information on
new fonts. Please wait (this may take xx seconds)". Your new fonts
should be available now.
If this does not work, you can update them manually. Open up a Terminal
shell and go to your Fonts folder. At the prompt, type two commands:
buildafmdir
cacheAFMData afm (the parameter is the <afm dir>)
The new fonts will not work if the cacheAFMData command is not run, and
since it is an undocumented command, it is a common culprit.
[ed: the cacheAFMData step may not be required in 3.0 OS]
I believe this is true. Looks like the PasteBoard Services runs
cacheAFMData in 3.0.
You should now be able to see and preview your fonts in the font panel.
If you are still having problems with your font, such as the <<
Unusable font >> message, consult NeXTAnswers. There are some useful
suggestions for debugging faulty fonts there. It is also always
helpful to look at existing fonts to see how they are installed.
One note on the NeXTAnswers. Supposedly there are only a few discrete
values which are allowed to appear in the weight field of the font:
"Ultra Light", "Thin", "Light", "Extra Light", "Book", "Regular",
"Plain", "Roman", "Medium", "Demi", "Demi-Bold", "Semi-Bold", "Bold",
"Extra Bold", "Heavy", "Heavyface", "Black", "Ultra", "UltraBlack",
"Fat", "ExtraBlack", and "Obese". However, I have a few fonts where
this is not the case ("standard" is a common entry) and have had no
problems as of yet. But it would probably be wiser to be on the safe
side.
See below for a definitive list.
This is Info file compfont.info, produced by Makeinfo-1.55 from the
input file FAQ.texinfo.
Subject: 7.2. Tell me more about NeXTstep fonts
Outline files should be in PFA or hexadecimal ASCII format. The font
name should be taken either from the outline (font) file or the AFM
file. In both case the name is given after the word "FontName" at the
beginning of the file)
As a matter of fact, fonts don't strictly HAVE to be in all hexadecimal
ASCII format. The eexec portion of the font can be in binary if you
wish, and in fact some Mac->NeXTstep or PFB->NeXTstep font converters
simply strip off the Mac/PFB storage format headers and leave the
binary sections as binary.
However, if you wish to send such a font across a serial channel to a
PostScript printer, you will need some way to unpack the binary eexec
portion to seven-bit ASCII before sending the font.
Converted Fonts After Conversion
--------------------------------
After conversion they are just like any other freeware or shareware
font that you can get in NeXTstep-format from the archives. That's just
outline and AFM files but no bitmapped screen fonts. So small point
size means poor resolution on screen but they most of should print OK
if they are any good ( = usually made with Fontographer).
About Conversion Utilities
--------------------------
NeXTstep utilities
..................
* unfont
You can find a package, named something like
pcATMfont2NeXT.tar.Z, from NeXT archives (cs.orst.edu)
that converts PC fonts to NeXT format (PFB -> PFA).
The most useful tool for me has been "unfont" which
converts the .pfb (binary outline) font to ASCII outline
font.
I usually use it like this
$ unfont new_font.pfb >NewFont
If the conversion was successful all I have to after that is
maybe to rename the font correctly and move the outline file
in the correct .font folder.
* Opener.app
Opener seems to be a very useful application since it can
open several kinds file packages on NeXTstep that are
common on other platforms. E.g. ".sit", ".hqx", ".zoo",
".zip", ".z", etc.
I haven't used it a lot but looks very promising.
* T1utils-1.1
This is collection of command-line programs that manipulate
PS Type 1 fonts and one of them can also do the PFB->PFA
conversion (t1ascii?).
Basic unarchiving of Mac and PC files.
On your Unix machine:
xbin
Converts .hqx to:
.data
Rename and transfer to PC (or use opener.app on NeXT?)
.info
Discard
.rsrc
Discard
unzip
Converts .zip to:
.inf
Discard
.wfn
Discard
.pfm
Discard (unless it can generate a better AFM file)
everything else
Transfer to NeXT On a PC:
xbin
Converts .hqx to:
.data
Rename and transfer to PC (or use opener.app on NeXT?)
.info
Discard
.rsrc
Discard
extract -f ...
Converts .cpt to:
file with no extension
This is usually the outline font. Refont and transfer to
NeXT.
.afm
Transfer to NeXT.
.pfm
Discard (unless it can generate a better AFM file)
.bma
Discard if you have an AFM file.
unsit30 -eb ...
Converts .sit to:
file with no extension
This is usually the outline font. Refont and transfer to
NeXT.
.afm
Transfer to NeXT.
.pfm
Discard (unless it can generate a better AFM file)
.bma
Discard if you have an AFM file.
refont
Converts outline formats from Mac to NeXT format (PFA).
pkunzip
Converts .zip to:
.inf
Discard
.wfn
Discard
.pfm
Discard (unless it can generate a better AFM file)
everything else
Transfer to NeXT On a NeXT
Opener.app
Converts archive formats (.sit, .hqx, .zip) to NeXT format.
unfont
Converts PFB files to NeXT format.
afm
Converts AFM files to NeXT format AFM files (CR/LF hackery)
Installation
------------
There are scripts (installfont) available that can handle the
installation process but here is how you do it manually.
* .font
After all that you have to create the .font folder, move the
outline and .afm files there and start fighting with the strangely
formatted .afm file. The most common problems are font name
mismatch between outline and AFM files (family name is incorrect
or too long, etc) and missing fields (ex. no ItalicAngle entry) in
the AFM file.
* buildafmdir AND cacheAFMData
buildafmdir puts its complains to Console but cacheAFMData put
them on stdout or stderr (ie. Terminal Window).
PARSE ERRORS ----------- "Parse error 10000011 ..." comes from
mismatch between of CharMetrics declared in the .afm and actually
found. I haven't been able to figure out the other strange parse
errors.
buildafmdir in the 3.0 release has the limitation of not being
able to install more that 255 fonts in any one font folder. This
is supposed to be fixed in 3.1.
* The Dreaded <<Unusable Font>> Message
<<Unusable Font>> appears in the font panel when you have run
buildafmdir and it finds things it thinks are wrong with the AFM
file. Errors can also be generated by parsing routines inside the
PasteBoard Services.
<<Unusable Font>> almost NEVER has anything to do with the font
itself, since buildafmdir doesn't actually look inside the font.
Errors in the font due to faulty conversion will likely show up at
the time the PostScript server actually attempts to define the
font or render characters from the font.
The only error I have ever seen from a converted font was the
results of a naive Macintosh to PFA converter, which didn't
understand that the POST resources in a Macintosh format Type 1
font do not have to be in order, nor do the POST resources all
have to be contiguous - they can be interspersed with other
resources. The results were that a comment resource ended up in
the middle of the eexec section of the font and the PostScript
interpreter threw out lots of errors.
<<Unusable Font>> almost ALWAYS occurs because there is something
wrong with the AFM file you installed. Here is a partial list of
problems that can occur with AFM files:
* Carriage-return characters (^M) at ends of lines.
This happens when you get incomplete translations from PC
files, which use carriage-return-line-feed combinations at
ends of lines.
Solution: edit away the carriage returns. Make sure the
lines are terminated only by line-feed characters.
* Spaces or tabs at ends of lines.
Fixed in NeXTstep 3.1.
* Missing fields.
NeXTstep DEMANDS that certain fields be present in the AFM
file. Required fields are: FontName, FullName, FamilyName,
Weight, EncodingScheme, and ItalicAngle. If any of these
fields are missing, you will get the <<Unusable Font>>
message.
Solution: fill in the required fields.
* Incorrect Weight field.
buildafmdir accepts only a certain set of values for the
Weight field. Acceptable values are: "Ultra Light", "Thin",
"Light", "Extra Light", "Book", "Regular", "Plain", "Roman",
"Medium", "Demi", "Demi-Bold", "Semi-Bold", "Bold", "Extra
Bold", "Heavy", "Heavyface", "Black", "Ultra", "UltraBlack",
"Fat", "ExtraBlack", and "Obese".
* Character information count mismatches.
AFM files contain several sets of information which are
introduced by a "Startxxxxx nnn" line where the xxxxx is the
name of the section (such as StartCharMetrics) and nnn is the
purported number of lines of information of this type to
follow. Sad to say, many many AFM files supplied by vendors
and others are such that the actual number of lines of data
do not match the number stated on the Startxxxxx line. When
this error occurs in the AFM file, buildafmdir emits a Parse
Error message to the console and the font will be marked
unusable. The parse error messages from buildafmdir is of
the form:
Parse error nnnnnnnn xx yy
where nnnnnnnn is the error number, xx is the number of lines
of information claimed to exist, and yy is the number of
lines actually read. The nnnnnnnn are are:
10000011 mismatch in the StartCharMetrics section
10000012 mismatch in the StartTrackKern section
10000013 mismatch in the StartKernPairs section
10000014 mismatch in the StartComposites section
10000015 mismatch in a composite character specification
I have converted many fonts from the Berkeley Macintosh User
Group CD ROM and fully half of the supplied AFM files are
incorrect.
* Other AFM file errors.
Parse error numbers 10000001 through 10000010 means some kinds of
syntax errors in the AFM data file. Any of these errors mean that
the AFM file is truly hosed.
Subject: 7.3. Porting fonts to the NeXT
Porting PC/Unix Type 1 Fonts
============================
You must have the .pfb and .afm files
A PC Adobe font is stored in binary format, so the first step is to
convert it to ascii.
There are a couple of utilities out there which can do this. I think
t1utils can do it, and there is a nice utility called pcATMfont2Next
which has a couple of tools to do this (unfont and pfb2ps). Look for
the file pcATMfont2Next.tar.Z; it is available on many ftp sites.
Also, since NeXTstep run on Unix, there is the customary problem of
converting the CRs (carriage returns) that PCs use to the LFs
(Linefeeds) that Unix uses. The easiest way to do this is to use tr to
delete the octal for the CR character from both the .afm and outline
file. The command to do this is:
tr -d '\015' < inputfile > outputfile
The unfont program will do this automatically when it converts the .pfb
file, but pfb2ps does not. I'm not sure if t1utils' utility does or not.
Once you have the outline file, you can go ahead and install it by the
process outlined above.
Otto J. Makela (otto@jyu.fi) posted a terrific cshell script to
comp.fonts, which automates just about everything for you. It converts
the .pfb to ASCII format, extracts the name from the FontName field,
creates the font folder, copies in the component files with the correct
name, and runs buildafmdir and cacheAFMData when done. A newer version
of this script is now available from the standard NeXT step archives
(Sonata, etc.).
Porting Mac Type 1 Fonts
========================
A variety of programs and scripts exist to convert Macintosh format
Type 1 fonts to UNIX format. Their ability to do a complete job
varies. Common traps which naive font converters fall into are:
* not dealing with Macintosh POST which are out of order.
* not dealing with Macintosh POST which are interspersed with other
resources.
* not dealing at all with POST Type 4 resources where the font
program starts in resource fork of the file but the remainder of
the data is in the data fork.
Most naive converters we've looked at have this problem. This
means that most Type 3 fonts won't convert at all.
* not dealing with MacBinary headers.
Subject: 7.4. Font availability
[ The archive site at sonata.purdue.edu seems to have disappeared. ]
Subject: 7.5. Why can I only install 256 fonts on my NeXT?
Included to NS3.0 there's a new 'buildafm'-routine (for non-NeXTers:
'buildafm' is a shell script which announces a new font to the
computer) at /usr/bin/buildafmdir. The new one only allows to install
about 256 fonts. Running the new 'buildafmdir' to install a new font
surpresses every font above this number. Workaround: Re-install the
'old buildafmdir' from NS2.1 at /usr/bin/buildafmdir and everything
should be fine!
(thanks to: Rob Parkhill and d'Art Computers/Germany d'art)
[ed: and my thanks to Borris Balzer for sending this to me]
|