Path: utzoo!telly!eci386!ecicrl!clewis
From: clewis@ecicrl.UUCP (Chris Lewis)
Newsgroups: comp.lang.postscript
Subject: Re: Novice looking for troff -> postscript conversion (long)
Keywords: troff DWBII
Message-ID: <890@ecicrl.UUCP>
Date: 18 Oct 90 16:53:31 GMT
References: <864@jonlab.UUCP> <874@ecicrl.UUCP> <1990Oct12.163552.8448@bradley2.bradley.edu> <883@ecicrl.UUCP> <1990Oct16.145303.20446@bradley2.bradley.edu>
Reply-To: clewis@ecicrl.UUCP (Chris Lewis)
Organization: Elegant Communications Inc., Ottawa, Canada
Lines: 61

In article <1990Oct16.145303.20446@bradley2.bradley.edu> brad@ds3.bradley.edu (Bradley E. Smith) writes:
|clewis@ecicrl.UUCP (Chris Lewis) writes:
|Well to make a long story shorter.  I have two packages that take
|ditroff and make postscript.
|...   By using the same ditroff output, the 2 programs
|produced different results (tpscript being wrong).
|... What would fail is the column of numbers would not line up straight
[using "." as leader]

|tpscript sends an horp position then a word. Each word being
|in a 'NNNN X (text_here)s'.  The tab fill char, which is a '.'
|would be put altogether ( "NNNN X (......)s" ).  What I changed
|tpscript to do is to send out "NNNN X (.)s" for each character that
|is not "a-z" or "A-Z".  This increased the size of the output but
|it worked.

|The fonts and DESC are the ones that came with tpscript, and another
|program using the same output works.  So I felt the problem was and
|is with tpscript.

|One a side note I looked at the postscript output and couldn't find
|anything wrong with it (all the X positions added up right).  The
|only thing I can think is that the character '.' is narrower than
|the font table.  But if this is so then why didn't the other program
|have a problem?

There's two possibilities:
    1) the width table is truly wrong by a bit.  If the other program
       doesn't do as complete a job of coalescing characters into single
       show commands, (even to the extent of drawing each character
       separately), the error in the width table would accumulate in
       the case of tpscript, but perhaps not in the other package.
       I seem to remember tpscript generating relative moves.
    2) Tpscript has an internal width truncation problem.

I had both problems when I introduced this kind of optimization into
psroff - I needed to round-off the numbers in the width tables when
I scaled them to CAT-style width tables.  In long words, the cumulative
effect could have words overlap - the word started at the proper place,
but the word was longer or shorter than CAT troff thought when drawn
using the engine's width tables as opposed to the width tables generated
by tpscript's postscript program and then scaled to CAT widths.  Without
the optimizer, this didn't matter - because each character was shown
separately using absolute X positions, and the error didn't accumulate to
something brutally obvious.  (after the fact, I discovered that it was 
barely visible even between single characters).  Once I carefully 
rounded off the scaling, it worked perfectly.

The second problem was truncation in the calculation of X-position
after each character was added to an accumulated string.  Sometimes
the calculation got far enough to terminate the string accumulation
(degradation of optimization, not accuracy).

I've used tpscript but haven't noticed this problem before.  I'll
send your example off to someone who has current access to a tpscript
configuration (actually, CAT troff | psroff | tpscript).
-- 
Chris Lewis, Phone: TBA
UUCP: uunet!utai!lsuc!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request@eci386)
Psroff mailing list (psroff-request@eci386)