none

[whaley%lbl-csam at sri-unix.UUCP]

From:  (Ken Whaley [cc])whaley at lbl-csam

:Re:versatec printers and fan fold paper.
> From unix-wizards-request at BRL-VGR.ARPA  Fri Mar  2 12:37:32 1984
> Received: from BRL-VGR (brl-vgr.ARPA) by lbl-csam.ARPA ; Fri, 2 Mar 84 12:37:32 pst
> Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Mar 84 15:02 EST
> Received: From Purdue-Merlin.ARPA by BRL via smtp;  2 Mar 84 14:38 EST
> From: Christopher A Kent <cak at Purdue.ARPA>
> Message-Id: <8403021959.AA12877 at merlin.ARPA>
> Received: by merlin.ARPA; Fri, 2 Mar 84 14:59:07 est
> Date:  2 Mar 1984 1459-EST (Friday)
> To: unix-wizards at brl.ARPA
> Subject: versatec printers and fan fold paper
> 
> We have a Versatec 1200A on our VAX (4.2) that we use for troff output,
> among other things. We choose to use fan fold paper instead of roll
> paper; it's so much nicer not to have to cut up your output on a paper
> cutter.
> 
> Unfortunately, this is not all roses. All the standard macro packages
> insist on just putting out cut marks as part of the footer, and in
> order for us to use them, we have to hack them to put out a special
> command that causes a hardware form feed. It works fine, once the
> macros are fixed.
> 
> We have just recently converted to 4.2, and I tried to use vgrind for
> the first time last night, and discovered that its macro package hadn't
> been so hacked. I didn't feel up to it, but started thinking about the
> problem again. It's really a pain to have to modify every macro
> library; they're not portable, and we can't easily import other
> people's macros. Besides, we now have a Symbolics laser printer that
> understands cut mark page marks, so we either have two copies of each macro
> package or magic in the macro package to understand the output device;
> both undesirable.
> 
> It seems like the vcat program should be able to look for the cut marks
> and do the right thing. I inquired about this (I wasn't involved in the
> original solution), and was told that the cut marks don't always come
> out evenly spaced; they sometimes actually come out slightly over a
> page fold, so the form feed causes a blank page in the output. Or that
> if a person outputs cut marks you might get spurious form feeds. And so
> on.
> 
> On the other hand, I said to myself, the people that print troff output
> on 11" wide plotters after rotating must know where a page ends; how do
> they do it? Indeed, I can't believe that EVERYONE goes through this
> crap like we do! After all, the Symbolics printer seems to be able to
> parse the cut marks in the output stream.
> 
> So, does anyone have a better solution, or do you all use roll paper?
> 
> Cheers,
> chris
> ----------

	We too have had problems with the cut marks.  We have a Versatec V80
running under Version 7 UNIX that uses fan-fold paper.  There probably are 
many solutions, one of which is, as Chris said, modifying the macro packages 
themselves so as not to output the cut marks.  While this is not the most
desirable thing to do, there really is no way around it, and the modifications
are trivial to do at worst.   If you are running only one output device and 
you are sure that you never want cut marks, then delete or comment out the 
line(s) in the macros that put out a ".tl  (something)" line.   However, we, 
like most systems, output to different devices; so we chose to do something a 
little different.  Instead of just deleting the reference to the 
".tl  (cut marks)", we changed it to "if  !\nv   .tl '\(ru'..'\(ru'".

This conditions the printing of the title line on the value of a 
number register (we called it "v").  So then all typesetting to devices where 
cut marks are NOT wanted is:

		troff (or ditroff) [normal options...] -rv1

which sets the number register "v" to 1, and thus the ".tl ...." is not
processed.

				Kenneth Whaley
				Systems Group, Computer Services
				Lawrence Berkeley Laboratory
				Berkeley, CA.

whaley at lbl-csam.ARPA
...ucbvax!lbl-csam!whaley