Having spent many frustrating hours over the last week dealing with the difficulties of Windows custom paper sizes, some of which led to improvements in edits 1208-1209, I thought it might be useful to document some of my experiences, in case they are useful to others.

First, a little history:

The printer init command PAPERSIZE was introduced in 5.1.1157, followed by the embedded GDI command //PAPERSIZE in 5.1.1158.1. This has worked reasonably well for standard sizes (e.g. "LETTER", "A4", "LEGAL", etc.), but things can get confusing when dealing with custom sizes.

In 5.1.1209.0 (just posted), we introduced a pair of new printer init commands PAPERWIDTH and PAPERLENGTH intended to make it easier to specify non-standard paper sizes, with mixed results (as discussed below).

Edits 1208 and 1209 also improved the LP traces (SET TRACE LP ON to activate), providing much more useful debugging information.

For our case study, we want to be able to print on 8.5 x 12 inch paper, a size which appears to not match any known standard, at least for cut-sheet paper. (LETTER_PLUS is 12 x 8.5, but is intended for fanfold paper, which is typically foreign to laser printers.)

Attempt #1 (fake it): Not knowing how to specify a custom size, we tried to specify a size that was larger than the actual size (e.g. LEGAL, which is 8.5 x 14) and just not print on the entire "page"). This actually works ok on most printers, but at the target site, which was using an HP9000, depending on how the properties of the driver were configured, it sometimes resulted in a complaint about the requested paper size not matching the paper sizes available. It was never actually clear to me if the printer was capable of detecting the paper sizes in the bins, but it did allow the sizes in the bins to be selected manually. We might therefore have been able to fool the printer into thinking it had LEGAL in one of the bins, but we weren't sure if that was a good long term plan (likely to confuse users, get messed up during maintenance or paper changes, etc.) The other option was to specify "All Papers" (somewhere in the driver dialog or perhaps on the printer's control panel), which turned off the complaint about a mismatch between the available paper and the requested paper, but again, that didn't seem very permanent.

Tips on "faking it": First, make sure the size you want to fake is the same or smaller than the size you tell the printer. (You can carve out 8.5x12 from 8.5x14 LEGAL, but not from 8.5x11 LETTER.) Second, make sure your font size isn't being affected by the paper size. (Avoid PITCH =AUTO. If using the //SETFONT width parameter, set it to a positive rather than negative value. Use //SETVMI to set the vertical spacing independent from the paper height and the LPP .) And of course you'll need to insert hard page breaks at the appropriate locations.

Attempt #2 (manually define and select a custom paper size): My in-house Brother HL-5250DN didn't seem to have any support for custom forms, but I was able to get a VNC connection to the remote site and found in the HP9000 printer driver an option to define a custom form. Which I did. Once defined, I then listed the available paper sizes (by adding a dummy PAPERSIZE=256 command to my PRT8.PQI printer init file, using SET TRACE LP ON to activate the LP tracing, and then printing a sample file with PRINT PRT8=TEST.PRT/PREVIEW). It listed several paper sizes, but many of them only specified a numeric value, so I couldn't tell which one, if any, was the custom one I defined. (This eventually led me to improve the tracing to show the printer's description of each available paper size along with the actual size, in edit 1208, but that comes later.)

So I didn't know how to programmatically select the custom paper, but I was able to manually select it in the driver properties as the current paper (using "Apply" to make it the new default setting). After that, I could print to the printer (without requesting any specific PAPERSIZE) and got the desired result.

That seemed like a reasonable solution, since some kind of operator person presumably has to manually load the special form into the printer, so it doesn't seem like too much to ask to have that person set the current papersize in the driver properties to the custom form. But it still suffers from the possibility that the user will forget that step, or be preempted by someone else printing to the printer (perhaps using a different bin). So a method of requesting it automatically was desired.

Attempt #3 (select the custom paper using PAPERSIZE): After adding the improved tracing (mentioned above), I was able to see that the in fact the custom paper size I defined in the printer driver properties was now showing up as papersize #142. (This was further confirmed by the fact that APEX was showing "papersize #142" in its title bar when previewing the output of the Attempt #2 above.)

