Hi Scott, I implemented a pdf-resize utility on top of iText a while ago. The resize is done by reading the original pdf, modifing the coordinates in the MediaBox and CropBox of every page according to the desired paper size (content centralization is also handled in the algorithm), then saving the modified pdf using PdfStamper.
If this approach is taken, the resizing algorithm can take the rotation information into account when manipulating the coordinates of the MediaBox and CropBox. Best Regards, Ellen N. Zhao Scott Cupp schrieb: > Hello, > > I have an application that takes a source PDF in, and scales it to > some predefined sizes. I'm doing this by creating a new document, and > then grabbing each page from the source PDF, and adding it to the > output document. Recently, I encountered a title that uses the Rotate > directive in the Page object within the PDF. > > _Example Item:_ > *116 0 obj<</Contents 118 0 R/Type/Page/Parent 291 0 R/_Rotate > 180_/MediaBox[0 0 612 792]/CropBox[0 0 612 792]/Resources 117 0 R>> > endobj > * > When dealing with these, the PdfImportedPage object isn't picking up > the Rotate 180. As a result, the output document had the wrong > orientation on the pages that used this command. > > To correct the problem, I started poking at the iText source, and I > came across a single line change that needed to be made in the > constructor of the PdfImportedPage class. Line 69 needed to be > switched to use getPageSizeWithRotation(int) instead of > getPageSize(int). By making this change, I was able to fix the > problem using a transformation matrix on pages that have rotation > because the rotation value is now populated. > > That said, my concern is more for future issues. I wanted to find out > if there was a specific reason for using the getPageSize(int) call > instead of getPageSizeWithRotation(int)? If not, then would this be > something that could be added to the core code? I'd rather not > deviate from the actual released versions of iText in case we need to > upgrade to a future version. > > If anyone can provide some advice on this, it would be greatly > appreciated. > > Scott Cupp > ProQuest, LLC. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ------------------------------------------------------------------------ > > _______________________________________________ > iText-questions mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/itext-questions > > Buy the iText book: http://www.1t3xt.com/docs/book.php -- HaCon Ingenieurgesellschaft mbH Lister Str. 15 30163 Hannover Germany/Deutschland Tel. +49 511 33699-363 Fax. +49 511 33699-99 Email: [EMAIL PROTECTED] http://www.hacon.de Registry Court/Amtsgericht Hannover HRB 1712 Managing Directors/Geschäftsführer: Michael Frankenberg, Dr.-Ing. Marian Gaidzik, Dr.-Ing. Werner Kretschmer, Werner Sommerfeld, Dr.-Ing. Volker Sustrate, Peter Talke ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.1t3xt.com/docs/book.php
