I have used these options: gswin32c -sDEVICE=pdfwrite -sOutputFile=c:\temp\print\res1.pdf -q -dBATCH -dPDFFitPage -dNOPAUSE -c .setpdfwrite -f"c:\temp\op\test2.pdf" PDFFitPage option should ensure that result pdf will always be 8x11 (default size), right? It does not work for 2 attached samples: 1)v6.pdf - original is 8.5x11 (or at least acrobat says so), and the result should be the same, but it somehow comes to 8.5x5. It even cuts off bottom 30% of the page! 2)test2.pdf - original is 10x7, and result should be 11x8.5 (landscape), but it comes to 8.5 x 7.5. On a similar sample it would make a portrait page and squeeze the contents in bottom half of page. Please let me know how to attach the files - or I can email them separatelly.
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.