Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 5/3/83; site ukc.UUCP
Path: utzoo!linus!decvax!harpo!floyd!vax135!ukc!iau
From: iau@ukc.UUCP (I.A.Utting)
Newsgroups: net.text
Subject: Re: Need help with DITROFF .ft 1 problem
Message-ID: <3999@ukc.UUCP>
Date: Mon, 21-Nov-83 09:28:01 EST
Article-I.D.: ukc.3999
Posted: Mon Nov 21 09:28:01 1983
Date-Received: Wed, 23-Nov-83 04:30:47 EST
Organization: Computing Lab. Kent University, England
Lines: 26


	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