Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!eagle!harpo!seismo!hao!hplabs!sri-unix!whaley@lbl-csam From: whaley%lbl-csam@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: none Message-ID: <120@sri-arpa.UUCP> Date: Mon, 19-Mar-84 18:49:03 EST Article-I.D.: sri-arpa.120 Posted: Mon Mar 19 18:49:03 1984 Date-Received: Wed, 21-Mar-84 05:11:41 EST Lines: 83 From: (Ken Whaley [cc])whaley@lbl-csam :Re:versatec printers and fan fold paper. > From unix-wizards-request@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> Message-Id: <8403021959.AA12877@merlin.ARPA> > Received: by merlin.ARPA; Fri, 2 Mar 84 14:59:07 est > Date: 2 Mar 1984 1459-EST (Friday) > To: unix-wizards@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@lbl-csam.ARPA ...ucbvax!lbl-csam!whaley