By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,166 Members | 1,130 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,166 IT Pros & Developers. It's quick & easy.

Text is Truncated when Report Prints

P: n/a
TC
I've produced an Access application for a client. For one report, text
gets cut-off at the right margin when we print the report. It does this
only when we print; it doesn't happen when we view the report in
preview mode. Also, it occurs only at the client site; it doesn't occur
at my office or on any other computer I've tried.

I can describe the problem best with a specific example. (This is a
contrived example, but it is faithful to the real problem.)

On my computer, print preview and the printout both show:

Four score and seven years ago our fathers
brought forth on this continent, a new nation,
conceived in Liberty, and dedicated to the
proposition that all men are created equal.

On the client computer, print preview shows:

Four score and seven years ago our fathers brought
forth on this continent, a new nation, conceived in
Liberty, and dedicated to the proposition that all men
are created equal.

On the client computer, the printout shows:

Four score and seven years ago our fathers broug
forth on this continent, a new nation, conceived in
Liberty, and dedicated to the proposition that all m
are created equal.

The only font used is Arial. Everything is happening in Access 2003 and
Windows XP.

Despite the fact that we've tried to make everything exactly the same,
the report is being rendered differently on my computer vs. theirs. If
I can figure out why, I think I'll have a solution to the problem. My
gut feeling is that the bug is caused by their system configuration
(their fonts or their printer drivers), and not by Access or my
application. Nevertheless my application is the only thing which has
ever exhibited this behavior, so all fingers are pointing at me.

I've come here to see if there is a known bug in Access which could be
causing the problem. Has anyone seen something like this before?
-TC

Nov 15 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
TC, hopefully you will get several different responses to your question.

Access does use the metrics from the printer driver to plan the layout of
the report. It sounds as if the printer driver your client is using is
faulty.

To demonstrate that the problem is the printer driver, have the client
choose a completely different printer, and print to that. The problem will
disappear. Once they are convinced, they can take it up with the
manufacturer of their printer. Hopefully the manufacturer is aware of the
problem and already has a new driver available.

If the client cannot get an updated driver, but the printer has an emulation
mode, they may be able to work around the problem that way.

Another way to demonstrate that Access uses the printer driver's metrics for
report layout is to attempt to create or view an Access report on a computer
that has no printer installed at all. If there is no printer, Access will be
unable to calculate the report's layout.

HTH.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Reply to group, rather than allenbrowne at mvps dot org.

"TC" <go*********@yahoo.comwrote in message
news:11**********************@k70g2000cwa.googlegr oups.com...
I've produced an Access application for a client. For one report, text
gets cut-off at the right margin when we print the report. It does this
only when we print; it doesn't happen when we view the report in
preview mode. Also, it occurs only at the client site; it doesn't occur
at my office or on any other computer I've tried.

I can describe the problem best with a specific example. (This is a
contrived example, but it is faithful to the real problem.)

On my computer, print preview and the printout both show:

Four score and seven years ago our fathers
brought forth on this continent, a new nation,
conceived in Liberty, and dedicated to the
proposition that all men are created equal.

On the client computer, print preview shows:

Four score and seven years ago our fathers brought
forth on this continent, a new nation, conceived in
Liberty, and dedicated to the proposition that all men
are created equal.

On the client computer, the printout shows:

Four score and seven years ago our fathers broug
forth on this continent, a new nation, conceived in
Liberty, and dedicated to the proposition that all m
are created equal.

The only font used is Arial. Everything is happening in Access 2003 and
Windows XP.

Despite the fact that we've tried to make everything exactly the same,
the report is being rendered differently on my computer vs. theirs. If
I can figure out why, I think I'll have a solution to the problem. My
gut feeling is that the bug is caused by their system configuration
(their fonts or their printer drivers), and not by Access or my
application. Nevertheless my application is the only thing which has
ever exhibited this behavior, so all fingers are pointing at me.

I've come here to see if there is a known bug in Access which could be
causing the problem. Has anyone seen something like this before?

-TC

Nov 15 '06 #2

P: n/a
TC
Allen,

Thanks for the advice.

I like the theory of a faulty printer driver. To pursue that theory, I
asked the client to test the report on different printers. They tested
two printers, and the problem occurs on both. That puts a big hole in
the theory.

Is it possible for different printer drivers to share information about
how to render fonts? (For instance, do all Postscript printers use the
same font metrics, such that if one renders incorrectly, they can all
be expected to render incorrectly?) My new theory is that there is
something wrong with the configuration of their computers, and the
problem is not with the printer drivers per se, but with core software
used by several printer drivers (e.g. there is something wrong with
their Postscript software, or their True Type font definition for
Arial). Since I know nothing about fonts and drivers, this is just a
guess on my part. Does it sound like I'm on the right track?

