NAV 2013 Report Issues (Solved)

Anyone who is thinking about deploying NAV 2013 via Citrix, Terminal Services, or virtual desktops may get a bit of a surprise: none of the reports will print properly unless you take additional measures.  The issue is not specifically a NAV bug, it's due to RDLC/SSRS issues when running remote sessions.  This has been an issue for a couple of years and there's no word from Microsoft on a fix yet.  There are, however, a few work-arounds.

UPDATE: There are now two fixes for this issue.  Run Server 2012 (as per NAV Team Blog), or install the Microsoft hotfix for 2008/Win7 (thanks to Duilio and Marco in the comments for the tip).  We've installed the hotfix and it works well.

Please note that all DMS news and blog content has been moved to the main website at for a categorized view.

All utilities and downloads are available at


When running NAV remotely (RDP, etc.) and previewing a report it looks great, but when you print it (regardless of printer) you get a report with squished fonts.  This makes some reports almost unreadable, and it makes most reports look quite ugly.  For example, below are screen shots from the standard NAV invoice in Cronus:

Print Preview (click for larger view):

Printed Version:
As you can see, the fonts are rendered in a way that messes the spacing up quite a bit.  This report is still fairly readable, but others don't fare as well, e.g., have a look at the Shipment heading:

 Once it's actually printed on paper, it looks worse.


This behavior only occurs if you're running NAV 2013 via Citrix, Terminal Services, or virtual desktops, and then only if you're running NAV with a display resolution that isn't a 4:3 aspect ratio.  I.e., if you're running a "wide screen" (16:9) display resolution, you'll get this issue; if you're running something like 1024x768, you're fine (that, incidentally, is one of the work-arounds we've found).

After a lot of searching and experimenting, these are the solutions we've found for the issue so far:
  1. Run NAV using a local install.  As mentioned, the issue only seems to occur when running via RDP, Citrix, etc.  Not always the best solution, but may be the easiest in many cases.
  2. Change the client's display resolution to one that's a 4:3 aspect ratio (or less - i.e., 1280x1024 works fine too).  See this chart for a list of resolutions and aspect ratios.
  3. Don't print reports from NAV.  Instead, save them as PDF, Word, or Excel and then print them. The "save as" function is not affected by the issue.  This isn't much help when doing Post+Print, but for general reports could be acceptable.
  4. Instead of having actions that run reports, execute a codeunit that saves the report to PDF and then launches it.  A bit of a pain (which is why we haven't done this), but would be useful for Post+Print scenarios.
UPDATE: One of our developers has confirmed that using background posting for post+print causes the documents print correctly, which makes sense since they're being printed on the server instead of the client.

There are also some wilder, more involved options like creating a custom report viewer that can force the DPI settings appropriately, or even a print processor to adjust the PostScript on the fly (craziness, though we've actually done something similar before).  Anyway, we're not going that far - our approach so far has been to either install locally, and in cases where we cannot, force users to use a different resolution for their sessions.

If anyone has additional work-arounds or solutions, we'd love to hear about them. 


Anonymous said...

One can vote here for this issue to be handled with higher priority from MS:

dtacconi said...

This issue has been solved this week by Windows Platform team. You just have to install this hotfix
(remember to reboot machine)

Duilio Tacconi

Anonymous said...

Hi Mark,

It looks like MS found a solution to the problem.

Please let me know if you can also confirm this works!


Unknown said...

Thanks Duilio and Marco - fix works well.

Unknown said...

i can add that the resolution work arround isn't a real fix, Barcodes for example still don't scan.
now moving on to the microsoft hotfix

Mark said...

Hi Bert, bar codes are a common issue with printing - for example, barcodes printed from Word normally don't scan due to the way Word smooths and adjusts font spacing, though they will print if Excel is used.
If you have the potential to use them (i.e., you have scanners that will accept them), 2D barcodes are a better choice. If you want a 2D barcode library for NAV, drop us a line at info at

Post a Comment

Your comment will be posted once approved.