473,799 Members | 2,941 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Text is Truncated when Report Prints

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
7 4656
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*********@ya hoo.comwrote in message
news:11******** **************@ k70g2000cwa.goo glegroups.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
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

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
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
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*********@ya hoo.comwrote in message
news:11******** **************@ h48g2000cwc.goo glegroups.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
"Allen Browne" <Al*********@Se eSig.invalidwro te 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
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*********@ya hoo.comwrote in message
news:11******** **************@ k70g2000cwa.goo glegroups.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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
2192
by: N. Graves | last post by:
Hello, Please help me I'm still a newbie. I have an unbound text box on a report that I would like to build a expression to display it on the report. Something like txtboxSearchCriteria = !! in the OnPage Event and sometime this will work and sometime it will not. Is there a better simpler way?
4
2074
by: Jay | last post by:
This is a strange one that I can't seem to find a fix for. We have a Billing DB application (Access 2000 format) where we upload billing info in a comma delimited text file to our printer who prints and mails our bills. The application basically creates a table then exports a comma delimited file of that table. The problem is that we keep getting one seemingly random record in the text file that is misaligned. The record in question is...
6
3318
by: Mike Conklin | last post by:
This one really has me going. Probably something silly. I'm using dcount for a report to determine the number of different types of tests proctored in a semester. My report is based on a parameter query which is the recordsource for the report. The parameter is <=. The query returns the correct amounts upto the date entered (no need for "between" dates here). There are 8 textboxes with dcounts; 2 other boxes Sum some of these
3
6052
by: akparasite | last post by:
Hello all, I have a text box in the page header of my Access report that takes a dynamic string value from a named text box on an open form as its control source, written as follows: =Forms!frmExtractResInfo!txtSelectionCriteria Two problems/situations occur:
2
3310
by: Hers2keep | last post by:
I have a report that prints daily. The report needs to print whether or not there are records available. I read in an old post on this group that putting an unbound text box in the report footer, with the following code in the OnNoData event would work like a charm -- Private Sub Report_NoData(Cancel As Integer) Dim NoInboundLoads As TextBox Me!NoInboundLoads = "No inbound loads scheduled for today." Cancel = False End Sub
8
3695
by: michele | last post by:
Hi, i have in my crystal report viewer .net a multiline field. When i preview the report, the text in the field is clipped on the right, so some words are invisible... i'm going mad; i've searched on the crystal decision site but without success. Please help me, thanks Michele
3
1722
by: leo | last post by:
Hello Guys I have this problem in controlling a text in a Text Area. How can I do that, for example the field size is 200, when it reaches 50 it automatically goes to the next line. Because im having problem when viewing text in my report, it continuesly views in a straight line. Can you give me ASP code for that
1
2111
by: Thorben Grosser | last post by:
Hello newsgroup, I'm finally done with my folder-archiving tool, still there are some flaws. To label the folders, I use a Dymo LabelWriter 400 printer which works great for my purposes. I've created a report to print the labels. When I print (page 1 to 1 as I don't want to print all the records stored in the database) the
5
11280
by: dm3281 | last post by:
Hello, I have a text report from a mainframe that I need to parse. The report has about a 2580 byte header that contains binary information (garbage for the most part); although there are a couple areas that have ASCII text that I need to extract. At the end of the 2580 bytes, I can read the report like a standard text file. It should have CR/LF at the end of each line. What is the best way for me to read this report using C#. It is...
0
9686
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
10475
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10250
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
9068
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7564
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5585
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4139
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
3757
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2938
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.