Another challenge to faulty-printer-driver theory is that, if the
problem is not Access, I should see the bug while using other software.
I've experimented in Word with the same fonts, page setup, margins,
etc., and so far I haven't been able to make Word printouts exhibit the
problem. Can anyone offer an explanation for why Access might be the
only software to suffer this failure if, as my theory proposes, the
fault lies in the printer driver?
-TC
Allen Browne wrote:
TC, hopefully you will get several different responses to your question.

Access does use the metrics from the printer driver to plan the layout of
the report. It sounds as if the printer driver your client is using is
faulty.

To demonstrate that the problem is the printer driver, have the client
choose a completely different printer, and print to that. The problem will
disappear. Once they are convinced, they can take it up with the
manufacturer of their printer. Hopefully the manufacturer is aware of the
problem and already has a new driver available.

If the client cannot get an updated driver, but the printer has an emulation
mode, they may be able to work around the problem that way.

Another way to demonstrate that Access uses the printer driver's metrics for
report layout is to attempt to create or view an Access report on a computer
that has no printer installed at all. If there is no printer, Access will be
unable to calculate the report's layout.

HTH.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Nov 15 '06 #3

P: n/a

TC wrote:
Allen,

Thanks for the advice.

I like the theory of a faulty printer driver. To pursue that theory, I
asked the client to test the report on different printers. They tested
two printers, and the problem occurs on both. That puts a big hole in
the theory.

Is it possible for different printer drivers to share information about
how to render fonts? (For instance, do all Postscript printers use the
same font metrics, such that if one renders incorrectly, they can all
be expected to render incorrectly?) My new theory is that there is
something wrong with the configuration of their computers, and the
problem is not with the printer drivers per se, but with core software
used by several printer drivers (e.g. there is something wrong with
their Postscript software, or their True Type font definition for
Arial). Since I know nothing about fonts and drivers, this is just a
guess on my part. Does it sound like I'm on the right track?

Another challenge to faulty-printer-driver theory is that, if the
problem is not Access, I should see the bug while using other software.
I've experimented in Word with the same fonts, page setup, margins,
etc., and so far I haven't been able to make Word printouts exhibit the
problem. Can anyone offer an explanation for why Access might be the
only software to suffer this failure if, as my theory proposes, the
fault lies in the printer driver?
I tend to think Access has some issues when it comes to printing. I've
had issues with Access reports doing some exceptionally strange things.
One day I had a report suddenly begin printing one quarter size after
making a few modifications. No other software besides Access
manifested this problem. I resolved this issue by lowering the
resolution (DPI) in the printer's driver settings from its default of
1200 to 600 with no obvious degradation of quality or appearance. I
would see if your client is willing to test some different driver
settings (especially a 'draft mode' if there is such a setting) to see
what effect that has on the problem.

Bruce

Nov 15 '06 #4

P: n/a
TC wrote:
Allen,

Thanks for the advice.

I like the theory of a faulty printer driver. To pursue that theory, I
asked the client to test the report on different printers. They tested
two printers, and the problem occurs on both. That puts a big hole in
the theory.

Is it possible for different printer drivers to share information
about how to render fonts? (For instance, do all Postscript printers
use the same font metrics, such that if one renders incorrectly, they
can all be expected to render incorrectly?) My new theory is that
there is something wrong with the configuration of their computers,
and the problem is not with the printer drivers per se, but with core
software used by several printer drivers (e.g. there is something
wrong with their Postscript software, or their True Type font
definition for Arial). Since I know nothing about fonts and drivers,
this is just a guess on my part. Does it sound like I'm on the right
track?

Another challenge to faulty-printer-driver theory is that, if the
problem is not Access, I should see the bug while using other
software. I've experimented in Word with the same fonts, page setup,
margins, etc., and so far I haven't been able to make Word printouts
exhibit the problem. Can anyone offer an explanation for why Access
might be the only software to suffer this failure if, as my theory
proposes, the fault lies in the printer driver?
Are you sure the font in your report is installed on their PC? Windows
might be making a poor substitution.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Nov 15 '06 #5

P: n/a
Very strange. Arial should be a safe font: it's been stable for so long that
I can't see the font itself being an issue.

There was an issue under A2002 where an excessive number of fonts caused
problems, but AFAIK that's not an issue in A2003.

If the different printers they tried used the same language (Postscript),
then that certainly could affect the rending. To genuinely eliminate this as
a possible cause, they would need to try a completely different type of
printer (e.g. PCL or dot matrix), of a different brand (to minimize the
chance of common code.)

