Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/answers/fonts-faq/part9

Internet Message Format | 1993-09-22 | 25KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kei.com!sol.ctr.columbia.edu!caen!nic.umass.edu!ymir.cs.umass.edu!ymir.cs.umass.edu!usenet
From: [e-mail] (Norman Walsh)
Newsgroups: comp.fonts,news.answers
Subject: comp.fonts FAQ: NeXT Info
Supersedes: <[e-mail]>
Followup-To: poster
Date: 22 Sep 1993 15:12:19 GMT
Organization: Dept. of Computer Science, Univ. of Mass (Amherst)
Lines: 642
Approved: [e-mail]
Distribution: world
Expires: 5 Nov 1993 15:10:25 GMT
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Norman Walsh)
NNTP-Posting-Host: ibis.cs.umass.edu
Summary: This posting answers frequently asked questions about fonts.
         It addresses both general font questions and questions that
         are specific to a particular platform.
Xref: senator-bedfellow.mit.edu comp.fonts:10179 news.answers:12794

Archive-name: fonts-faq/part9
Version: 2.0.2

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.

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.

  Where to Obtain Fonts for NeXTstep
  ==================================

  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
       [phone].
       [e-mail]

  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.

  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.  You'd probably be better off
       obtaining AfmBuilder from Trilithon Software and building a new
       AFM file straight from the font.

  This is Info file comp.fonts.faq.info, produced by Makeinfo-1.55 from
  the input file FAQ.texinfo.

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 ([e-mail]) 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.

  Note that it uses the unfont utility from the pcATMfont2Next package,
  so to use this you will need that too.

  Just take everything between the CUT HERE lines, save it into a text
  file, and make it executable with the chmod command or the Inspector.

       --------------CUT HERE---------------
       #!/bin/csh -f
       # Font install program -- 1992 by Otto J. Makela

       set progname="$0" todir=~/Library/Fonts
       set progname="$progname:t"

       if ( $#argv>0 && -d "$1" ) then

              set todir="$1"
              shift
       endif

       if ( $#argv == 0 ) then
              echo "usage: $progname [installdir] afmfile..."
              exit
       endif

       foreach afmfile ( $* )

           echo "${afmfile}:"
           set fontname=`tr -d '\015' < $afmfile | awk '$1=="FontName" {
       print $2 } '`

           if ( -d $todir/${fontname}.font ) then
                   echo "${progname}: font $fontname already installed"
                   continue
           endif

       # If there already is a pfa, no need to translate, otherwise convert
       to ascii
              if ( -f ${afmfile:r}.pfa ) then
                      mkdir ${todir}/${fontname}.font

                      cp ${afmfile:r}.pfa
       ${todir}/${fontname}.font/${fontname}
              else if ( -f ${afmfile:r}.pfb ) then
                      mkdir ${todir}/${fontname}.font
                      unfont ${afmfile:r}.pfb >
       ${todir}/${fontname}.font/${fontname}
              else
                      echo "${progname}: no pfa/pfb file for $fontname afm"
                      continue
              endif
       # Strip CR's from afm file
              tr -d '\015' < $afmfile >
       ${todir}/${fontname}.font/${fontname}.afm

              echo "installed as $fontname"
       end

       buildafmdir $todir
       cacheAFMData $todir

       ---------------CUT HERE-----------

  The original installfont script is available as a shar file from
  ibis.cs.umas.edu in /pub/norm/comp.fonts/installfont-for-NeXT.

  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.

  MacToPfa
  --------

  Trilithon Software provides a commercial NeXTstep `MacToPfa' utility
  which converts Mac to NeXTstep format and installs the converted fonts
  for you.  `MacToPfa' overcomes a lot of the problems which plague other
  font conversion schemes.

  MetroTools
  ----------

  MetroSoft provides a commercial NeXTstep Mac->NeXTstep utility as a
  part of their MetroTools package for NeXTstep.  MetroTools is a kind of
  Boy Scout Knife, containing a Mac to NeXTstep font converter, a Mac to
  NeXTstep sound converter, a screen saver, a dock extender, and others.
  MetroTools will not convert Macintosh fonts if it can't find AFM files.
  The font converter converts font formats and installs them on NeXTstep
  for you.

         MetroSoft,
         San Diego, California 94028
         [phone].
         [e-mail]

  Porting PC (PFB) Type 1 Fonts
  =============================

  Trilithon Software provides a commercial NeXTstep `PfbToPfa' utility
  which converts Mac to NeXTstep format and installs the converted fonts
  for you.  `PfbToPfa' overcomes a lot of the problems which plague other
  font conversion schemes.

Subject: 7.4. Font availability

  Public Domain fonts for the NeXT are available via anonymous FTP from
  sonata.purdue.edu, in the directory next/graphics/fonts.  The README
  for this file states that the directory is currently being restructured
  by the archive moderator, although fonts are still available in that
  directory.

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]