Pdf Spec

If you download 1.5, 1.6, or 1.7 from:

http://www.adobe.com/devnet/pdf/pdf_reference.html

on the first page of Appendix C, it states:

Quote:

---

PDF itself has one architectural limit: Because ten digits are allocated to byte offsets,
the size of a file is limited to 10¹⁰ bytes (approximately 10 gigabytes).

---

and yet, on the next page, the largest scalar 10 digit type is Integer:

Quote:

---

integer 2,147,483,647 Largest integer value; equal to 2³¹−1.

---

So, if a PDF is near 10 gig, and its xref table has a position near 10 gig, how could it possibly be read by an integer???

http://www.vbforums.com/attachment.p...postid=1797398

Can you in reality have a PDF file as large as the limit goes? The largest I've seen was about 100MB.
Usually limitations are some abstract numbers that are really hard to reach.

We just got one in the last week that was > 2.1 gig.

It's not uncommon to recieve > 1.5 gig files,
but the 2.1gig was unable to be opened in Acrobat Pro.

I knew I had read the spec said effectively that the upper limit is 10 gig, however I never saw one greater than 2 gig before, and the fact that Adobe's acrobat can't render the PDF seemed odd if they claim the 10 gig.

So I reread the spec, and saw that the Integer has the standard 2 gig limit.
Knowing that xref's values arre indeed 10 digits in length forced me to conclude that their designers are using the integer as the basis for extracting the objects byte positioning from the xref table, without allowing for the possibility of an xref value actually being greater than 2 gig.


So the processing of a PDF > 2gig is dependent on the base type of the applications pointers. PDFLib+PDI allows me to process such files, and I was able to chunk it in two, a little over 1 gig each.

These chunks then were renderable in acrobat, and our rips were also able to process them. {lol, the original, when lpr'd to our rips, would never arrive, and when I ftp'd them, and tried to use the "Print from File" option, the rip wouldn't even acknowledge it's existence. And it wasn't a Unix file limit issue either, since Unix easily reported its existence with ls -l.}

So It seems that:

A) 10 Gig IS the upper limit per spec, but Adobe effectively designs its apps to not be so flexible

or

B) Someone misgeneralized with the 10 gig information, not realizing that Adobe intended the limit to be the max value of integer, and not the max base 10 value of a 10 digit string.

I can understand if you guys are stress testing the acrobat itself.
Other than that whatever you do doesn't sound quite reasonable if you are creating files of that size regardless of type.
Why don't you just break it into smaller pieces? I don't get it.

We don't create our customers files.

unfortunately.

They just throw in everything and the kitchen sink; 1200 dpi images, hundreds of fonts, Lines of text that are single characters adjacent to each other {Thus creating an object per charecter instead of an object per line of text}, & when the product is supposed to be BW, They have CMYK, DeviceN, ICC profiles, multilayer images...

Objects outside of the pageframe, Unflattened line art that is composed of thousands of individual points, shades, and graphical elements,.,,

No optimization or common sense whatsoever.

:ShoulderShrug:

Well, either they work or they don't.
When they don't we try to pass on whats wrong & hope it helps them troubleshoot. Unless its a non-automated order, whereby we try to "fix" the file ourselves, after we suggest fixing it directly to the customer, unless they want to do it themselves.