I can't say I've seen this issue, TC, and I do use some HP Postscript
printers. Have seen some rather stange issues with HPs that use PCL, and
those issues were solved by changing the printer driver.

I don't suppose there's any chance that some of these printers are
defaulting to Letter size and others to A4, so there is a slight difference
in the available width?

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"TC" <go*********@yahoo.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
Allen,

Thanks for the advice.

I like the theory of a faulty printer driver. To pursue that theory, I
asked the client to test the report on different printers. They tested
two printers, and the problem occurs on both. That puts a big hole in
the theory.

Is it possible for different printer drivers to share information about
how to render fonts? (For instance, do all Postscript printers use the
same font metrics, such that if one renders incorrectly, they can all
be expected to render incorrectly?) My new theory is that there is
something wrong with the configuration of their computers, and the
problem is not with the printer drivers per se, but with core software
used by several printer drivers (e.g. there is something wrong with
their Postscript software, or their True Type font definition for
Arial). Since I know nothing about fonts and drivers, this is just a
guess on my part. Does it sound like I'm on the right track?

Another challenge to faulty-printer-driver theory is that, if the
problem is not Access, I should see the bug while using other software.
I've experimented in Word with the same fonts, page setup, margins,
etc., and so far I haven't been able to make Word printouts exhibit the
problem. Can anyone offer an explanation for why Access might be the
only software to suffer this failure if, as my theory proposes, the
fault lies in the printer driver?
-TC
Allen Browne wrote:
>TC, hopefully you will get several different responses to your question.

Access does use the metrics from the printer driver to plan the layout of
the report. It sounds as if the printer driver your client is using is
faulty.

To demonstrate that the problem is the printer driver, have the client
choose a completely different printer, and print to that. The problem
will
disappear. Once they are convinced, they can take it up with the
manufacturer of their printer. Hopefully the manufacturer is aware of the
problem and already has a new driver available.

If the client cannot get an updated driver, but the printer has an
emulation
mode, they may be able to work around the problem that way.

Another way to demonstrate that Access uses the printer driver's metrics
for
report layout is to attempt to create or view an Access report on a
computer
that has no printer installed at all. If there is no printer, Access will
be
unable to calculate the report's layout.

Nov 16 '06 #6

P: n/a
"Allen Browne" <Al*********@SeeSig.invalidwrote in message
news:45***********************@per-qv1-newsreader-01.iinet.net.au...
Very strange. Arial should be a safe font: it's been stable for so long that I
can't see the font itself being an issue.
I've never had fonts cause a report truncation, but I did have one user (out of
26) on a particular app where the text on some labels and buttons on forms
didn't fit properly. This was Arial and he had Arial on his system but the font
files were not the same as on my system. When I replaced his files with copies
from my system the problem went away.

Can font files get corrupted?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Nov 16 '06 #7

P: n/a
I have seen this issue many times with my RTF control. The font metrics for
a standard TT font are not always the same for a Unicode version of the same
font.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"TC" <go*********@yahoo.comwrote in message
news:11**********************@k70g2000cwa.googlegr oups.com...
I've produced an Access application for a client. For one report, text
gets cut-off at the right margin when we print the report. It does this
only when we print; it doesn't happen when we view the report in
preview mode. Also, it occurs only at the client site; it doesn't occur
at my office or on any other computer I've tried.

I can describe the problem best with a specific example. (This is a
contrived example, but it is faithful to the real problem.)

On my computer, print preview and the printout both show:

Four score and seven years ago our fathers
brought forth on this continent, a new nation,
conceived in Liberty, and dedicated to the
proposition that all men are created equal.

On the client computer, print preview shows:

Four score and seven years ago our fathers brought
forth on this continent, a new nation, conceived in
Liberty, and dedicated to the proposition that all men
are created equal.

On the client computer, the printout shows:

Four score and seven years ago our fathers broug
forth on this continent, a new nation, conceived in
Liberty, and dedicated to the proposition that all m
are created equal.

The only font used is Arial. Everything is happening in Access 2003 and
Windows XP.

Despite the fact that we've tried to make everything exactly the same,
the report is being rendered differently on my computer vs. theirs. If
I can figure out why, I think I'll have a solution to the problem. My
gut feeling is that the bug is caused by their system configuration
(their fonts or their printer drivers), and not by Access or my
application. Nevertheless my application is the only thing which has
ever exhibited this behavior, so all fingers are pointing at me.

I've come here to see if there is a known bug in Access which could be
causing the problem. Has anyone seen something like this before?
-TC

Nov 16 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.