🚀 go-pugleaf

In article <2369@psuvax1.UUCP>, ehrlich@psuvax1.UUCP (Dan Ehrlich) writes:
> Can anyone suggest a method for eliminating the cut marks that troff generates?
> When the output from ptroff (Adobe's TranScript troff script) get printed on
> the LaserWriter Plus there are cut marks at the top of the page.  Short of
> buying stock in the company that makes white out, any suggestions would be
> appreciated.  Thanks in advance.
> 


The problem you describe affects not only PostScript printers, but imPRESS,
QUIC, DDL, and all other devices driven by [di]troff.

The macro sets as delivered by most sources of UNIX and/or Documenters
Workbench contain explicit code to generate cut marks at the top of each
page.

List the macro sets (and any files included by same) and edit out the code.

(Suggestion to providers of UNIX systems and/or Documenters Workbench:
Please provide comments in your macro sets to allow such excision of
cut mark code in a clean and easy manner.  You might even consider defaulting
to NO cut marks given that most [di]troff output is CURRENTLY to page printers.)

In article <2369@psuvax1.UUCP> ehrlich@psuvax1.UUCP (Dan Ehrlich) writes:
>Can anyone suggest a method for eliminating the cut marks that troff generates?
>When the output from ptroff (Adobe's TranScript troff script) get printed on
>the LaserWriter Plus there are cut marks at the top of the page.  Short of
>buying stock in the company that makes white out, any suggestions would be
>appreciated.  Thanks in advance.

The cut marks are not being made by troff, but by direction of the macro 
package.  For example in the -ms macro package (/usr/lib/tmac/tmac.s) for
troff (ditroff is probably different, mine is in /usr/local/lib/ditmac/tmac.s),
there is a reference to the macro CM.  This macro generates the cut marks.

You can make this macro a ``noop'' by defining it in your input as null.
Viz. 	.de CM
	..

Or you can, as is often done in ditroff, only call it if the output is to 
a device like a Versatec that has continuous paper.

Happy printing.
Gary..
{ucbvax!sun,styx,altos86}!elxsi!gww

In article <2369@psuvax1.UUCP> Dan Ehrlich writes:

> Can anyone suggest a method for eliminating the cut marks
> that troff generates? When the output from ptroff (Adobe's
> TranScript troff script) get printed on the LaserWriter
> Plus there are cut marks at the top of the page.  Short of
> buying stock in the company that makes white out, any
> suggestions would be appreciated.  Thanks in advance.

The easiest way I've found to eliminate these bothersome
holdovers from the days of roll-fed typesetters is to edit the
macro packages you use, and replace the dashes in their
definition with spaces.  This way, if you ever need to, you can
re-insert the dashes.

As an alternative method, add

	.de CM (or whatever your macros use for cut marks)
	..

or

	.rm CM

to the head of each file, but the first method is less hassle
and you dont need to remember to add the new "definition" or
"remove" lines.

:r all usual disclaimers

Geoff Walton
Software Publications
NCR E&M San Diego
{wherever}!ucbvax!sdcsvax!ncr-sd!geoff
Even the smallest problem becomes unsolvable if enough meetings
are held to discuss it.

In article <2369@psuvax1.UUCP>, ehrlich@psuvax1.UUCP (Dan Ehrlich) writes:
> Can anyone suggest a method for eliminating the cut marks that troff generates?

The cut marks are inserted by the macro packages.  I cobbled up some
function redefinitions for the -ms and -me packages to oust the cut marks.
They are minimal changes from the preexisting ones, and I am sure could
be made shorter.  Here they are.

For -ms:
\" Kick out the cut marks at the bottom of the page by redefining a macro
.de @m
.@O 0
.lt 7.5i
.tl ''''	\" DRS changed
.@O
.lt
..

For -me:
\" Don't print the cut mark.
.	\"CM - cut mark
.de CM
.po 0
.lt 7.6i
.ft 1
.ps 10
.vs 4p
.tl ''''
.po
.vs
.lt
.ps
.ft
..

Be careful, for old troff the software that converts the C/A/T output
to whatever your printer wants may depend upon those cut marks.  We
had some software that did.  ditroff has a page command that the
device dependent driver can use to start a new page, old troff
doesn't and the cut marks are about as good as you can do.

--------------------------------------

	rusty c. wright
	rusty@weyl.berkeley.edu
	ucbvax!weyl!rusty

It is perhaps too late for old troff, but I wish to offer an
observation:

Cut marks, if any, should be generated not by the input macros,
nor by the formatter, but by the post processor.

(The formatter must, of course, tell the post processor where each
page break occurs.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

> In article <2369@psuvax1.UUCP>, ehrlich@psuvax1.UUCP (Dan Ehrlich) writes:
> > Can anyone suggest a method for eliminating the cut marks that
> > troff generates?
> 
> The cut marks are inserted by the macro packages. 
> (-ms and -me solutions described)
For -mm, just put the line

	.rm )k

at the beginning of the document.


Paul Kleppner
VenturCom, Inc.
617/661-1230
{seismo!harvard,genrad!mit-eddie}!cybvax0!vcvax1!paul

In article <2369@psuvax1.UUCP> ehrlich@psuvax1.UUCP (Dan Ehrlich) writes:
> Can anyone suggest a method for eliminating the cut marks that troff
> generates?  When the output from ptroff (Adobe's TranScript troff script)
> get printed on the LaserWriter Plus there are cut marks at the top of the
> page.

	Ptroff is a shell script that essentially runs "troff | pscat |
lpr" with the proper assortment of arguments to the various commands.  One
of the arguments to pscat (the C/A/T to PostScript translator) specifies a
Y offset to be used.  We just made the offset big enough to push the cut
mark out of the image area.  Quick and dirty, but it works.  Ah, if only
all troff problems were that simple to solve!
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

"you can't spell deoxyribonucleic without unix!"

> For -mm, just put the line
> 	.rm )k
> at the beginning of the document.

Um, could we please make that something like

	.rm )k		\" suppress cut marks

so that the poor clod who has to work on your document ten years from
now can tell what's going on?  I doubt that this particular feature of
mm is documented (if it is, I still suggest the comment, but less strongly).
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

In article <2547@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>In article <2369@psuvax1.UUCP> ehrlich@psuvax1.UUCP (Dan Ehrlich) writes:
>> Can anyone suggest a method for eliminating the cut marks that troff
>> generates? 
>We just made the offset big enough to push the cut
>mark out of the image area.  Quick and dirty, but it works.  

Wow, kludge :-).  The cut marks are in the macros, so you'll need to
modify the appropriate files.  The -ms macros have a .CM macro that
does the dirty deed, and -mm uses a three-part title to stick them in.
I forget how -me and -man do the cut marks, but it should be similar to
one of the above.
-- 
Melinda Shore                               ..!ihnp4!gargoyle!sphinx!shor
University of Chicago Computation Center    XASSHOR@UCHIMVS1.Bitnet

