> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Edward W. Rouse > Sent: Thursday, August 21, 2008 3:20 PM > To: 'Post all your questions about iText here' > Subject: Re: [iText-questions] Extremely large PDFs > > It's due to the use of a byte array as the underlying data > structure which > has the 2Gb limit.
The problem is not there but in the xref table that only uses int pointers. > It would be a monumental undertaking to > redo iText to use > something else, so I completely understand why this may never > happen. It's not an impossible task (and it would certainly be easier than the work done on signatures) as long as a single object was not greater than 2G, a reasonable "restriction". The problem is that only a couple of people would benefit from it and none of the current developers has a need for it. Furthermore, iText is not that suited to process files with lots of objects, it does too much work beforehand and for a splitting program, for example, most of it is not needed and just takes time and memory. Paulo > And > really, how many situations require handling such huge files? > I would say > not many. > > Right now I am looking at ways to take very large files and > split them down > into more manageable subfiles to pass to iText. If it was a > simple beak on > pages I would be done already. The sticking point is having > to determine an > exact place for a page break so that all of the pages that belong to a > smaller pdf stay in the same subfile. That and preserving all of the > original bookmark info in the subfiles. > > But it's the challenges that keep the job interesting ;) > > Edward W. Rouse > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Le > Doyen, Loic > Sent: Thursday, August 21, 2008 4:05 AM > To: Post all your questions about iText here > Subject: Re: [iText-questions] Extremely large PDFs > > Hi, > > If I remember correctly, the 2G limitation is about the java > runner and you > will not able to exceed this size if you want to use java (maybe it is > solved in recently versions). > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Leonard > Rosenthol > Sent: mercredi 20 août 2008 23:22 > To: Post all your questions about iText here > Subject: Re: [iText-questions] Extremely large PDFs > > Check out the products from Appligent (http://www.appligent.com). > > Leonard > > On Aug 20, 2008, at 3:50 PM, Edward W. Rouse wrote: > > > At this point I am considering commercial solutions. So far > I haven't > > found any with Java API's or that can be run on a Unix (Solaris) > > command line. At least not any that have all of the features I need. > > > > Edward W. Rouse > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Leonard Rosenthol > > Sent: Wednesday, August 20, 2008 3:44 PM > > To: Post all your questions about iText here > > Subject: Re: [iText-questions] Extremely large PDFs > > > > I am not aware of any open source/free utilities that can > handle files > > that large - even to split them. I can think of a few commercial > > solutions... > > > > Leonard > > > > On Aug 20, 2008, at 3:00 PM, Edward W. Rouse wrote: > > > >> Ah, gloom. This is not going to go away and I am being forced into > >> supporting files that exceed the iText limit. I am hoping > that there > >> is a tool that can split such a large file in twain so I > can run the > >> pieces using my current iText based code. Does anyone know of a > >> utility, java or otherwise that can split a pdf of over 2Gb in size > >> into 2 roughly equals pieces on a bookmark? > >> > >> And preserve the bookmarks. My current process parses the bookmarks > >> to extract data and create smaller pdfs based on the bookmarks and > >> information contained therein. Having spent a lot of time getting > >> this working quite nicely with all of the goodness that comes with > >> iText, I am loathe to have to start over using some other > library. I > >> like iText and want to stay with it, but I also have to > handle those > >> insanely large files. > >> > >> Any suggestions? (Beating the customer about the head and neck is, > >> unfortunately, not an option) > >> > >> Edward W. Rouse > >> > >> > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >> Paulo Soares > >> Sent: Wednesday, August 20, 2008 1:16 PM > >> To: Post all your questions about iText here > >> Subject: Re: [iText-questions] Extremely large PDFs > >> > >> iText doesn't support files over 2G and I suspect that it > never will. > >> > >> Paulo > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] On > Behalf Of > >>> Edward W. Rouse > >>> Sent: Wednesday, August 20, 2008 5:44 PM > >>> To: 'Post all your questions about iText here' > >>> Subject: [iText-questions] Extremely large PDFs > >>> > >>> We are currently processing PDFs that we receive from a 3rd party > >>> process for a customer. These files are extremely large. > We recently > >>> hit a file size limit when trying to process a pdf that exceeded > >>> 2.2Gb in size. The error was > >>> > >>> > >>> > >>> Exception in thread "main" > >>> java.lang.IllegalArgumentException: Size exceeds Integer.MAX_VALUE > >>> at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:707) > >>> at > >>> com.lowagie.text.pdf.MappedRandomAccessFile.init(Unknown Source) > >>> at > >>> com.lowagie.text.pdf.MappedRandomAccessFile.<init>(Unknown Source) > >>> at > >>> > com.lowagie.text.pdf.RandomAccessFileOrArray.<init>(Unknown Source) > >>> at > >>> > com.lowagie.text.pdf.RandomAccessFileOrArray.<init>(Unknown Source) > >>> > >>> > >>> > >>> I took a look at this and found that the > FileChannelImpl.map takes a > >>> MapMode and 2 longs, but that MappedRandomAccessFile seems to be > >>> casting seeks, reads and pointers to int. As an example: > >>> > >>> > >>> > >>> 331 public void seek(long pos) throws IOException { > >>> > >>> 332 seek((int)pos); > >>> > >>> 333 } > >>> > >>> > >>> > >>> Is there any chance that this will be (or maybe has been) > changed in > >>> future releases to allow for files in excess of 2Gb? Personally I > >>> think this is bordering on the absurd, but customers want what > >>> customers want. Or am I using this wrong and there is > another way to > >>> process extremely large files? > >>> > >>> > >>> > >>> Edward W. Rouse Aviso Legal: Esta mensagem é destinada exclusivamente ao destinatário. Pode conter informação confidencial ou legalmente protegida. A incorrecta transmissão desta mensagem não significa a perca de confidencialidade. Se esta mensagem for recebida por engano, por favor envie-a de volta para o remetente e apague-a do seu sistema de imediato. É proibido a qualquer pessoa que não o destinatário de usar, revelar ou distribuir qualquer parte desta mensagem. Disclaimer: This message is destined exclusively to the intended receiver. It may contain confidential or legally protected information. The incorrect transmission of this message does not mean the loss of its confidentiality. If this message is received by mistake, please send it back to the sender and delete it from your system immediately. It is forbidden to any person who is not the intended receiver to use, distribute or copy any part of this message. ------------------------------------------------------------------------- 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
