In line with the ISO 32000 standard for PDF, the page dimension limit is 14,400 "default user space units" in each direction. Normally these are Points (1/72 of an inch) so the limit equates to 200 x 200 inches.

It's possible to create a PDF file which sets a new default user space unit on a per-page basis (by defining the /UserUnit variable in the /Page object), and so can  create much larger physical page sizes at the expense of reduced accuracy for the placement of contents. Support for creating PDFs with UserUnit values is limited, but Adobe Acrobat and Reader will respect them where found. Here's a screenshot of the Acrobat properties dialog for one of our engineering test files (page size approx 236 miles), which opens just fine on Acrobat and Reader:

/UserUnit is a multiplication factor, so by default it's 1. Normally it's not included in the /Page object unless it's been changed. Setting a tag of /UserUnit 72 would make the page use inches instead of points, and so on.

Note that this is a scaling factor, so if you add or edit text on the page, Acrobat will use the base value in the dialogs. There are also some rendering bugs if the /Userunit value changes between pages, so I advise it be set the same for every page.

Acrobat can't do it without a plugin (it will retain a value if there's one in the file but won't add one). There are a number of plugins and tools for editing the low-level content of PDF files (PDF Can Opener, PDF Surgeon, etc) that could do it, and a number of CAD programs have the ability to write custom /UserUnit values when exporting. However it sounds like the files in this case have an incorrect value of the base page box (the /MediaBox tag) as if it was just a question of changing the units, the PDF would open fine and simply report a different page size on the properties dialog. It'd help to see a sample of one of the files which crashes.

That indicates the MediaBox contains an illegal value, and Acrobat is hard-limiting it. If the bounding boxes of items on the page also use illegal values, they won't display either.

The problem is that although the ISO PDF standard is explicit about the 14400 unit limit, there's nothing to stop other software vendors from making PDFs with larger values (14400 isn't the biggest number in the 32-bit address space). That's noncompliant but if their own software also ignores the rules when reading the value, it'll work in their own brand bubble.

For example, CorelDRAW's PDF engine will happily write anything into the /MediaBox array - I've got a file from CD which says

/MediaBox [-0.0000 -0.0000 85040.0 85040.0]

which of course Acrobat won't display. Acrobat is behaving correctly when it decides not to render the illegal-value content, but other applications don't care about the ISO standard. Some will allow anything, some won't read the /UserUnit tag even if it's present, some will just crash...

It's one of the reasons why people use Adobe software to create and view PDFs - you know that the files absolutely respect the standard.

Chris_Crossen wrote:

 

Sorry if I gave the wrong impression. Acrobat doesn't crash, it just displays a blank image. Document properties in Acrobat show the width to be 200.00 inches.

 

The same PDF displays correctly in the Evince Document Viewer and the properties there show the width to be 328.35 inches (834 cm) which is correct.

 

Glad to be of assistance.

As your PDFs start out with an illegal value in the MediaBox, simply adding the UserUnit tag won't help - you'd have to rescale the coordinates of every page object so they're all legal, and Acrobat doesn't currently have that ability. In the case you quoted, halving every coordinate and applying a UserUnit of 2 would bring everything back into spec, and I assume the file would then display correctly. Ultimately it's the fault of whatever is making the PDFs in the first place.

I agree it would be useful if a future version of Acrobat alerted the user to an illegal page size. Can't promise anything though.