Access Report is printing "funny" characters

What is the RecordSource for this report?

There are issues with Memo fields and GroupBy queries displaying data like this.

JeffCoachman

@harfang:
*it's the standard 2007 calibri font (and all users DO have it installed.)
*It's a bit too wide to put in portrait, but i'll give it a go and see if that does anything  -- if it does: what difference would that make?
*there isn't anything different on the report EXCEPT: one of my fields is generated from a module that concatenates strings together. I've looked at the data for the two users who are getting funky stuff, and it doesn't look any different than any one else's data.
*Yup. same print settings.
*Yes, they can successfully create a pdf and print that -- which is what makes it so curious.

@boag:
no memo fields or group by's. Just a standard query, with one module created field.

And again, it's previewing fine, just printing funky.

Also an update: one of the users was printing fine until last week, when their report started printing funky.

Honestly, you might never find the exact reason why this happens. Too much of the printing process happens "behind the scenes". I encountered something similar a few years back: on one given report, when I used bold on the page header, bold was no longer available anywhere else on the report. It worked in print preview, but not when printing on any of the client company's laser printers. I ended up using "semi-bold" as a workaround...

Anyway, it's obvious that the print driver doesn't draw the characters, but sends character codes, which the printer is supposed to draw. Many printers have standard windows fonts pre-installed, so that they don't need to be downloaded before each print job. This is why I suggested trying different fonts. Suppose the printer doesn't have colibri: there might be a bug in the soft font download. Suppose it has: there might be a bug in the pre-installed font.

Ideally, to gather as much information as possible, you should work on one of the workstations where the problem occurs and try to reproduce it with a new report. Perhaps you will end up recreating your report entirely without triggering it, though.

This leads to another idea: try to rebuild the report. You can use these commands for that:

    SaveAsText acReport, "rptBuggyReport", "C:\buggy.txt"
    LoadFromText acReport, "rptBuggyReportCopy", "C:\buggy.txt"

These commands are normally hidden, so if you want intellisense you need to "show hidden members" in the Object Browser (key [F2]).

Just saving and reloading will probably not solve the problem, but you can examine the text file before reloading it. You will see some large data chunks, named PrtMip, PrtDevMode, and PrtDevNames. If you delete them, the copy will revert to the default values of your database. This is as close as you can get to recreating a report from scratch without actually doing it.

In any case, good luck!
(°v°)

1. Are all the machines at the same Service Pack level for Office *And* Windows.

2. Try Arial or Times New Roman font.

boag - they are all logging into the terminal server and running it off the TS. The only thing that's different from user to user are their local printers.

In any case, switching the font to Arial seems to have fixed the issue. Go figure. Thanks for all your help.

V

It was switching the font to Arial that resolved the problem, I think.