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 www.dynms.com for a categorized view.
All utilities and downloads are available at www.dmsiworks.com
BehaviorWhen 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):
Once it's actually printed on paper, it looks worse.
Work-AroundsThis 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:
- 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.
- 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.
- 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.
- 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.
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.