summaryrefslogtreecommitdiff
path: root/help/comp-fonts-FAQ/comp.fonts_FAQ:_NeXT_Info
diff options
context:
space:
mode:
Diffstat (limited to 'help/comp-fonts-FAQ/comp.fonts_FAQ:_NeXT_Info')
-rw-r--r--help/comp-fonts-FAQ/comp.fonts_FAQ:_NeXT_Info538
1 files changed, 538 insertions, 0 deletions
diff --git a/help/comp-fonts-FAQ/comp.fonts_FAQ:_NeXT_Info b/help/comp-fonts-FAQ/comp.fonts_FAQ:_NeXT_Info
new file mode 100644
index 0000000000..e59e68039f
--- /dev/null
+++ b/help/comp-fonts-FAQ/comp.fonts_FAQ:_NeXT_Info
@@ -0,0 +1,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]
+