Bug 688359

Created attachment 1740 [details]
first sample

Created attachment 1741 [details]
second sample

Created attachment 1744 [details]
another example

I got another sample here where result pages are weird dimensions.
There is another issue with first page here - the picture on it moves way to
the left (outside of visible area) so the resulting first page looks empty
(except for the very border of the picture). This is probably different issue -
let me know if you want me to open a separate bug for this.

First sample has:
  /CropBox [0.0 432.0 612.1 1224.1 ]
  /MediaBox [0 0 612 1224 ]

To see the image you expect, try -dUseCropBox. Otherwise the image is
scaled down to fit the 14 inch length on the 11 inch paper. I don't
see clipping of the image (just the really reduced size).

Second sample has:
   /MediaBox [0 0 720 540 ]
   /CropBox [0 0 720 540 ]

PDFFitPage does not rotate to fit the page. The PDF file does not contain
the /Rotate key in the Page dictionary, so the viewing orientation is
preserved (to give upright text).

Third sample has:
   /MediaBox [0 0 1224 1224 ]
   /Rotate -90
   /CropBox [216 612 1008 1224 ]   %  for Page 1

   /CropBox [216 0 1008 1224 ]     % for Pages 2 and 3

This one shows a bug in PDFFitPage handling -- the /Rotate -90 value
is not being taken into account when the CropBox is used, this when
-dUseCropBox is specified, the image is not positioned correctly.

Hi Ray,
I don't quite understand your comments. Are you saying that the resulting pages
with dimensions of 8.5x5 and 8.5x7.5 are correct? I don't mind image being
scaled, nor I expect pdf to be rotated, but I do expect results to be on
letter-size dimensions (either portrait or landscape). Most of the other files I
work with produce excellent results, and even these ones look much better when
printed without PDFFitPage option.

Created attachment 1931 [details]
another clipping example

Here is another example that shows significant clipping of the image due to
incorrect resulting page orientation and size

Created attachment 2126 [details]
another example

Here is one more example where PDFFitPage really messes up.
I hope that this bug will finally get some attention.

It is not polite to add someone else to the 'cc' list.

Please refrain from such activity. If "leonardo" wishes to add himself
for some reason, he will do so.

The patch attached to http://bugs.ghostscript.com/show_bug.cgi?id=688124#c8 
also fixes the problem described here. I think the changes mentioned in a note 
at the end of point (C) in that comment are needed too.

Rev. 7999. fixes this problem.
Thank you, SaGS.

the "fix" for this bug was included in 8.60, but it makes result pdf sizes no
better at all. Here are the resulting sizes I got using the same command line on
8.60:

first example: 5.5 x 7.12
second: 11 x 8.25
third: 4.25 x 5.50
fourth: 5.5 x 7.57
fifth: 2.5 x 5.85

None of them is 8.5 x 11, as PDFFitPage should do!

The patch that was commited included the following changes:

(a) Fix: The CropBox was not always computed correctly, so part of 
    the page could appear cropped.

(b) Enhancement: Choose the output page to be portrait/landscape 
    depending on the source page being portrait/landscape. Before the 
    patch, GS sometimes fitted landscape pages on portrait paper (or 
    vice-versa), so the output was scaled more than necessary.

IMHO, this is what was reported and needed to be fixed. Both 
work OK.


Now about the reporter's new comment #11.

First, open the PDF with Ghostscript and you will see the "paper" 
is indeed 8.5x11in. Acrobat does not use the MediaBox (which is 
the "paper"), but the CropBox, for display.

Secondly, follow the advice in comment #4: "To see the image you 
expect, try -dUseCropBox.". The PDFs have large MediaBoxes and a 
small CropBox inside it. If you fit the large MediaBox on 
8.5x11in, the part corresponding to the small CropBox (the only 
one displayed by Acrobat) will be, naturally, small.

Now, at least one of the page dimensions shown by Acrobat will be 
8.5in or 11in. The other may be smaller than expected, because:

  - GS migrates the CropBox from the input to the output PDF;
  - When the width:height ratio of the input CropBox does not match 
    the paper's 8.5:11, the output CropBox cannot cover the whole 
    page (the aspect ratio must be maintained);
  - Acrobat uses the output CropBox to display the output PDF, so 
    that extra space, outside the destination CropBox, won't be 
    included in the "page size".

