Bug 694979 - Some EPS files do not rotate to Landscape when "-g..." option is supplied
Summary: Some EPS files do not rotate to Landscape when "-g..." option is supplied
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: 9.10
Hardware: PC Linux
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-28 05:46 UTC by Till Kamppeter
Modified: 2014-02-05 06:11 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
M_1_no_of_ppts.eps (22.03 KB, image/x-eps)
2014-01-28 05:46 UTC, Till Kamppeter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2014-01-28 05:46:07 UTC
Created attachment 10622 [details]
M_1_no_of_ppts.eps

See Ubuntu bug report

https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1242678

especially my comment #13.

evince is not able to display the attached EPS file if rotated to Landscape but displays it correctly if rotated to Portrait. This is caused by Ghostscript, always rendering it in Portrait orientation, independent which orientation is actually requested. It seems that evince cannot cope with the wrongly oriented raster output, displays a lot of warnings on the console, and shows a blank page.

Extracting the actual Ghostscript command line and reducing the command line to a minimum of arguments still showing the problem, it turns out that if the "-g..." option is supplied, independent whether the values form a Landscape- or Portrait-oriented rectangle, the file does not display in Landscape orientation.

With this command line all is OK:

gs -sDEVICE=x11 -c '<< /Orientation 3 >> setpagedevice .locksafe' -f ~/Documents/M_1_no_of_ppts.eps

Note that the numbers 1 and 3 after "/Orientation" request Landscape and the numbers 0 or 2 request Portrait. With Portrait there is never a problem.

The command lines

gs -sDEVICE=x11 -g574x402 -c '<< /Orientation 3 >> setpagedevice .locksafe' -f ~/Documents/M_1_no_of_ppts.eps

gs -sDEVICE=x11 -g402x574 -c '<< /Orientation 3 >> setpagedevice .locksafe' -f ~/Documents/M_1_no_of_ppts.eps

both show the problem with orientations 1 and 3 and work only correctly with orientations 0 and 2.

Also changing the output device, for example replacing "-sDEVICE=x11" by "-sDEVICE=ppmraw -sOutPutfile=out.raw" shows the same behavior.

The file M_1_no_of_ppts.eps is attached.
Comment 1 Ken Sharp 2014-02-05 06:11:48 UTC
Fundamentally, as far as I can tell, there is no bug here, though there may well be some misunderstandings.

Firstly its important to be aware that the dictionary argument to setpagedevice does not contain *instructions* to the interpreter, it contains a series of requests. The interpreter is supposed to attempt to match the requested media to the 'best' possibility amongst its various available media.

So when you set '/Orientation 1' you are requesting that the interpreter find landscape media if possible.

Further to this, EPS files don't actually have a Media size request, its not permitted for EPS files, so there is no further media request beyond the setup on the command line.

We start by setting up the page device dictionary with the media you selected, 574x402. Obviously this matches, so no further work is required. Then we call setpagedevice with an Orientation. The Orientation is merged with the existing dictionary contents, and the interpreter looks to see if it can examine the request.

Now, we only have one medium available (574x402), so we notice that this matches the requested media (574x402) if we *don't* rotate, and doesn't match if we do rotate. For reasons that escape me, in this case we opt to rotate the document 1 extra time, but the reasoning is pretty clear; the media matching causes the 'inability to rotate'

The reason this doesn't happen if you don't specify -g (and I might add don't specify -dFIXEDMEDIA) is because for file-based output we consider the media to be infinitely variable. There is a maximum you can set but its pretty big, so you are unlikely to hit it. The default media size (595x842 for me, YMMV) fits equally well whether rotated or not rotated, so the media matching routine happily selects the rotated medium.

Basically, this isn't a bug. If you want to rotate an EPS you absolutely should NOT be doing so by using /Orientation, which is a media selection parameter. You should instead use '90 rotate' or similar to set up the CTM before you render the EPS.