lcn@philtis.UUCP (Leo C. Noordhuizen @ Philips CAD Centre) (06/01/89)
Is there a way to generate postscript output from the (unsupported) version of troff available under Ultrix 3.0, or do we have to get another version of troff like ditroff ? -- ---------------------------------------------------------------------------- Leo C. Noordhuizen uucp: mcvax!philmds!philtis!lcn Philips - Corp. CAD Centre phone: 31-40-735834 Building SAQ P343, 5600 MD Eindhoven, The Netherlands
treese@cirocco.crl.dec.com (Win Treese) (06/03/89)
In article <597@philtis.UUCP>, lcn@philtis.UUCP (Leo C. Noordhuizen @ Philips CAD Centre) writes: > Is there a way to generate postscript output from the > (unsupported) version of troff available under Ultrix 3.0, or > do we have to get another version of troff like ditroff ? The Transcript package from Adobe will convert troff output to PostScript. It also includes a converter for ditroff output, as well as some other useful utilities. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp.
steve@fnord.umiacs.umd.edu (Steven D. Miller) (06/03/89)
I'd love to know the answer to this, too. The Adobe TranScript package seems (without beating on it particularly hard) to compile and run without problems. Unfortunately, it seems (from the poking about I've done) that there's no way to get the DECstation troff to read *any* font width files, even those in /usr/lib/font. From what I see with trace(1), the -F option does nothing (i.e., no font width files are opened), and even running without -F, troff never opens any files in /usr/lib/font. I've also seen error messages from the DECstation troff that aren't in the VAX Ultrix troff source. Unfortunately, the 4.3BSD troff doesn't just drop in place, so now I'm waiting for the sources... If anyone else knows the answer to this, I'd love to hear it. RTFMs are (as always) welcome. (Not that I can find a troff man entry, but maybe I somehow didn't install it.) -Steve 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
kg@elan.UUCP (Ken Greer) (06/03/89)
From article <17859@mimsy.UUCP>, by steve@fnord.umiacs.umd.edu (Steven D. Miller): > I'd love to know the answer to this, too. The Adobe TranScript package seems > (without beating on it particularly hard) to compile and run without problems. > Unfortunately, it seems (from the poking about I've done) that there's no > way to get the DECstation troff to read *any* font width files, even those > in /usr/lib/font. If anyone else knows the answer to this, I'd love to hear it Briefly there are two types of troffs in the world (both written at AT&T): 1. C/A/T Troff, which is on SUNs, DECs, most BSD based UNIX systems. This troff was written for the C/A/T typesetter and has the character geometries hard coded (!) for the C/A/T. Using this troff to any other device (like a laser printer) will result it quite awful looking output. This troff is useless, in my most humble opinion, no matter what filter it's going with. (This is the troff you have, by the way.) 2. Device Independant Troff (often called diTroff), which was written (again by AT&T) when laser printers were starting to come of age. Ditroff uses font tables for each font, each which is unique also for each particular output device. If you're not driving a C/A/T, you should be using this troff. There is always a catch -- the first one's free; the second one ain't. You get what you pay for, as the saying goes. Where do you get diTroff? You can get a very buggy one from AT&T. Or, you can get an enhanced and supported one from one of only a few vendors in the country. The company I work for is one such vendor! We are also the formost. Our software (EROFF) is used extensively with site licenses at Hewlett Packard, SCO, GE, to name a few. For those interested in better looking troff output on laser printers, please feel free to contact the sales folks at the number below. (You can even call me, if you like!) Ken Greer Elan Computer Group, Inc. 888 Villa Street, 3rd Floor Mt. View, CA 94041 {ames,hplabs,uunet}!elan!kg 415-964-2200
steve@fnord.umiacs.umd.edu (Steven D. Miller) (06/10/89)
To summarize the message I was about to send, but thought better of: the troff on DECstations, like the troff on 4.3BSD and Ultrix VAXen, and on Suns running SunOS 3.2 and 4.0.1, *can and does* know about font width tables. You use -F to specify where to look, and it seems that you have to use .fp (i.e., '.fp 1 R') directives to force the width tables to be read. On all the above machines, including the DECstation, I get the desired behavior -- the tables are indeed read in. However, now that I look more closely at the release notes, I see that the DECstation troff has been modified to use ASCII-format font width tables. No doubt the folks at DEC ran into the same problem I had: the tables are compiled with cc, and a.out != COFF. I chose to write a COFF -> a.out font width table converter. The people at DEC chose to change the font width table format, which may be unwise, given the number of people Out There who are using font width tables they get from various sources, and which are all in a.out format. Sigh. Anyway, the new format doesn't seem to be documented anywhere that I yet know about. Also, it sure looks a lot like DEC has made a mistake, and is shipping the font width tables in the old format, even on DECstations. Both the Ultrix unsupported (RISC) tapes I have definitely have the old format files on them; I just went through the pain of checking them. Oops... (And, blast it, the 4.3BSD troff, if compiled on a DECstation, dumps core! Never debug troff on a full stomach!) So, does anyone Out There know anything about the new format, and can they describe it? -Steve 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