🚀 go-pugleaf

In article <197@wjh12.harvard.edu>, bb@wjh12.harvard.edu (Brent Byer) writes:
> In article <921@hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
> >I've encountered the following bug in pic, and was wondering if
> >anyone has a fix.  I'm using the pic that came with DWB 2.0.

   [ description of problem with misaligned arrowheads in pic output ]

> The bug is not really in pic; anal analysis of pic's output
> will show it to be correct.  So, the problem is actually
> in some combination of ditroff and your post-processor.

  [ commercial message deleted ]

> It's because of this tighter-than-you-thought inter-relationship of
> { pre-processors, formatter, and post-processor } ...
>        ... support for a problem like this can be a futile nightmare.

Can you please elaborate on this inter-relationship?
Each of the elements in your list (preprocessor, formatter,
postprocessor) is nothing more nor less than a translator.
If the input to one of them is correct, then either its
output is correct or else it contains a bug.  Where is there
an inter-relationship?  If one of the translators produces
incorrect output and depends on its successor to correct its
error, this might be deemed an "inter-relationship".  Trying
to make such relationships work correctly all the time would
indeed be a futile nightmare.  Better to fix the bug in the
first place, no?  What am I overlooking?

With older versions of pic there was the problem of device
dependencies.  But the DWB 2.0 pic outputs all motions and
dimensions in inches so it is device independent.  As a quick
check, I just ran through my pic an input file which produces
vertical and oblique lines with arrowheads at both ends.  I
ran the resulting output through 4 different versions of
ditroff (including DWB 2.0), and each of those through 4
separate postprocessors from 4 different vendors.  Not a
misaligned arrowhead in the bunch.
-- 
	Jay Plett
	UUCP:	{cmcl2,ihnp4}!lanl!unm-la!jay
		{ucbvax,gatech}!unmvax!unm-la!jay
	ARPA:	jxyp@lanl.gov