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.
Adobe Type 1 fonts are available in NeXTstep format from RightBrain Software of Palo Alto. RightBrain are the authorised Adobe reseller for Type 1 fonts on NeXTstep. Adobe fonts for NeXTstep come with AFM files and a font installer for installing on NeXTstep and downloading to non-NEXT printers.
RightBrain Software 132 Hmilton Avenue Palo Alto California 94301 (415) 326-2974. info@rightbrain.com
Other vendors in general do not provide Type 1 fonts in a form suitable for UNIX/NeXTstep. In such cases you must obtain the fonts in either Macintosh format or PC (PFB) format. When you obtain fonts from other vendors, MAKE SURE you INSIST they supply AFM files. Fonts without AFM files can be converted to NeXTstep format, but it can be a big deal. Trilithon Software currently supply utilities to generate AFM files directly from the font, but you get only the character metrics -- other data such as kerning pairs is not in the font and cannot be synthesised.
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).
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 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.
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:
On a PC:
On a NeXT
There are scripts (installfont) available that can handle the installation process but here is how you do it manually.
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 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 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.
<
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.
Fixed in NeXTstep 3.1.
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
<
Solution: fill in the required fields.
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''.
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:
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:
I have converted many fonts from the Berkeley Macintosh User Group CD
ROM and fully half of the supplied AFM files are incorrect.
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. You'd probably be better off obtaining AfmBuilder from
Trilithon Software and building a new AFM file straight from the font.
Parse error nnnnnnnn xx yy
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