steve@umiacs.umd.edu (08/31/89)
As it turns out, there's no real reason for troff's font width tables to be in a.out format. A font width table is essentially an array of 224 characters. Troff reads a font width table by opening the file containing the table, skipping the first 32 bytes (the supposed a.out header, but you should be able to put any garbage in here at all), and then reading the next 224 bytes into an array. The only reason I can think of for reading the widths in this way is that (a) you don't need to read them one at a time, which may have been a performance issue way, way, *way* back, and (b) by using 'cc' to build the arrays, you can just read the arrays back in without worrying about padding, alignment, or whatever. (Maybe for machines with 16-bit 'char' data types, this is an issue, but not for any Suns, or for DECstations, or for most other machines we're all used to dealing with.) Running 'trace' on troff can be quite instructive, by the way. If you use the SPARC a.out font width tables on your Sun-3 (or vice versa), you should have no problems, unless Sun did something really strange to their troff. -Steve P.S.: Never read the troff sources soon after eating. Some of the cruft there is incredible; look at the way .ev works some time, if you want to see something really scary... (It does make sense for a machine with only 64K of data space, I suppose.) Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742