[cups.development] Filters and rotation
Johannes Meixner
jsmeix at suse.de
Tue Apr 5 06:57:07 PDT 2011
Hello,
On Apr 1 15:06 Tim Waugh wrote (excerpt):
> I know how foomatic-rip works. :-)
I got a bit confused because you didn't wrote that you use the
term "foomatic-rip" for the whole "PS/PDF -> raster data" black box.
> The fact remains: PostScript (or PDF) goes in, and raster data
> comes out. At some point during this process, foomatic-rip (viewed
> as a black box) needs to rotate landscape documents as needed,
> just like pstoraster does.
In general I agree - but see below...
>> If you can get the actual PostScript which Ghostscript gets as input
>> as a file (e.g. gs-input.ps) run Ghostscript with its "bbox" device
>> (e.g. "gs -sDEVICE=bbox gs-input.ps") to get the actual PostScript
>> bounding box values which show if the actual PostScript has
>> landscape dimensions (i.e. if it is wider than high).
>
> I don't think you're suggesting that foomatic should do this as a matter
> of course.
Of course not.
I only liked to show a way for debugging how one could determine
the actual imaged area of PostScript code regardless of whatever
possibly wrong DSC comments in a particular PostScript file.
> The PostScript that foomatic-rip gives to gs is in the wrong
> orientation when you print a landscape PDF. The bounding box isn't very
> good for detecting that though. Here's what I get, for example, with a
> simple test document:
>
> %%BoundingBox: 57 524 176 536
> %%HiResBoundingBox: 57.023998 524.501984 175.607995 535.445984
>
> If I run 'gs -sDEVICE=x11' on the PostScript then I see a landscape
> document, just like the one that entered the filter chain originally.
Do not confuse the BoundingBox values with the Orientation value
and with whatever media related values.
All those values have different meaning.
Have a look at this example PostScript+DSC code:
---------------------------------------------------------------
%!PS-Adobe-3.0
%%BoundingBox: 99 99 301 201
%%Orientation: Landscape
100 100 moveto
300 100 lineto
300 200 lineto
stroke
showpage
---------------------------------------------------------------
In this example PostScript code the BoundingBox is intentionally
sufficiently small to fit on A4/Letter paper both in portrait
and landscape orientation.
This shows that the BoundingBox values cannot be used in general
to determine whether or not the content should be rotated.
Is the content meant as some kind of huge capital letter 'L'
or is the content meant as '___|'?
With 'gs -sDEVICE=x11 -sPAPERSIZE=a4' I get something like
_____________
| |
| |
| |
| |
| |
| |
| |
| | |
| ______| |
|_____________|
With landscape paper via 'gs -sDEVICE=x11 -sPAPERSIZE=ledger'
it shows me something like
___________________________
| |
| |
| |
| |
| |
| | |
| ______| |
|___________________________|
In contrast when I use a preview application like "gv",
it cares about the DSC comment "%%Orientation: Landscape"
and rotates so that I get with plain "gv" something like
_____
|| |
|| |
|| |
||___ |
-------
Regarding "preview application" see the Adobe DSC specification
which reads:
----------------------------------------------------------------
%%Orientation: Landscape
.... can be used by previewing applications ... to determine
how to orient the viewing window.
----------------------------------------------------------------
With a paper in gv using 'gv --media=a4' I get something like
_________________________
| |
| | |
| | |
| | |
| |___ |
| |
| |
|_________________________|
This is the same as the first 'gs -sDEVICE=x11 -sPAPERSIZE=a4'
output only rotated clockwise by 90 degrees.
As far as I understand the Adobe DSC specification it seems
'gv' does it right.
Now when this example PostScript+DSC code should be printed
with 'lp -d queue -o media=A4' I would like that the filtering system
(i.e. the whole "PS -> printer data" black box) does "the right thing"
to get the content printed on the paper as it is in the printer.
I would expect to get a printed A4 paper which comes out
of the printer like the following
_____________
| |
| |
| |
| |
| |
| |
| |
| | |
| ______| |
|_____________|
which is what my HP LaserJet 1220 PostScript printer results
when it prints this PostScript in raw mode and when I use
the Ghostscript driver ljet4 with foomatic-rip.
Now to Tim Waugh's
-------------------------------------------------------------------
PostScript output is "portrait" output for landscape-sized media:
%%Page: 1 1
%%PageBoundingBox: 0 0 842 595
%%BeginPageSetup
%%PageOrientation: Portrait
-------------------------------------------------------------------
Accordingly I use now this example PostScript+DSC code:
---------------------------------------------------------------
%!PS-Adobe-3.0
%%BoundingBox: 0 0 842 595
%%Orientation: Portrait
1 1 moveto
841 594 lineto
stroke
showpage
---------------------------------------------------------------
Both 'gs -sDEVICE=x11 -sPAPERSIZE=a4'
and 'gv --media=a4' show me something like
_____________
| |
| |
| |
| |
| |
| _--|
| _-- |
| _-- |
| _-- |
|-____________|
Accordingly when this is printed with 'lp -d queue -o media=A4'
the printout should look the same - i.e. it is cut at the right.
I get exactly this on my HP LaserJet 1220 PostScript printer
when it prints this PostScript in raw mode and when I use
the Ghostscript driver ljet4 with foomatic-rip.
This matches to the Adobe DSC specification which reads:
----------------------------------------------------------------
%%Orientation: Portrait
.... A portrait orientation indicates that the longest edge of
the paper is parallel to the vertical (y) axis.
----------------------------------------------------------------
As far as I understand the Adobe DSC specification it is correct
when the content is cut at the right for such PostScript,
i.e. when PostScript with DSC like
---------------------------------------------
%!PS-Adobe-3.0
%%BoundingBox: 0 0 842 595
%%Orientation: Portrait
---------------------------------------------
with a PostScript content which looks like
+---------+
|landscape|
| |
+---------+
gets printed like
+----+
|land|
| |
+----+
I assume that actually the PostScript+DSC is wrong in this case and
pstoraster has some best-effort error-correction attempts implemented
when DSC comments look contradicting to the actual PostScript content
so that it can print even wrong PostScript+DSC input to some extent
in a way as end-users usually expect it.
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
More information about the cups-devel
mailing list