Report Prints Incorrectly When Choosing the PDF File Format As The Report Destination

Allan Cahill - Click for blog homepageThis is a reposting of an article Allan Cahill originally wrote on my Developing for Dynamics GP blog.

I recently worked on a PDFWriter printing incident with a Customer and we ran into a format problem when choosing the PDF File format.

The Problem

Since performing an upgrade to Microsoft Dynamics GP 2010, the Customer was having an issue when printing a single page invoice, in this instance, the SOP Blank Invoice Form.  When choosing the PDF file format as the report destination, the invoice was splitting over 2 pages for a single page invoice i.e. the standard report prints with the vertical lines extended past the border in the footer or with the Customer’s modified report, the page is moved up and report was splitting to multiple pages.

In testing, it was found that the following options functioned correctly:

  1. Print directly to printer using PDFWriter
  2. Print to screen, then to printer using PDFWriter
  3. Print to screen, then send via email as PDF

For the Customer, the problem was occurring when using Adobe Acrobat Distiller versions 7, 8 and 9.

This appears to impact all reports with vertical lines that also have a Word Form (SOP Order Blank Form, Purchase Order, etc.)

The Cause

The file is written as a Post Script file and when subsequently opened, it runs through the Adobe Distiller and creates the PDF. When you open the PDF it shows the issue as represented by the following screenshot:

There appeared to be some additional logic now in place that restricts the number of records that print on the first page to 24 when it is going to file using the PDF format.  This was previously 35 lines on Microsoft Dynamics GP 10.0 and the vertical lines printed accordingly.  With the record limitation the lines extend into the bottom of the page where there would have been the 11 additional records.  The page 2 extends the vertical lines through the report footer section.

The Solution

Working with Development, the following work-around options have been provided in relation to adding the following 2 lines to the the dex.ini:


The manual enforcement of the page size to 72 lines resolved our Customer’s issue as shown in the following screenshot:

If your report is landscape, use these settings instead:


The settings denoted in this post are for A4 paper size.  You may need to adjust these values for other paper sizes such as US Letter. Suggested values for US Letter are 68 for portrait and 52 for landscape.

In summary, the 3 versions of the report that “print” through PDFWriter worked without the dex.ini settings.  The version that is “exported” using Adobe Acrobat Distiller needs the dex.ini settings to control the page length. Because there are 2 different tools being used, you need to ensure your paper size is being set correctly in both tools prior to printing.


05-May-2011: Added more details in regards to landscape reports.

28-Jun-2011: Added suggested values for US Letter paper.

This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on

6 thoughts on “Report Prints Incorrectly When Choosing the PDF File Format As The Report Destination

  1. We are also having problems when we generate GP forms to .pdf for emailing. The footer comes up too high and does not stay at the bottom of the page, but not when printing to screen or directly to printer. I am going to test this to see if it resolves our problem as well!
    One question, what is the differenece between the 2 instructions?


  2. Hi Lauri
    I am not 100% sure why, but our testing showed you needed both settings for the changes to take effect when exporting to PDF. The ExportLinesPerPage setting might work by itself for the other export file formats, but ExportPDFLinesPerPage by itself was not enough to fix our issue.


  3. Thank you, this did resolve our issue! We tested the setting at per page =72, then had to tweak it for our purposes to 68. We tested emailing our various forms to ensure that by fixing the one we had issues with was okay but hadn't broken others, because the dex.ini is a global setting. Actually, to add to this scenrio, we are using a third party emailing solution. This ISV had not been able to resolve this problem for us. I should share this with them.


Please post feedback or comments

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.