TWIPS and Pixels

J

jaminjay

Hello All!

I've been having trouble with this for some time, and I keep coming up
with new information, but as yet, no solution.

I am printing barcodes on Access Reports using my own code. The
function takes a Container (the report) and a LabelZone (a report
rectangle object) to place the Code (passed as a string, usually the
..Value, .Text or .Tag of an object on the report). It uses these
values to calculate the size and orientation of the bar label printing,
then uses a loop to output the binary string (converted by another
function) as lines drawn directly on the report.

The problem seems that measurements for most graphical elements are in
TWIPS, except the DrawWidth property is in integer pixels. To get the
width of a bar, I originally suspected that the width of the LabelZone,
divided by the number of elements in the bitstream (the length of the
string) divided by 2 (as the width of a line is half on either side of
an imaginary centre down which it is drawn) would result in the correct
figure.

This does not work on all printers and if some printer is reinstalled
or a new one installed, the program needs to be tweaked to account for
the difference in device pixel size. The size also needs to be
calculated correctly for the screen preview of the report (lest people
think it's broken, and I'm a pedant).

So, how can I get the physical pixel size of the current, arbitrary,
print device (be it screen, default printer or specific target
printer)? I have modularised my code as it's used in a number of
reports and do not want to have to set it manually for each printer,
especially since most reports can get redirected to a number of
printers over which I have no control.

My research has unearthed a few posibilities, but none have seemed to
help (references to Printer.TwipsPerPixel[X|Y], for example, seem to
have no known reference, and I can't find them in the Object Browser).

Any and all help appreciated.


Benjamin


The original post regarding this is at:
microsoft.public.access.reportsprinting (article '.DrawWidth and
..Line').
 
M

Matthias Klaey

Hello All!

I've been having trouble with this for some time, and I keep coming up
with new information, but as yet, no solution.

I am printing barcodes on Access Reports using my own code.
[...]

I suggest that instead of your own code you use a barcode font. Just
google for "bar code font" or "barcode font"; you will find many
entries, both commercial and free.

HTH
Matthias Kläy
 
S

Stephen Lebans

Here is an older post of mine on this issue.

From: Stephen Lebans - view profile
Date: Tues, Jul 9 2002 11:26 pm
Email: "Stephen Lebans" <[email protected]>
Groups: microsoft.public.access.reports
Not yet ratedRating:
show options


Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse | Find messages by this author


It's a resolution issue. To understand how the width of a line in a
report is translated to the output device here is an older post of mine
on this subject. I realize you are not using the Line method of the
Report object to render the lines yourself but the logic is still
applies to your issue. To specify an exact line width of 1 pixel you
would have to take into account the output resolution of the printer. I
would suggest that you stay away from Hairline/ 1 pixel width lines. Use
a minimum of 2 to 3 pixels to avoid any problems. SInce oyu cannot
specify line widths in pixels perhaps you are getting points and pixels
mixed up. They are very different beasts!

From: Stephen Lebans ([email protected])
Subject: Re: DrawWidth prints different widths for different printers
Newsgroups: microsoft.public.access.reports
View this article only
Date: 2000-10-23 13:18:46 PST


' *** START ORIGINAL POST
Hi Matthias.
If I remember correctly the DrawWidth property is expressed in output
device Pixels. If Kathy desires a line of two points in width then you
will have to factor in the output device resolution. For example: 72
points per inch(Standard printer scale)
600 DPI output resolution
600/72 = 8 device pixels per printer point


So we would need to set the DrawWidth to 16 to get a 2 Point line width.


Obviously I've rounded 600/72 = 8.33 to 8 as the DrawWidth prop is an
Integer value. Also if accuracy is paramount remember that the output
resolution is never what is listed for the device. For example a laser
printer rated at 600DPI does not mean there are:
600 * 8.5 = 5100 pixels horizontally
600 * 11 = 6600 pixels vertically
on the output page. Most printing devices have a nonprint area, a border
that their print engine cannot image onto. This reduces the effective
output resolution by the amount of this "margin".
' *** END ORIGINAL POST



--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.


Hello All!

I've been having trouble with this for some time, and I keep coming up
with new information, but as yet, no solution.

I am printing barcodes on Access Reports using my own code. The
function takes a Container (the report) and a LabelZone (a report
rectangle object) to place the Code (passed as a string, usually the
.Value, .Text or .Tag of an object on the report). It uses these
values to calculate the size and orientation of the bar label printing,
then uses a loop to output the binary string (converted by another
function) as lines drawn directly on the report.

The problem seems that measurements for most graphical elements are in
TWIPS, except the DrawWidth property is in integer pixels. To get the
width of a bar, I originally suspected that the width of the LabelZone,
divided by the number of elements in the bitstream (the length of the
string) divided by 2 (as the width of a line is half on either side of
an imaginary centre down which it is drawn) would result in the correct
figure.

This does not work on all printers and if some printer is reinstalled
or a new one installed, the program needs to be tweaked to account for
the difference in device pixel size. The size also needs to be
calculated correctly for the screen preview of the report (lest people
think it's broken, and I'm a pedant).

So, how can I get the physical pixel size of the current, arbitrary,
print device (be it screen, default printer or specific target
printer)? I have modularised my code as it's used in a number of
reports and do not want to have to set it manually for each printer,
especially since most reports can get redirected to a number of
printers over which I have no control.

My research has unearthed a few posibilities, but none have seemed to
help (references to Printer.TwipsPerPixel[X|Y], for example, seem to
have no known reference, and I can't find them in the Object Browser).

Any and all help appreciated.


Benjamin


The original post regarding this is at:
microsoft.public.access.reportsprinting (article '.DrawWidth and
.Line').
 
J

jaminjay

Stephen said:
Here is an older post of mine on this issue.


Thankyou. I have read this post in two other places on this forum.


The trick I need is gathering the properties from the current target
device to calculate the DrawWidth for that device, which is not
necessarily the same for all users of the system and is definately
different between screen (preview) and printer rendering.
 
S

Stephen Lebans

Have a look at the code in the TextHeightWidth solution on my site as it
shows you how to determine whether you are being called from a Form or
report and how to get the current resolution of the output device.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
 
J

jaminjay

In the meantime, I have managed to work out the
{Report}.Printer.PrintQuality function will provide the correct scale
figure (1440 / .PrintQuality) for the print preview (or, so it would
appear).

I think there is a bit of confusion in taking this built page and
translating it to a printer (if only all the printers in the company
had the same firmware and the correct drivers installed... ;-).

I am still testing my code to see if it works on other target printers,
thus isolating it to a driver issue...

Benjamin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top