Re: groff-1.19: setpagedevice prevents printing

[Werner LEMBERG]

>       groff-1.19 added a setpagedevice command to its output via
>       code in the file src/devices/grops/ps.cpp; setpagedevice was
>       not used in earlier versions.  That command appears in the
>       output PostScript as
> 
>       << /PageSize [ 595 842 ] /ImagingBBox null >> setpagedevice
> 
>       preventing printing on at least HP LaserJet 4M and Lexmark
>       Optra/S laser printers.  No printed output was produced on
>       either of them: the print job was just silently swallowed.

Dear Nelson,


it seems that you've missed the following in the NEWS file:

  o The paper size is now emitted via the %%DocumentMedia and PageSize
    mechanisms so that it is no longer required to tell `gv' or
    `ps2pdf' about the paper size.  The `broken' flag value 16 omits
    this feature (the used PostScript command `setpagedevice' is a
    LanguageLevel 2 extension).  Patch by Egil Kvaleberg
    <address@hidden>.

The broken flag can be set either with adding 16 to the `-b' option
value for grops (e.g. `-b16'; this is `-P-b16' if called by groff the
program) or by adding 16 to the value of the `broken' command in the
devps/DESC file.

>       As an experiment, I replaced those A4-format settings with US
>       A-format settings: 612 792.  The file then printed correctly
>       on both printers.

Hmm.  This looks like another bug.  Basically, groff's configure
script has code to automatically detect whether the default paper is
`letter' or `A4', setting a proper default value for `papersize' in
the DESC files.  The corresponding code is in groff's aclocal.m4,
function `GROFF_PAGE'.  It seems to fail for you.  Can you investigate
that?

> COMMENTS:
>       I have previously needed to include groff output as figures
>       in other documents, including ones set by groff and by TeX. 
>       
>       In both cases, it took substantial work to massage the
>       groff-produced PostScript to get it to work correctly as an
>       inserted figure.  
> 
>       The problem is that groff produces operators which modify the
>       underlying page transformations, interfering with attempts to
>       scale, translate, and rotate the image at the current point by
>       the inserting application.
>
>       For example, try this:
> 
>               % groff -man /usr/man/man1/ls.1 > ls.eps

grops has no support for computing %%BoundingBox; its main function is
to output groff documents to a printer.  It would be nice if someone
adds that, but until now this hasn't happened.  Note that this is a
non-trivial problem which even dvips doesn't solve properly (namely,
it ignores included graphics).

Anyway, if you limit groff to output a single page you results are
becoming much better:

  groff -o 1 -man ...

BTW, dvips has the same behaviour as groff: Without specifying option
-i (or restricting to a single page), multiple pages in a document are
overlaid.

Please provide an example that `groff produces operators which modify
the underlying page transformations'.  AFAIK, this is not correct.
groff encapsulates each page with a save/restore pair which is the
right thing to do, I think.

>       Part of the problem is a lack of a proper %%BoundingBox
>       comment in the groff output: that is where the default
>       page dimensions should appear.

To get a bounding box (printed on stderr) you can try this:

  gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=bbox ls.eps

It should be then not too difficult to write a small script which
replaces the `%!PS-Adobe-3.0' line with `%!PS-Adobe-3.0 EPSF-3.0',
inserts the output of the above command, and concatenates the rest of
the original groff output (filtering out invalid PS commands like
`setpagedevice').


    Werner