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 7 4605
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
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
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
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
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.
"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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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 = !!...
|
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...
|
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...
|
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:
...
|
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,...
|
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...
|
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...
|
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.
...
|
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...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
| |