I'm not sure how that number got assigned, or whether it will be permanent, but I was then able to add PAPERSIZE=142 to the printer init file, and voilà, it worked. (That is, I was able to set the default printer properties back to LETTER paper, and print my file using PAPERSIZE=142 and it selected the correct custom form.)

So that was pretty good. But it would still be better if we could specify the desired custom paper size in the printer init file, without having to first manually define the custom form in the printer driver. This led to the addition of two new printer init commands, PAPERWIDTH and PAPERLENGTH (which you can read about in the Development Notes )

[continued...]

[...continued from above]

Attempt #4 (specify custom size using PAPERLENGTH and PAPERWIDTH):
I started with my Brother HL-5250DN, where I quickly discovered that the driver simply did not support that option. Printer drivers all return a bit field indicating which standard features they support. As of 1209, this information is displayed in the traces (examples to follow). But there was no obvious workaround.

I tried several other drivers that I had installed, and among them, the only one that seemed to support the feature was the PDFX driver, but only when I first set the driver properties manually to the "custom" paper option. (After that, the PAPERWIDTH and PAPERLENGTH options did allow changing the custom size, but that doesn't seem very useful, unless you planned to create a second copy of the driver, one set to a standard size and one set to the custom size.) Scanning other developer forums, one gets the idea that support for this feature is pretty spotty.

But before giving up, I decided on the old standby technique for solving printer problems: when all else fails, try getting a driver update. Sure enough, even though my printer is a couple of years older than my PC (and thus it's hard to imagine the driver wasn't stable by the time I installed it on the PC), there was in fact an updated driver available through Windows Update. And the improvements were significant, including support in the properties dialog for custom forms. So with the updated driver I was now able to successfully repeat the procedure described above in Attempts #2 and #3. And, the driver was no longer saying it didn't support paperwidth and paperlength settings. But, it still didn't work.

To be more precise, here's my printer init:
I then set the printer default to A4 paper (to make there was no confusion over whether both the PAPERSIZE and PAPERWIDTH commands were overriding the default setting). I then printed the TEST.PQI (with the APEX /PREVIEW switch on to avoid wasting paper):
The preview window title shows that the paper size is still A4:



Looking at the trace, we see:

Requesting printer DC for BROTHER HL-5250DN using devmode 7a73a8
32 21:34:09 Initial page size: 4960 x 7014 pixels
33 21:34:09 Retrieving handle to printer [BROTHER HL-5250DN] (for duplex/paper setup)...
34 21:34:09 [OK: hPrinter=794d0c]
35 21:34:09 Allocated 2516 bytes for DEVMODE
36 21:34:09 Selecting paper from SUPPORTED papers:
37 21:34:09 A4 (9) "A4" (210.0 x 297.0 mm, 8.3 x 11.7 in)
38 21:34:09 LETTER (1) "Letter" (215.9 x 279.4 mm, 8.5 x 11.0 in)
39 21:34:09 LEGAL (5) "Legal" (215.9 x 355.6 mm, 8.5 x 14.0 in)
40 21:34:09 EXECUTIVE (7) "Executive" (184.1 x 266.7 mm, 7.2 x 10.5 in)
41 21:34:09 A5 (11) "A5" (148.0 x 210.0 mm, 5.8 x 8.3 in)
42 21:34:09 A6 (70) "A6" (105.0 x 148.0 mm, 4.1 x 5.8 in)
43 21:34:09 ENV_B5 (34) "B5" (176.0 x 249.9 mm, 6.9 x 9.8 in)
...
52 21:34:09 papersize: #260 (260) "Organizer M" (215.9 x 279.4 mm, 8.5 x 11.0 in)
53 21:34:09 papersize: #261 (261) "3 x 5" (76.2 x 127.0 mm, 3.0 x 5.0 in)
54 21:34:09 papersize: #262 (262) "A4 Long" (210.0 x 404.9 mm, 8.3 x 15.9 in)
55 21:34:09 FOLIO (14) "Folio" (215.9 x 330.2 mm, 8.5 x 13.0 in)
56 21:34:09 papersize: #263 (263) "DL Long Edge" (219.9 x 109.9 mm, 8.7 x 4.3 in)
57 21:34:09 papersize: #256 (256) "User Defined" (69.9 x 116.0 mm, 2.8 x 4.6 in)
58 21:34:09 A3 (8) "A3" (297.0 x 419.9 mm, 11.7 x 16.5 in)
59 21:34:09 B4 (12) "JIS B4" (256.9 x 363.9 mm, 10.1 x 14.3 in)
60 21:34:09 TABLOID (3) "Ledger" (279.4 x 431.8 mm, 11.0 x 17.0 in)
61 21:34:09 DEVMODE Device:Brother HL-5250DN, Ver:793, Size:156, Extra:2360, bin=1, duplex=1, paper=9, orient=1, copies=1, dmFields=0x1ff1f
62 21:34:09 Requesting paperwidth override to 215.9 mm (8.5 in)
63 21:34:09 Requesting paperlength override to 304.8 mm (12.0 in)
64 21:34:09 Updated page size: 4960 x 7014 pixels
...

68 21:34:09 Final page size: 4960 x 7014 pixels (600 x 600 dpi)

Notes on the highlighted parts:

- The initial page size indicates the current default paper size. (You may have to scan down to the end to see the Final page size to get the dpi value in order to convert the pixels to inches or mm.) This information is also confirmed in the "DEVMODE ... paper=9" trace near the bottom (9 = A4, as you can see in the list of supported papers).

- The "Selecting paper " indicates that we didn't specify any PAPERSIZE command in the printer init file or the print file itself. (The PAPERWIDTH/PAPERLENGTH commands triggered the listing of the available paper sizes.)

- The custom paper that I defined manually using the printer driver dialog was given a papersize value of 256. (This is a kind of standard for custom papers, and in fact as of edit 1209, you can specify PAPERSIZE=CUSTOM as an alias for it.) Note though that when I defined the custom paper size in the driver dialog, I gave it a weird size (2.8 x 4.6 in) to make sure that it could be over-ridden by PAPERWIDTH and PAPERLENGTH at print time.

- The two "Requesting..." messages confirm that it really is asking the driver for these custom sizes, and the lack of any warning before or after indicates that the driver seems to support the feature.

However, the "Updated page size: 4960 x 7014 pixels" (same as the Initial Page Size), clearly indicates that it did not actually change the paper size.

At this point you most likeLY need to crack open a beer or go out for a long walk. But upon returning, the thing to do is to conclude that there is a bug in the driver (it indicates that it supports PAPERWIDTH and PAPERLENGTH, yet it doesn't seem to work). But before giving up, remembering (from much trial and error) that in other cases it was necessary to explicitly set the printer to the custom paper size before explicit changes could be made to the width and length, it's worth a try to see if it can be done via the PAPERSIZE command. Sure enough, after adding PAPERSIZE=CUSTOM to the TEST.PQI, the preview now looks like this:



Which is exactly what we were trying for. The success of the custom PAPERLENGTH and PAPERWIDTH is further confirmed by the traces:

34 21:57:27 Initial page size: 4960 x 7014 pixels
...
64 21:57:28 Requesting papersize #256
65 21:57:28 Requesting paperwidth override to 215.9 mm (8.5 in)
66 21:57:28 Requesting paperlength override to 304.8 mm (12.0 in)
67 21:57:28 Updated page size: 5100 x 7200 pixels

So, the moral of the story is two-fold:

a) You may need to manually define a custom paper manually (although the specific size may not be important) before you can use PAPERWIDTH and PAPERLENGTH. Unfortunately, this does limit the robustness of the technique, since it depends on an initial customization to the driver properties (although it doesn't depending on an initial state of the printer settings).

b) You may need to add PAPERSIZE=CUSTOM, along with your PAPERWIDTH and PAPERLENGTH commands.

But is this representative of print drivers in general? Or just this updated Brother HL-5250DN?

[to be continued...]

[...continued from above

Attempt #5 (try PAPERWIDTH/PAPERLENGTH with other drivers): For my next test, since I don't have another physical printer handy at the moment, I'll use the Microsoft XPS Writer driver. (In theory we should be able to count on it following the standards!) To start, I removed my PAPERSIZE command, so my new printer init is:

And this time I didn't pre-define any custom paper sizes. In fact, there doesn't seem to be any mechanism in the driver properties to do so, and there was no "Custom" option in the otherwise very extensive list of papersize options in the printer dialog. The only change I made was to set the default paper to A4, to match my previous test.



No joy there, although interestingly it selected papersize 256 (215.9 x 279.4 mm = 8.5 x 11 in) rather than the A4 default I had set. Let's look at the trace messages to see if we can get a better idea of what happened:

Requesting printer DC for MICROSOFT XPS DOCUMENT WRITER using devmode 7a2ad0
30 22:27:18 Initial page size: 4961 x 7016 pixels
34 22:27:18 Selecting paper from SUPPORTED papers:
35 22:27:18 LETTER (1) "Letter" (215.9 x 279.4 mm, 8.5 x 11.0 in)
36 22:27:18 LETTERSMALL (2) "Letter Small" (215.9 x 279.4 mm, 8.5 x 11.0 in)
37 22:27:18 TABLOID (3) "Tabloid" (279.4 x 431.8 mm, 11.0 x 17.0 in)
38 22:27:18 LEDGER (4) "Ledger" (431.8 x 279.4 mm, 17.0 x 11.0 in)
39 22:27:18 LEGAL (5) "Legal" (215.9 x 355.6 mm, 8.5 x 14.0 in)
40 22:27:18 STATEMENT (6) "Statement" (139.7 x 215.9 mm, 5.5 x 8.5 in)
41 22:27:18 EXECUTIVE (7) "Executive" (184.1 x 266.7 mm, 7.2 x 10.5 in)
42 22:27:18 A3 (8) "A3" (297.0 x 420.0 mm, 11.7 x 16.5 in)
43 22:27:18 A4 (9) "A4" (210.0 x 297.0 mm, 8.3 x 11.7 in)
...
141 22:27:18 papersize: #133 (133) "8.5x12" (215.9 x 304.8 mm, 8.5 x 12.0 in)
143 22:27:18 DEVMODE Device:Microsoft XPS Document Writer, Ver:1536, Size:156, Extra:856, bin=15, duplex=1, paper=9, orient=1, copies=1, dmFields=0xff03
144 22:27:18 Driver doesn't support explicit paper dimensions; try resetting form to #0
145 22:27:18 DEVMODE Device:Microsoft XPS Document Writer, Ver:1536, Size:156, Extra:856, bin=15, duplex=1, paper=0, orient=1, copies=1, dmFields=0xff03
146 22:27:18 Driver doesn't support explicit paper dimensions; try resetting form to #256
147 22:27:18 DEVMODE Device:Microsoft XPS Document Writer, Ver:1536, Size:156, Extra:856, bin=15, duplex=1, paper=256, orient=1, copies=1, dmFields=0xff03
148 22:27:18 Custom paper width/length not supported by printer driver!
152 22:27:19 Final page size: 5100 x 6600 pixels (600 x 600 dpi)

This time it started in A4 (4961 x 7016 pixels at 600 dpi). The list of supported paper sizes does not indicate a "custom" option. And we do get a message indicating that the driver does not support explicit paper dimensions.

When this happens, since we've determined that in some cases, the driver has to first be nudged into custom paper mode before it will accept explicit custom sizes, A-Shell tries first to set the paper to whatever PAPERSIZE you may have specified in the printer init file. Since we didn't specify one, it tries the equivalent of PAPERSIZE=0. When that didn't work, it tries again with PAPERSIZE=256. When that also didn't work, it finally spits out the message "Custom paper width/length not supported by printer driver!". (This message will appear in the log even if the LP TRACE option is not set.)

And as we can see from the final page size, we ended up with LETTER size (8.5 x 11 in or 5100 x 6600 at 600 dpi).

At this point I am out of suggestions, since there doesn't seem to be any way to define a custom size, and we've already tried the PAPERSIZE=CUSTOM approach (or more precisely, A-Shell tried it for us when the first attempts to change the PAPERLENGTH and PAPERWIDTH didn't work).

Conclusion: the Microsoft XPS Document Writer doesn't support custom paper sizes.

Let's try one more printer. Although I don't have another physical printer handy, I can use another laser printer driver and point it at my printer's network address (which may work well enough at least to test the driver interface).

So I set up the Samsung ML-2010 driver and run the same test. This driver does support the ability to define a custom form, but initially I leave it unset. This fails in a similar way to the XPS Writer test, although with some minor differences which are worth exploring:



This time we end up with paper size "LETTER" instead of "256".

The trace:

Requesting printer DC for SAMSUNG ML-2010 SERIES using devmode 749fd8
27 22:53:28 Initial page size: 4960 x 7014 pixels
31 22:53:28 Selecting paper from SUPPORTED papers:
32 22:53:28 LETTER (1) "Letter" (215.9 x 279.4 mm, 8.5 x 11.0 in)
33 22:53:28 LEGAL (5) "Legal" (215.9 x 355.6 mm, 8.5 x 14.0 in)
34 22:53:28 EXECUTIVE (7) "Executive" (184.1 x 266.7 mm, 7.2 x 10.5 in)
35 22:53:28 A4 (9) "A4" (209.9 x 296.9 mm, 8.3 x 11.7 in)
...
46 22:53:28 papersize: #121 (121) "Oficio" (215.9 x 342.9 mm, 8.5 x 13.5 in)
47 22:53:28 papersize: #256 (256) "Custom Size" (215.9 x 279.4 mm, 8.5 x 11.0 in)
49 22:53:28 DEVMODE Device:Samsung ML-2010 Series, Ver:1024, Size:156, Extra:3335, bin=7, duplex=1, paper=9, orient=1, copies=1, dmFields=0xdf03
50 22:53:28 Driver doesn't support explicit paper dimensions; try resetting form to #0
51 22:53:28 DEVMODE Device:Samsung ML-2010 Series, Ver:1024, Size:156, Extra:3335, bin=7, duplex=1, paper=1, orient=1, copies=1, dmFields=0x1df03
52 22:53:28 Driver doesn't support explicit paper dimensions; try resetting form to #256
53 22:53:28 DEVMODE Device:Samsung ML-2010 Series, Ver:1024, Size:156, Extra:3335, bin=7, duplex=1, paper=1, orient=1, copies=1, dmFields=0x1df03
54 22:53:28 Custom paper width/length not supported by printer driver!
58 22:53:28 Final page size: 5100 x 6600 pixels (600 x 600 dpi)

The trace is similar to that for the XPS Writer, in that the driver indicates that it does not support PAPERLENGTH and PAPERWIDTH, but when we try to pre-set the PAPERSIZE to 0 or 256, it gets translated by the driver back to 1 (LETTER). This is particularly surprising since there is a "papersize: 256 Custom Size" in the list of supported papers.

Even though A-Shell automatically attempted PAPERSIZE=256 after trying PAPERSIZE=0, the fact that there is a pre-defined paper size #256 is tantalizing enough to try another test with an explicit PAPERSIZE=CUSTOM in the printer init file:

Code

DEVICE = Samsung
PASSTHROUGH = OFF
PITCH = AUTO
CPP = *
PAPERSIZE=CUSTOM
PAPERLENGTH=3048        ; (tenths of mm; = 12 in)
PAPERWIDTH=2159         ; (= 8.5 in)

Hmmm..., this does act differently, suggesting that the automatic attempt to set PAPERSIZE=0 to see if it affects the driver's inclination to support PAPERLENGTH/PAPERWIDTH may have back-fired, causing the subsequent attempt to set PAPERSIZE=256 to not work (since setting PAPERSIZE=CUSTOM directly does seem to work, kind of).

The problem is that although we ended up with papersize #256 (aka CUSTOM), the size we got is not the 8.5 x 12 (215.9 x 279.4 mm) that we wanted. Yet according to the trace, after requesting the custom paper width and length, the updated page size was correct (5100 x 7200 pixels):

268 23:03:21 DEVMODE Device:Samsung ML-2010 Series, Ver:1024, Size:156, Extra:3335, bin=7, duplex=1, paper=9, orient=1, copies=1, dmFields=0xdf03
269 23:03:21 Driver doesn't support explicit paper dimensions; try resetting form to #256
270 23:03:21 DEVMODE Device:Samsung ML-2010 Series, Ver:1024, Size:156, Extra:3335, bin=7, duplex=1, paper=256, orient=1, copies=1, dmFields=0x1df0f
271 23:03:21 Requesting paperwidth override to 215.9 mm (8.5 in)
272 23:03:21 Requesting paperlength override to 304.8 mm (12.0 in)
273 23:03:21 Updated page size: 5100 x 7200 pixels
277 23:03:21 Final page size: 5100 x 6600 pixels (600 x 600 dpi)

However, somewhere between that operation and the "final page size", it reverted back to 5100 x 6600 pixels (8.5 x 11 in).

I don't have any good explanation for that, other than that it may be because I don't actually have the printer, and in this case the "final page size" is the size the APEX gets from the printer in order to construct the preview. So that may be a red herring.

In fact, repeating the test with APEX disabled (using /NOPREVIEW), it appears to work correctly, at least according to the trace:


566 23:22:04 Updated page size: 5100 x 7200 pixels
568 23:22:04 Final page size: 5100 x 7200 pixels (600 x 600 dpi)

(It doesn't actually print though, again probably because I don't actually have that kind of printer.)

The moral of this story appears to be:

a) Drivers vary, both in what they explicitly support, and in subtle details about how they respond to paper size requests.

b) You may or may not need an explicit PAPERSIZE=CUSTOM along with your PAPERWIDTH and PAPERLENGTH commands.

c) Trial and error may be required, and sometimes pays off.

d) You can do a fair amount of testing and debugging without actually having the printer (using APEX and the traces). This could be particularly useful for dealers attempting to support users with oddball printers that don't behave as expected.

e) Even with the PAPERSIZE, PAPERWIDTH and PAPERLENGTH commands, it may be preferable to require the end user to manually define a custom form and manually set it to be the default before loading and using the custom paper. (This way at least it tends to put the responsibility in the users' hands, rather than in yours, or A-Shell's.)

Here's an updated technique for defining and selecting a custom form, which appears to work with some but not all drivers (and which requires 5.1.1209.2, and possibly Windows 7):

Step 1: Go into the Devices and Printers > Print Server Properties applet, where you can see the available "forms" and create a new one:



In the image above, I created a form called "MSBILL" which is 8 x 10".

Step 2: Add PAPERSIZE=MSBILL to your printer init (or //PAPERSIZE,MSBILL to your printfile).

Step 3: Run a test with SET TRACE LP ON and PRINT ptr=file/preview, and check the list of support paper sizes to see if your custom form appears there. In my tests, it appears for the XPS Writer, and for the LaserJet 4, but not for the Samsung ML-2010 nor the Brother HL-5250DN. (If it doesn't appear, you'll get a message box saying that it couldn't match the requested paper.)

There may be some trick or additional step needed to make these custom forms visible to all drivers, but the fact that in my simple test it worked for two drivers and failed for two others seems to suggest variability between drivers more than a missing step on my part. But that's another area for investigation.

On a related note, the driver interface actually supports named "forms", as an alternate to "papers", but so far I have been unable to request a "form", even though after defining a "form", I've been able to select it as if it were a "paper".

This technique above (defining custom form) works fine for custom label printing, with a Brother QL label printer. Thanks.

Thanks for the feedback!