If you absolutely want Acrobat to show the page as 8.5x11in, you 
need to get rid of the CropBox in the output file. Currently, I 
don't know of any supported way to do this with Ghostscript. 
[Maybe someone else does.]

There exists a hack, however:

    gswin32 -sDEVICE=pdfwrite -o OUT.PDF -dPDFFitPage -dUseCropBox 
            -c "pdfdict /.writepdfmarks false put" -f IN.PDF

I have also looked at this. It may be that the 'Fit' logic is not using
the correct width and height values.

I get reasonable looking 'fit' if the page is square (e.g. -g700x700), but
things are clipped if the page is not square.

Created attachment 3332 [details]
Possible fix for: "Page cropped if -dPDFFitPage with -dFIXEDMEDIA"

As mentioned in comment #12, -dPDFFitPage chooses portrait or 
landspace to get the "best fit". According to PLRM LL3 Table 6.2, 
under the description for PageSize, this should succeed:

   "The order in which the dimensions are specified is immaterial; 
    that is, a requested page size of [a b] is considered to match an 
    input medium whose dimensions are specified as [b a]." ... " The 
    PostScript interpreter will set up the transformation from user 
    space to device space so that the longer and shorter dimensions 
    specified by PageSize are properly oriented with those of the 
    physical medium."

However, -dFIXEDMEDIA does not obey this rule; as documented, it 
forces "pages of other sizes or orientations to be clipped". Note 
that -g implies -dFIXEDMEDIA. -dDEVICE(WIDTH|HEIGHT)POINTS and 
-sPAGESIZE, without -dFIXEDMEDIA, don't lead to page clipping.

Attached patch makes -dPDFFitPage check for -dFIXEDMEDIA, and if true:
- suppress the portrait<->landscape switching;
- compute the scaling for the page as-is, in current orientation.

An alternate solution is to change -dFIXEDMEDIA to obey PLRM, but 
that would be an incompatible change.

Notes:

  - No change if no -dPDFFitPage. In this case, either the choosen 
    media is large enough, or pages are clipped because that's what 
    -dFIXEDMEDIA asks for.

  - The knowledge whether the page can be rotated or not must be 
    hard-coded into pdf_main.ps::/pdf_PDF2PS_matrix, it is not 
    possible to attempt a setpagedevice here and see what we get 
    for the PageSize. This proc is used, among other things, while 
    adjusting link destinations, so it must know, in the middle of 
    one page, the final orientation of any past or future page.

Hi SaGS, I tested your "hack" (-dUseCropBox -c "pdfdict /.writepdfmarks false
put") and it seems to work quite fine for all of these examples - thanks!

How safe is it to use it all the time? Is there any risk of using this option?
For example, could it cause clipping (losing information on page) in any other case?

This appears to have been fixed. Any further questions can be asked/answered
with the bug resolved (comments can still be posted).

Ghostscript 8.70 seems to have broken something here. I am getting the error on
the following script (that worked fine with 8.64):

gswin32c -sDEVICE=pdfwrite -sOutputFile=k:\temp\print\res2.pdf -q -dBATCH
-dPDFFitPage -dNOPAUSE -dUseCropBox -c "pdfdict /.writepdfmarks false put" 
-f"k:\temp\out2\mediabox.pdf"

here is the error message:

   **** Page has no /MediaBox attribute. Using the current page size.
Error: /stackunderflow in --index--
Operand stack:
   --dict:5/5(L)--   612.0   792.0   3
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval-
-   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   fa
lse   1   %stopped_push   1862   1   3   %oparray_pop   1861   1   3   %oparray_
pop   1845   1   3   %oparray_pop   --nostringval--   --nostringval--   2   1
1   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1156/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--   --dict:75
/200(L)--   --dict:106/127(ro)(G)--   --dict:285/300(ro)(G)--   --dict:21/25(L)-
-   --dict:2/6(L)--
Current allocation mode is local
GPL Ghostscript 8.70: Unrecoverable error, exit code 1

Created attachment 5347 [details]
mediabox missing sample

sample for the previous script

-dUseCropBox is broken in v. 8.70 .

When the option is requested but the file has no /CropBox attribute
it messes up the operand stack. Please see the bug 690676 for the patch.