gary@qubix.UUCP (Gary Wiedenmann) (11/17/83)
The new device independent TROFF seems to have lost some functionality
of the old nroff/troff. .ft x, where x is a number not a font name,
doesn't seem to be detected as a request to activate a font slot previously
loaded with a .fp command, but rather tries to load font x.out from the
font library. I didn't notice this until I checked out the macro
packages, such as MS, which use .ft x a lot. Anyone know whats going on?
Gary Wiedenmann
Qubix Graphic Systems Inc.
18835 Cox Ave
Saratogo, Ca. 95070
408-370-9229 x211
...{decvax,ucbvax}!decwrl!qubix!gary
...ittvax!qubix!gary
decwrl!qubix!gary@Berkeley.ARPAiau@ukc.UUCP (I.A.Utting) (11/21/83)
When I try to reproduce your problem, the intermediate language output looks fine. However, I noticed some time ago that some of the ditroff back-ends (dcan etc.) don't take enough notice of `x font ...' changes causing a new font to be loaded over an existing one (ie. they track font changes by position number irrespective of which real font is installed there). I have also noticed that strange fonts are called for if a character name appears in the DESC `charset' table but not in any of the font tables. Without knowing which back-end you're using, it's difficult to be more specific, but this note might give you some clues. In any event, I would suspect the back-end rather than ditroff itself. While I'm typing this, some more general observations: o Not all fonts are available at all point sizes. It would be useful to specify the available sizes for each font, rather than for the typesetter itself. o Has anyone any ideas on improving the (virtually non-existent) kerning facilities? o PIC (and maybe other pre-processors) sometimes cause word-space markers to be generated and sometimes not. When? Why? (I had hoped to use these markers to correct for kerning inserted by the back-end, but this effect makes it tricky). Ian Utting, University of Kent at Canterbury. UK. vax135!ukc!iau