🚀 go-pugleaf

[Sorry for the rearrangement, but the context is more or less correct]

In article <1612@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes:
>In article <1383@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
>>In article <1595@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes:

>>>You don't say which troff you are using.  If it is a troff text processor that
>>>provides output for the C/A/T phototypesetter, then the answer is you can't.

>>Psroff (1.0 thru 3.0) can do this with CAT troff when driving Postscript.
>>It even works with psfig in psroff 3.0.  I don't think any of the other CAT
>>troff to (anything) converters can do this - though you imply that pscat
>>might be able to.  (psroff 3.0 does this by faking \X'').  

>There must be something that I am missing.  Is your psroff a troff replacement
>or a postprocessor of troff output?  If it is a troff replacement, this is a
>whole different story, making CAT troff discussion moot.  If psroff is a
>post-processor to CAT troff, then how the Hell can psroff be told to include
>PostScript since things like \! and \X do not work.  Is there something in
>troff that I don't know about?  Is there a game that you are playing.

Psroff is a postprocessor for both CAT troff and ditroff.  It can generate
HPPCL with incremental downloading, Postscript and ditroff (eg: X windows
previewing).  It's been tested with literally dozens of different imaging
devices and systems (DPS, xtroff, xditview, LJIII builtin fonts, Pageview etc.)

Two games actually.

Game #1 (simplified):
	- There is no CAT code corresponding to the letter 'M'.  Eg: in
	  CAT output, 0115 can never occur.
	- So, you put this in your CAT troff input:
	    .tm "Mhello there"
	- And you use troff thusly:
		(troff -t ... 2>&1) | cat-2-whatever
	- Inside the cat-2-whatever, you then catch the 'M', and following
	  that, you get "hello there" in ascii terminated by a newline.
	  So, you just have to define your back-end command convention.
	  Such as font mounts, file inclusion, passthru, character extensions,
	  ".sy" emulation etc.
	- This stuff is wrapped in a variety of macros so you don't
	  lose normal operation of .tm (ie: macro error messages) etc.
	- Problems: this forces a break no matter what you do.  For ".fp"
	  assists and raw postscript inclusions this is not a problem.
	  It's also hard to see troff errors because there isn't a way
	  to disambiguate them from CAT codes.

Given source code to the CAT-2-whatever tool, game #1 is easy to implement.
(But I expect royalties.  Just kidding)

Game #2 (simplied): In the cat-2-whatever converter, implement a finite
automaton (state machine) to recognize certain sequences and extract the
backend commands from them.  The sequence psroff uses is roughly this:
	\ka\o'\(bs\(bs'<command>\(bs\h'\nau'
(mark current horizontal position in "a", overstrike two bs's, copy the command,
terminate with \(bs, and reposition to beginning). I use a perl script
to convert \X'...', \D'...' and non-CAT \(xx characters into the equivalent
\(bs sequences.  The command comes thru in CAT flash codes that have to be
converted back to ASCII.  As it turns out, the code for both of these mechanisms
has a lot in common.  At present, the FA can't always perfectly reliably
intercept the sequences, but it works well enough on everything except
complicated pic output.   Doing game #2 is complicated by the fact that
CAT troff prints "bidirectionally" (because the CAT is a mechanical device),
and that in psroff, it's in between several layers of buffering and 
output optimizer (Psroff's output postscript is very fast - close to
rated PPM even on old AppleWriters)

With CAT troff and psroff, you not only get \X'...' emulation, but
\D'...', ".sy" and an extended character set and a few other things I
can't think of at the moment.

With the optimizer, you can also use the "sed the postscript output and
mangle at suitable places" approach.  Your approach will work
with CAT troff & psroff too.  Or, at least it should (given that your
Postscript code is modified as necessary to take into account psroff's
imaging model).

><Using your method, or the other \! approach, or using \X directly requires
><you to do a lot more about allocating space in troff, scaling/placing the
><object, and making sure you don't blow up the "imaging model" that the
><postscript driver is trying to use.  (Eg: scales/rotates/translates buggering
><up subsequent troff output).

>If the original poster is using ditroff, then things like \! and \X can be
>made to work, since the output of ditroff is totally different than CAT troff.
>The "imaging model" is secured by the MB and PE procedures that I had in the
>reply that I did.

"Can be made to work" is rather different than "everything's automatic"
in psfig.  Given EPS's, psfig is trivial to use.  You say (roughly) to psfig:
	.F+ 2i
	file such-and-so
	.F-
And everything's done for you - page placement, space allocation, scaling
and all.  No need to know postscript or even raw troff.

>Like I asked above, how can CAT troff be told to do something that it wasn't
>built to do?

Genius wins out ;-)

>I replied with the information that I had and the software that I have been
>using.

I know that.  Just letting people know that there are alternatives that
eliminate these restrictions.
-- 
Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca
UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request@eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request@eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!