[Phil]

Per article page width limit of 200 inches, PDFs have some constraints on their document sizes. While 200 inches on a side is plenty big for most applications (indeed, it could cover the Mt. Palomar Hale telescope's mirror), apparently some people have seriously tried to make larger documents.

In PDF Reference, Fifth Edition, version 1.6 one can read (paragraphe 171, page 1033) :

    In PDF versions earlier than PDF 1.6, the size of the default user space unit is fixed at 1⁄72 inch.
    In Acrobat viewers earlier than version 4.0, the minimum allowed page size is 72 by 72 units in default user space (1 by 1 inch); the maximum is 3240 by 3240 units (45 by 45 inches).
    In Acrobat versions 5.0 and later, the minimum allowed page size is 3 by 3 units (approximately 0.04 by 0.04 inch); the maximum is 14,400 by 14,400 units (200 by 200 inches).
    Beginning with PDF 1.6, the size of the default user space unit may be set with the UserUnit entry of the page dictionary.
    Acrobat 7.0 supports a maximum UserUnit value of 75,000, which gives a maximum page dimension of 15,000,000 inches (14,400 * 75,000 * 1⁄72). The minimum UserUnit value is 1.0 (the default).

So the size limitation turns out to be a matter of "UserUnit" value. The problem would be solved if this value was an option in [HTML to PDF converter wkHTMLtoPDF], something like : --user-unit (default : 1)

and

So it sounds like there are two different size limitations happening: by PDF version number and by Acrobat.

PDF < 1.6 -- User Space Unit fixed at 1/72"
>= 1.6 -- User Space Unit may be set (UserUnit)

Acrobat < 4.0 -- maximum 3240 units square (45")
< 7.0 -- maximum 14400 units square (200")
>= 7.0 -- maximum 14400 units square AND maximum UserUnit 75000 (15E6")

Given that Acrobat is probably by far the most used PDF reader* (or at least Adobe products are), what should our maximum page sizes be for a given PDF version? Can we count on just about everyone being at Acrobat 7.0 or equivalent? Remember that there are still some businesses and government agencies who mandate IE 6 (!) for browsers, so it may be safer to stick to older limits.

* How do Adobe Reader and PDF plug-ins for browsers map to Acrobat's versions?

Note that the referenced PDF document is not the latest version. I haven't dug through this part of the PDF 1.7 definition yet, but it sounds like the only change in PDF is (as of 1.6) that "UserUnit" may be set (default: 1 Pt, maximum 75000 Pt). Perhaps a warning should be issued if measurements exceed 14400 UserUnits (tough luck to pre-Acrobat 4 users with a 3240 limit, or perhaps we could add another warning for them).

Needless to say, such a change requires that we pay attention to the PDF version being output. That has to be implemented first.

[Phil]

I'll have to check if there are any further developments in the PDF 1.7 spec. Don't forget to use the PDF version check to specify a 1.6 minimum output, if we add a new method to explicitly specify User Units, and/or check for a media size in excess of 14400 points and automatically generate a User Units call. In the latter case, there should be a warning message that resolution has decreased (the PDF may be blockier or grainier -- I haven't tried it yet) and old Acrobats (< 7.0) will fail. This probably should be data carried along until final output (just like default MediaBox data -- Not passing Validation / #83), in case the user later explicitly requests a new value.

This still leaves the issue of what to do (if anything) about the use of earlier Acrobat readers and tools that either allow only a maximum 3240 point media size (Acrobat < 4.0) or don't allow a User Units setting (Acrobat < 7.0). Perhaps there could be a suppressible warning message that there will be problems with certain versions of Acrobat? It would be nice to generalize the warning check routine in case there are any other Acrobat-level warnings to implement in the future. In this day and age, is anyone still on backlevel Acrobat programs? Is it worth the bother? Perhaps it would be better to have a separate "lint" utility to read a PDF and warn if problems can be expected on certain Acrobat (and other tools) levels.

[Phil]

Need to fully investigate this UU scaling: must it be done before any coordinates are output? What happens if it changes in the middle of a page? If I have a line 72Pt long, and set UserUnits to 72, do I now just use a line 1UU long, or continue to use 72? What are the effects on output granularity -- would my pixels now be 1 inch square, and my coordinate grid likewise coarse? What happens to images?

[Phil]

What I'm leaning towards doing is the following:

• Don't worry about what Reader someone is using. If you choose to use User Units or larger documents, and someone is on a back-level Reader, tough. Maybe "contrib/" could have a "lint" of some sort that will point out potential problems, but that should be kept out of the base product.
• Allow either explicit specification of User Units at the beginning, or automatically set them if the MediaBox exceeds the limit of 200 inches or so (14,400 pt). Let the document creator worry about what happens if they change User Units in the middle of a page.

Over on wkHTMLtoPDF, there is discussion about virtually unlimited dimensions being needed (a document could be printed on a paper roll, of fixed width). If you have to set the MediaBox, I think you're going to run into that limit. There is also discussion about how to force a document to a single page of arbitrary size (within reason). One approach could be to start with some standard MediaBox (to also set the width). If something gets written at negative y, add -y to every vertical dimension (including the MediaBox). If the height exceeds 14,400 pt, that could be a problem (forcing User Units > 1.0, among other things). However, this might let us go to huge (15M in) page heights if desired. It might be best to write out the entire page (with lots of negative y values) and go through to add -y to everything all in one go, rather than each time it happens.

[Phil]

Some more fun... see https://forums.adobe.com/thread/1003116

/UserUnit scale  can be added to the Page Dictionary (just ahead of MediaBox) to map user space units to points (real world coordinate space). For example, /UserUnit 72.0 means your user units would be in inches (Letter size /MediaBox [0 0 8.5 11]). Resolution may suffer (blocky effect). UserUnit comes first, and then all other dimensions and coordinates (including MediaBox) come after, in User Space Units (points divided by the UserUnit, which is by default 1.0). Multiply any dimension or coordinate by UserUnit to get real world point size.

According to the article,

• Changing UserUnit from page to page may result in rendering anomalies. They recommend picking one UserUnit and using the same one for each page. In theory, you should be able to change UserUnit on each page, so this may be considered an Acrobat bug or limitation.
• While Acrobat adheres to the PDF standard of a maximum of 14400 User Space Units, some PDF writers and readers produce PDFs outside of the 14400 limit, with or without UserUnit. For PDF::Builder to import these and write out a PDF that Acrobat can successfully render, thought needs to be given to forcing a UserUnit entry and scaling down all dimensions and coordinates on a page by that amount!
• Adobe Distiller apparently does not support UserUnit, and is still limited to 14400 points (200 inches). Earlier PDF versions have smaller limits, and only readers supporting PDF 1.6 or higher (most, these days) support UserUnit.

We need to consider

• A new global setting for UserUnit, to be inserted on each page. This might include a flag indicating whether all user dimensions in calls are already scaled to this UserUnit, or PDF::Builder needs to divide each by UserUnit.
• Allow a per-page UserUnit setting, to override the global setting for this one page, but warn the user that there might be rendering difficulties on some readers.
• What to do when an existing PDF is read in that contains dimensions or coordinates in excess of 14400. Given that we normally don't process a read-in PDF, but just write it back out more or less intact (and tack on additional stuff), we might only be able to warn the user in the documentation and leave it at that.
• Should PDF::Builder allow creation of PDFs (whether read-in or from scratch) with dimensions in excess of 14400? It might be good to have a global switch to allow this, so that the user understands that some readers won't be able to handle this output. Perhaps output a one-time (per run) message that a non-conforming dimension was seen, and allow that message to be suppressed? This would work only for new material (not read-in PDFs).
• Note that outputting UserUnit means raising the output PDF version to a minimum of 1.6.

The simplest path is to allow a global (and possibly per-page override) UserUnit setting. It would be up to the user to properly scale their coordinates to work with this scale factor. There would be no check of user space coordinate values (no bounds checking), in case the user wants to output PDFs that are not universally readable, but are for a specific reader. Without extensive processing of read-in PDFs (possible in the future), there is no easy way to scale down existing read-in PDFs to Acrobat (or Distiller) compatibility.

We need to check whether MediaBox and UserUnit can be set globally (inherited per page), or must be set on a per-page basis. Also need to consider scaling down mediabox(name) by dividing by any UserUnit given. So, mediabox('Letter') would output /MediaBox [0 0 8.5 11] if UserUnit was 72.

[Phil]

UserUnit has been added to both global ($pdf->userunit(value)) and page ($page->userunit(value)).

Due to oddities and inconsistencies in how various Readers handle UserUnit, be careful when using it. For example, Adobe Acrobat Reader does not have pages inherit the global setting (PDF::Builder gets around this) and Crop Box behaves differently.

This feature forces PDF 1.6 output. It will be available in the 3.015 build.