Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!bu.edu!snorkelwacker.mit.edu!think.com!spool.mu.edu!uunet!littlei!intelhf!int13!tim
From: tim@int13.hf.intel.com (Timothy E. Forsyth)
Newsgroups: comp.lang.postscript
Subject: Re: PFB headers (was Re: generating afm files)
Message-ID: <1991May2.161359.5065@int13.hf.intel.com>
Date: 2 May 91 16:13:59 GMT
References: <1991Apr25.175643.25619@milton.u.washington.edu> <15506@helios.TAMU.EDU> <1991Apr29.195913.5520@ico.isc.com> <15707@helios.TAMU.EDU>
Organization: Intel Corp., Desktop Computer Division, Hillsboro, OR
Lines: 56

jlr1801@aim1.tamu.edu (Jeff Rife) writes:
>In article <1991Apr29.195913.5520@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes:
>}jlr1801@aim1.tamu.edu (Jeff Rife) writes:
>}> >    - "What's that silly binary code doing on the PFB files at [archive]?"
>}> 
>}> That's part of the encoding of an Adobe Type 1 font.  It's documented.
>}
>}It is documented, but it's not part of the Adobe Type 1 font.  The .pfb
>}files are divided into chunks of data with a little header-descriptor on
>}each chunk.  This header is for the use of a PC-based downloader; it should
>}not be sent to the printer.
>}
>}You can tell it's *NOT* PostScript because the first byte has value 80 hex,
>}which is not valid for Level 1 PostScript.  In Level 2, 0x80 it would be an
>}indicator of a "binary object sequence"--which is NOT what the .pfb is.
>}
>I'm sorry, I must have been on drugs or something. ;->  I missed the point
>of the question entirely.  I assumed the first enquiry was concerning the
>hex bytes within the "currentfile eexec.....cleartomark{restore}if" section.
>I never even noticed the binary on at the beginning of the file.  I guess I
>just assumed the fonts were OK because I never had any trouble, and I hadn't
>done anything special, but I assume my application is taking care of it.
>}
>}The header consists of:
>}	- 0x80: flag byte
>}	- type byte:  1=text, 2=binary data, 3=EOF
>}	- length: 4-byte little-endian integer counting the number of data
>}	  bytes which follow
>Thanks for the info on this header.  I will file it, and stand corrected.
>It is so much fun to make a fool of yourself in front of millions of people.
>:-)

You both were right, there are (I believe) three different methods that
Type 1 outlines are stored for different systems.  First there is the ASCII
format files where all of the eexec information is in HEX.  This is the file
type that can be downloaded to the printer and is the file type used on UNIX
systems.  There is the "compressed" format used in the MS-DOS/IBM PC world,
which consists of header flags bytes 0x80, 0x81, 0x82, etc used to
distinguish between sections of the file in ASCII and sections in binary.
The only part of the IBM PC format file (also know with the .PFB extension)
that is in binary is the eexec section.  The Mac format files use some kind
of "resource" information to seperate the sections and the eexec section is
alson in binary instead of HEX.  Thus the IBM PC and Mac format files are
about 1/2 the size of the ASCII/HEX format files, saving disk space.  And,
yes, the IBM PC file format is documented in the Adobe Type 1 Font Format
version 1.1 book, and the book refers the reader to Apple for information
about the Mac file format.

Hope this clears things up, or at least doesn't make the water muddier.
(Hey, my Type 1 Font Format book is at home!  This is all from memory.)

Tim Forsyth
-- 
Tim Forsyth, Intel Corp., Desktop Computer Division, Hillsboro, Oregon, USA
Internet: tim@int13.intel.com or Tim_Forsyth@ccm.hf.intel.com
CompuServe: 74040,2712 (checked once a week)