In article <4880@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> 
> Cut marks, if any, should be generated not by the input macros,
> nor by the formatter, but by the post processor.

Which would probably make it a royal pain for the user to modify cutmarks
for smaller pages (e.g., five by nine inch pages).  It is relatively
easy for me to edit the macros.  I don't want to have to deal with psdit
or daps or whatever.

				Robert Sleator
				tektronix!tektools!robs

>In article <4880@mimsy.UUCP> I wrote:
>>Cut marks, if any, should be generated not by the input macros,
>>nor by the formatter, but by the post processor.

>In article <2062@tektools.UUCP> robs@tektools.UUCP (Robert Sleator) writes:
>Which would probably make it a royal pain for the user to modify cutmarks
>for smaller pages (e.g., five by nine inch pages).

Not so.  Either you are printing on continuous roll paper or not.
If you are printing onto sheet paper, you want cut marks if and
only if you will use less than a full page; in this case, you can
add cut marks by writing or modifying macros.  If you are using
continuous forms, you will always want cut marks; the only variable
is their placement.  If the pages are larger than usual, and the
output language is properly designed, the postprocessor's cut marks
will mark the larger-than-normal pages; if not, the postprocessor's
cut marks will mark a normal size page, and you can then ignore
(or disable) these marks and use the same macros as in the sheet
paper case to generate the same cut marks.

Either way, it is wrong for the formatter to generate cut marks by
default, and it is wrong for a continuous roll output device not
to have cut marks by default.  But only the post processor (and
the user) knows whether the ultimate output is continuous or sheet
fed.  Yes, the formatter must be able to generate cut marks or
alignment marks, but it should not do so by default.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

 missed most of the discussion, but we use -

 .de )k
 ..

 And they dissappear quite nicely on standard sized output.

 Tom Merrick ATT BTL Andover, MA

> > Cut marks, if any, should be generated not by the input macros,
> > nor by the formatter, but by the post processor.
> 
> Which would probably make it a royal pain for the user to modify cutmarks
> for smaller pages (e.g., five by nine inch pages)...

No, you misunderstand the relationship between ditroff and postprocessor.
Ditroff *tells* the postprocessor where the page boundaries are -- the
postprocessor doesn't have to guess.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry