New Version ConvertReportToPDF, Page Size Bug

[krissco]

Hello,

I have been using Stephen's ConvertReportToPDF for some time and was
thrilled to see an update on his site the other day. I was most
excited about the "Fixed Paper Size Bugs." Alas, my bug is still
around.

Windows Server 2003 Enterprise 5.2 SP-2
Access 2000 9.0.6926 SP-3

I am able to export my report to .snp and everything looks fine. When
I convert the .snp to .pdf, a small portion of the bottom of the page
is truncated.

The page size (in Access) is 5.5" wide x 8.5" tall
I don't know how to determine the page size in the .snp file
The page size in the .pdf is 8.27" x 11.69" (essentially letter)

The Access page size is obviously custom. This is set up using the
windows print server properties - creating a custom print form for the
printer - etc.

I have tried setting/changing my default printer when creating
the .snp/.pdf files with no change.

My question is: Did "Fixed Paper Size Bugs" have anything to do with
custom page sizes? Any clues on how to fix this?

Thank you Stephen for all your hard work!

-Kris

 

[Stephen Lebans]

User Defined or Custom paper sizes are not supported in the current version.

Prior to Windows NT, Custom paper sizes were easy to support.With the advent
of NT, named Forms are now used to handle Custom Paper sizes. Each time you
add a Custom Form to your Printer, Windows assigns this form a numeric ID.
This ID value is generated from a sequential incrementing counter SPECIFIC
to each workstation. Access stores this ID in the PaperSize element of the
Report's Devmode structure. This creates an issue when you try to identify
the correct form on another computer. The odds are that the Form ID's will
not be the same. THis issue is further compounded by the fact that Access
does not store the Custom Form's name in the dmFormName element of the
DevMode structure. Calls to GetForm require a Form name. Now you have to
EnumForms to get all of the Form names for this printer, then use this to
index into the Registry Keys for Custom Forms and try to find a match based
on the Form's ID.

Again, its not an issue for the workstation that defined the Custom Form,
only for any other workstation that will be displaying or converting this
report.

I have not used the Printer Forms API's before so I would imagine the
standard steep learning curve. I'll add this issue to the ToDo list for the
next release.


--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[krissco]

User Defined or Custom paper sizes are not supported in the current version.

Prior to Windows NT, Custom paper sizes were easy to support.With the advent
of NT, named Forms are now used to handle Custom Paper sizes. Each time you
add a Custom Form to your Printer, Windows assigns this form a numeric ID.
This ID value is generated from a sequential incrementing counter SPECIFIC
to each workstation. Access stores this ID in the PaperSize element of the
Report's Devmode structure. This creates an issue when you try to identify
the correct form on another computer. The odds are that the Form ID's will
not be the same. THis issue is further compounded by the fact that Access
does not store the Custom Form's name in the dmFormName element of the
DevMode structure. Calls to GetForm require a Form name. Now you have to
EnumForms to get all of the Form names for this printer, then use this to
index into the Registry Keys for Custom Forms and try to find a match based
on the Form's ID.

Again, its not an issue for the workstation that defined the Custom Form,
only for any other workstation that will be displaying or converting this
report.

I have not used the Printer Forms API's before so I would imagine the
standard steep learning curve. I'll add this issue to the ToDo list for the
next release.

--

HTH
Stephen Lebanshttp://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

Ok, Thanks for the clarification.

That seems like an impossible task for a foreign workstation -
discover the page size of a form created on another machine for a
printer you may not even have installed. Yeah right.

As far as the "creator" workstation, I came across some code a few
years ago that does does the trick (interrogates winspool.drv using
the printer name and port as indices to retrieve page size
information).

The code was in:

Ch10.mdb
From Access 97 Developer's Handbook
by Litwin, Getz, and Gilbert (Sybex)
Copyright 1997. All rights reserved.


Are you familiar with this project? Does a .snp store device name and
port? If not, then I guess that EnumForms is the way to go.


Thank you again,

-Kris

ps. I also ran across this in my 15min crawl around the web:
http://support.microsoft.com/kb/282474