Greetings! I am using the following command to crop a PDF: gswin32c -dQUIET -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=pdfwrite -dFirstPage=1 -dLastPage=1 -o output.pdf -dDEVICEWIDTHPOINTS=237 -dDEVICEHEIGHTPOINTS=151 -dFIXEDMEDIA -c "<</PageOffset [-64 -396]>> setpagedevice" -f input.pdf My intention is to crop the input.pdf 3.4 inches from top boundary, 0.9 inches from left boundary, 5.5 inches from bottom boundary, 4.3 inches from right boundary, and everything seems to work fine and the output.pdf displays appropriately cropped while viewed on a desktop (Adobe, Chrome Browser etc). However when The same PDF is viewed on iOS or Android device, seems like the page shift has occurred along the dimensions mentioned and areas from uncropped regions are still visible. It almost seems like the page size did not work appropriately. Reading some online forums, I have also tried the following commands but none seems to have any cropping effect, even on a desktop viewer: gswin32c -dQUIET -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=pdfwrite -dFirstPa ge=1 -dLastPage=1 -o outupt.pdf -c "[/CropBox [64 396 237 151] /PAGES pdfmark" -f input.pdf gswin32c -sDEVICE=pdfwrite -dFirstPage=1 -dLastPage=1 -o output.pdf -dDEVI CEWIDTHPOINTS=237 -dDEVICEHEIGHTPOINTS=151 -dFIXEDMEDIA -c "237 151 translate 6 4 396 237 151 rectclip" -f input.pdf Any help offered is very much appreciated unless this is a bug! Many Thanks, Kaushik Chakraborti
(In reply to comment #0) > My intention is to crop the input.pdf 3.4 inches from top boundary, 0.9 inches > from left boundary, 5.5 inches from bottom boundary, 4.3 inches from right > boundary, and everything seems to work fine and the output.pdf displays > appropriately cropped while viewed on a desktop (Adobe, Chrome Browser etc). > However when The same PDF is viewed on iOS or Android device, seems like the > page shift has occurred along the dimensions mentioned and areas from uncropped > regions are still visible. It almost seems like the page size did not work > appropriately. Given that this happens on mobile devices it sounds to me like the PDF reader on the device in question has a bug. pdfwrite does not remove content which is not on the requested media, so if the PDF reader incorrectly sets the page size in some way, it is entirely possible that content which lies off the page will be visible. This does not appear to be a GS bug on reading the description. Its not possible to say anything more without seeing the relevant PDF files.
Created attachment 8645 [details] input.pdf
Created attachment 8646 [details] output.pdf that displays properly on desktop PDF viewers but not on mobile OSs
Many Thanks Ken for your valuable time. I am attaching the input.pdf and output.pdf - both seems to show fine on desktops but not on mobile devices. Please help! Thanks (In reply to comment #1) > (In reply to comment #0) > > > My intention is to crop the input.pdf 3.4 inches from top boundary, 0.9 inches > > from left boundary, 5.5 inches from bottom boundary, 4.3 inches from right > > boundary, and everything seems to work fine and the output.pdf displays > > appropriately cropped while viewed on a desktop (Adobe, Chrome Browser etc). > > However when The same PDF is viewed on iOS or Android device, seems like the > > page shift has occurred along the dimensions mentioned and areas from uncropped > > regions are still visible. It almost seems like the page size did not work > > appropriately. > > Given that this happens on mobile devices it sounds to me like the PDF reader > on the device in question has a bug. > > pdfwrite does not remove content which is not on the requested media, so if the > PDF reader incorrectly sets the page size in some way, it is entirely possible > that content which lies off the page will be visible. > > This does not appear to be a GS bug on reading the description. Its not > possible to say anything more without seeing the relevant PDF files.
Interestingly enough, when I crop the same file in Acrobat. it displays everywhere correctly! (In reply to comment #4) > Many Thanks Ken for your valuable time. I am attaching the input.pdf and > output.pdf - both seems to show fine on desktops but not on mobile devices. > Please help! > Thanks > > (In reply to comment #1) > > (In reply to comment #0) > > > > > My intention is to crop the input.pdf 3.4 inches from top boundary, 0.9 inches > > > from left boundary, 5.5 inches from bottom boundary, 4.3 inches from right > > > boundary, and everything seems to work fine and the output.pdf displays > > > appropriately cropped while viewed on a desktop (Adobe, Chrome Browser etc). > > > However when The same PDF is viewed on iOS or Android device, seems like the > > > page shift has occurred along the dimensions mentioned and areas from uncropped > > > regions are still visible. It almost seems like the page size did not work > > > appropriately. > > > > Given that this happens on mobile devices it sounds to me like the PDF reader > > on the device in question has a bug. > > > > pdfwrite does not remove content which is not on the requested media, so if the > > PDF reader incorrectly sets the page size in some way, it is entirely possible > > that content which lies off the page will be visible. > > > > This does not appear to be a GS bug on reading the description. Its not > > possible to say anything more without seeing the relevant PDF files.
(In reply to comment #4) > Many Thanks Ken for your valuable time. I am attaching the input.pdf and > output.pdf - both seems to show fine on desktops but not on mobile devices. > Please help! Your original file has both a /MediaBox and a /CropBox, when you set the new page size the /MediaBox is altered, but the CropBox is preserved. The mobile application is obviously (incorrectly) using the CropBox to display the content, instead of the intersection of the CropBox with the MediaBox. There are basically two ways to fix this. Firstly you could alter the PDF interpreter to not emit the /CropBox pdfmark which transfers the original setting. Secondly you could use ps2write to create a PostScript file, then pass the PostScript back through pdfwrite to get a PDF file. I would not really recommend either, I would suggest that you contact the developers of the mobile PDF viewing application adn tell tehm that its a bug.
(In reply to comment #5) > Interestingly enough, when I crop the same file in Acrobat. it displays > everywhere correctly! When you crop the file in Acrobat, it alters the CropBox so this isn't hugely surprising.
Thanks again Ken. I guess I am am trying to apply the cropbox like Acrobat does but struggling with the syntax. Could you please give me a little help as to what I am doing wrong? Also the PDF viewers on mobile are nothing but the standard inbuilt PDF viewer and iBooks in case of iOS and multiple companies on Android - and all are showing the same behavior. This is what I have got so far, but this is not creating any cropbox at all in my output file... gswin32c -dQUIET -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=pdfwrite -o output.pdf -c "[/CropBox [64 396 237 151] /PAGES pdfmark" -f input.pdf Many thanks!!! (In reply to comment #7) > (In reply to comment #5) > > Interestingly enough, when I crop the same file in Acrobat. it displays > > everywhere correctly! > > When you crop the file in Acrobat, it alters the CropBox so this isn't hugely > surprising.
(In reply to comment #8) > I guess I am am trying to apply the cropbox like Acrobat does but struggling > with the syntax. Could you please give me a little help as to what I am doing > wrong? Also the PDF viewers on mobile are nothing but the standard inbuilt PDF > viewer and iBooks in case of iOS and multiple companies on Android - and all > are showing the same behavior. Then they are all wrong, I would guess they are all built on the same code. > This is what I have got so far, but this is not creating any cropbox at all in > my output file... > > gswin32c -dQUIET -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=pdfwrite -o output.pdf > -c "[/CropBox [64 396 237 151] /PAGES pdfmark" -f input.pdf Basically, you can't do this with Ghostscript, Ghostscript is not the tool for this job. The PDF interpreter will write the CropBox for the page automatically and there is very little you can do to stop it. If you are a good PostScript programmer I can tell you how to do it, but its not the right solution anyway. I would suggest you try a different tool.
Thanks Ken for your valuable opinion. I am not a GhostScript expert by any means, so I am resorting to using pdfdraw to render the PDF as a PNG first, then using .Net to crop the base image into the smaller size, finally using PDFSharp to convert the image back to a PDF. I guess that is the best alternative I could come up with :-( Thanks once again for your help, support and honest opinions. Best, Kaushik (In reply to comment #9) > (In reply to comment #8) > > > I guess I am am trying to apply the cropbox like Acrobat does but struggling > > with the syntax. Could you please give me a little help as to what I am doing > > wrong? Also the PDF viewers on mobile are nothing but the standard inbuilt PDF > > viewer and iBooks in case of iOS and multiple companies on Android - and all > > are showing the same behavior. > > Then they are all wrong, I would guess they are all built on the same code. > > > > This is what I have got so far, but this is not creating any cropbox at all in > > my output file... > > > > gswin32c -dQUIET -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=pdfwrite -o output.pdf > > -c "[/CropBox [64 396 237 151] /PAGES pdfmark" -f input.pdf > > Basically, you can't do this with Ghostscript, Ghostscript is not the tool for > this job. The PDF interpreter will write the CropBox for the page automatically > and there is very little you can do to stop it. If you are a good PostScript > programmer I can tell you how to do it, but its not the right solution anyway. > > I would suggest you try a different tool.
(In reply to comment #10) > I am not a GhostScript expert by any means, so I am resorting to using pdfdraw > to render the PDF as a PNG first, then using .Net to crop the base image into > the smaller size, finally using PDFSharp to convert the image back to a PDF. > I guess that is the best alternative I could come up with :-( That's ugly. You can try this; create a file, put this in it: << /EndPage { pop 0 eq { [/CropBox [0 0 200 200] /PAGE pdfmark }if true } >> setpagedevice Then execute your command line, but put the name of the file with the above code *before* the PDF file to be processed. The Box in there is the llx, lly, urx, ury and you will have to fiddle the numbers accordingly. For me this created a reasonable CropBox. By the way, if you have these kinds of questions, this isn't the right place for them. GPL Ghostscript is supplied without support, but the developers can be found in the #ghostscript irc channel on freenode.net, where they have been known to answer questions, and many knowledgeable people can be found on stack overflow (www.stackoverflow.com)
Ooooh.. almost there... it even displays fine on the mobile devices now!! The only problem is I am getting 3 pages, with first two pages being cropped size and the 3rd page being bigger. Also the first and third pages are blank, the second page has the meat. Here is the command I tried: D:\Chakraborti\Desktop>gswin32c -dQUIET -dBATCH -dNOPAUSE -dNOPROMPT -dFirstPage =1 -dLastPage=1 -sDEVICE=pdfwrite -o almost_there.pdf crop.ps -f input.pdf Here is what's in crop.ps: << /EndPage { pop 0 eq { [/CropBox [0 0 200 200] /PAGE pdfmark }if true } >> setpagedevice And the almost_there.pdf is attached! (In reply to comment #11) > (In reply to comment #10) > > > I am not a GhostScript expert by any means, so I am resorting to using pdfdraw > > to render the PDF as a PNG first, then using .Net to crop the base image into > > the smaller size, finally using PDFSharp to convert the image back to a PDF. > > I guess that is the best alternative I could come up with :-( > > That's ugly. > > You can try this; create a file, put this in it: > > << > /EndPage { > pop 0 eq { > [/CropBox [0 0 200 200] /PAGE pdfmark > }if > true > } > >> setpagedevice > > > Then execute your command line, but put the name of the file with the above > code *before* the PDF file to be processed. > > The Box in there is the llx, lly, urx, ury and you will have to fiddle the > numbers accordingly. For me this created a reasonable CropBox. > > By the way, if you have these kinds of questions, this isn't the right place > for them. GPL Ghostscript is supplied without support, but the developers can > be found in the #ghostscript irc channel on freenode.net, where they have been > known to answer questions, and many knowledgeable people can be found on stack > overflow (www.stackoverflow.com)
Created attachment 8649 [details] Almost there...
Desperately trying to decipher postscript... I changed "pop 0 eq" to "pop 0 ge" and all the three pages are now same size... Next I will play with the "0" itself :-) (In reply to comment #13) > Created an attachment (id=8649) [details] > Almost there...
(In reply to comment #14) > Desperately trying to decipher postscript... > I changed "pop 0 eq" to "pop 0 ge" and all the three pages are now same size... > Next I will play with the "0" itself :-) I can only blame the lateness of the hour. Try this: << /EndPage { exch pop 0 eq { [/CropBox [0 0 200 200] /PAGE pdfmark true } { false } ifelse } >> setpagedevice
All I can say is THANK YOU! I am now going to crop 4 times for 4 areas from the single original PDF, and then merge the resulting 4 PDF's into 1 single one. I will not take more of your time, but just let me know if that can be done with a single call to GhostScript using some sort of postscript or I must make 4 + 1 individual ghostscript calls. Once again thanks Ken for all your help! (In reply to comment #15) > (In reply to comment #14) > > Desperately trying to decipher postscript... > > I changed "pop 0 eq" to "pop 0 ge" and all the three pages are now same size... > > Next I will play with the "0" itself :-) > > I can only blame the lateness of the hour. Try this: > > << > /EndPage { > exch pop 0 eq { > [/CropBox [0 0 200 200] /PAGE pdfmark > true > } { > false > } ifelse > } > >> setpagedevice
(In reply to comment #16) > I am now going to crop 4 times for 4 areas from the single original PDF, and > then merge the resulting 4 PDF's into 1 single one. Hmm, I did something similar to this for someone who wanted to take PowerPoint presentations or something, I don't remember exactly why it was wanted. The attached PostScript program does it, its commented so if it doesn't do what you want you can probably alter it. Mind you, I've no idea what it will do with CropBoxes, the test file I was working with didn't have any I don't think.
Created attachment 8650 [details] demo program
I do not think this is working or will work the way I expect. First of all it is running without errors but then not producing any output. Secondly I think conceptually it is going to slice the base page into multiple slices, but I my specifications may need to have overlapping cropping areas as well (please see attachment). So I think if there could be a way to simply run a loop using the earlier cropbox technique that would be what I need. Something like below: << /EndPage (loop 1 with x1, y1, w1, h1) { exch pop 0 eq { [/CropBox [x1 y1 w1 h1] /PAGE pdfmark true } { false } ifelse } (loop 2 with x2, y2, w2, h2) { exch pop 0 eq { [/CropBox [x2 y2 w2 h2] /PAGE pdfmark true } { false } ifelse } >> setpagedevice and so on. So with a single call to gswin32c, the loop will run 4 times for my 4 set of coordinates. Does this makes sense? (In reply to comment #18) > Created an attachment (id=8650) [details] > demo program
Created attachment 8653 [details] Cropping areas logic
(In reply to comment #19) > I do not think this is working or will work the way I expect. First of all it > is running without errors but then not producing any output. Secondly I think > conceptually it is going to slice the base page into multiple slices, but I my > specifications may need to have overlapping cropping areas as well (please see > attachment). It runs the original page 4 times, and makes 4 pages, from it. You are correct that they do not overlap. > So I think if there could be a way to simply run a loop using the > earlier cropbox technique that would be what I need. > Something like below: The syntax of EndPage doesn't permit what you are trying to do here, which is why the pdf_slice program doesn't do it that way. You should use pdf_slice. ps as an example of how to approach the problem, rather than a complete solution. > and so on. So with a single call to gswin32c, the loop will run 4 times for my > 4 set of coordinates. Does this makes sense? Yes, but I'm afraid we are already well beyond the scope of support we can offer to free users. If you aren't able to refactor the program to do what you need, perhaps you can find someone else who speaks PostScript well enough to do so. Otherwise I'm afraid you will have to stick with multiple passes.
Ken, Thank you so much for all the support you have provided so far. I will part ways from here and will venture into public forums etc. Once again I truly appreciate all your help with this. Many thanks, Kaushik (In reply to comment #21) > (In reply to comment #19) > > > I do not think this is working or will work the way I expect. First of all it > > is running without errors but then not producing any output. Secondly I think > > conceptually it is going to slice the base page into multiple slices, but I my > > specifications may need to have overlapping cropping areas as well (please see > > attachment). > > It runs the original page 4 times, and makes 4 pages, from it. You are correct > that they do not overlap. > > > So I think if there could be a way to simply run a loop using the > > earlier cropbox technique that would be what I need. > > Something like below: > > The syntax of EndPage doesn't permit what you are trying to do here, which is > why the pdf_slice program doesn't do it that way. You should use pdf_slice. ps > as an example of how to approach the problem, rather than a complete solution. > > > > and so on. So with a single call to gswin32c, the loop will run 4 times for my > > 4 set of coordinates. Does this makes sense? > > Yes, but I'm afraid we are already well beyond the scope of support we can > offer to free users. If you aren't able to refactor the program to do what you > need, perhaps you can find someone else who speaks PostScript well enough to do > so. > > Otherwise I'm afraid you will have to stick with multiple passes.