rcd@ico.isc.com (Dick Dunn) (04/30/91)
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. > > - "How do I make PFB files work on a postscript printer?" > > Any *real* PostScript printer should be able to use them just fine, assuming > a new enough version of the PostScript interpreter. You need a downloader of some sort which will get rid of the funny little headers. You can NOT just send a .pfb straight to a printer. (Well, you can, but the printer will just complain.:-) 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 -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...If you plant ice, you're gonna harvest wind.
jlr1801@aim1.tamu.edu (Jeff Rife) (05/02/91)
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. :-) -- Jeff Rife P.O. Box 3836 | "Because he was human; because he had goodness; College Station, TX 77844 | because he was moral they called him insane. (409) 823-2710 | Delusions of grandeur; visons of splendor; jlr1801@aim1.tamu.edu | A manic-depressive, he walks in the rain."
tim@int13.hf.intel.com (Timothy E. Forsyth) (05/02/91)
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)
henry@angel.Eng.Sun.COM (Henry McGilton) (05/04/91)
In article <1991May2.161359.5065@int13.hf.intel.com>, tim@int13.hf.intel.com (Timothy E. Forsyth) writes:
* ASCII format files with eexec information in HEX. This is the
* file type that can be downloaded to the printer and is the file
* type used on UNIX systems.
This is indeed the desirable format one needs for UNIX systems, given
the UNIX systems I use have nothing resembling a print manager.
* Mac format files use some kind of "resource" information to
* separate the sections and the eexec section is also in binary
* instead of HEX. . . .
* . . . and the book refers the reader to
* Apple for information about the Mac file format.
Yes -- this is documented in an Adobe document called something like
'Supporting Downloadable Fonts'. The Adobe document describes the
Mac 'resources', which are fancy names for `data types'.
HOWEVER, THERE'S A CATCH. On several occasions I have moved Mac font
files to my UNIX system using TOPS. In such cases there are 16#300
(768) bytes of glop at the beginning of the file, that do not in any
way resemble anything I've read about in any document, anywhere, at
any time. When I was writing a small program to convert Mac encoded
font files to UNIX all ASCII format, I determined by trial to skip
the first 16#300 bytes, and then all would be groovy.
I then spent roughly a YEAR asking Mac `experts' what the extra
16#300 bytes are, and received only the kinds of looks you get when
you ask a computer store salesperson a difficult question like `how
do you turn on the power?'. I formed my own theory that these bytes
are used by Mac file manager and when you open a file on Mac, file
manager shufles those extra bytes off somewhere and the application
never sees them. This is known as `extrapolating from a point'.
Eventually, a Mac knowledgeable person told me my theory was more or
less correct and skipping the extra glop was the Right Thing to do.
........ Henry