ACCURACY of making templates on a printer

microsoft.public.vb.general.discussion

18 Mar 2009 6:29 PM

Randy Gardner

Is it possible to create very accurately dimensioned templates by setting
printer properties: height, width, zoom, drawwidth, etc. and printing from VB?

I have found that there seem to be some force margin values that I have not
been able to over ride in the past.

Also, I note that height and width are twips setting, yet printers work in
DPI.

I use HP ink jet printer products.

Setting aside paper or mylar changing size due to time and conditions: when
I say accurate I'm looking for less than +/- 0.0025". (Center of line to
center of line)

--
Thank you,

Randy

18 Mar 2009 6:35 PM

Kevin Provance

Is there an actual VB question in there someplace? <g>

Show quoteHide quote

"Randy Gardner" <RandyGard***@discussions.microsoft.com> wrote in message
news:5539F07E-68B2-4357-9A93-E23B63AFF7F5@microsoft.com...
| Is it possible to create very accurately dimensioned templates by setting
| printer properties: height, width, zoom, drawwidth, etc. and printing from
VB?
|
| I have found that there seem to be some force margin values that I have
not
| been able to over ride in the past.
|
| Also, I note that height and width are twips setting, yet printers work in
| DPI.
|
| I use HP ink jet printer products.
|
| Setting aside paper or mylar changing size due to time and conditions:
when
| I say accurate I'm looking for less than +/- 0.0025". (Center of line to
| center of line)
|
| --
| Thank you,
|
| Randy

Are all your drivers up to date? click for free checkup

18 Mar 2009 7:25 PM

Jeff Johnson

"Kevin Provance" <Bill.McCarthy.Is.Stalking.TPASoft.com..@.nd.efblows.kmgda>
wrote in message news:eRj9Hi$pJHA.1172@TK2MSFTNGP05.phx.gbl...

> | Is it possible to create very accurately dimensioned templates by
> setting
> | printer properties: height, width, zoom, drawwidth, etc. and printing
> from
> VB?

> Is there an actual VB question in there someplace? <g>

You mean like the very first sentence?

18 Mar 2009 8:52 PM

Michael Williams

Yes, if you make sure the paper is always stacked and loaded perfectly then
you can position and size printed output accurately on the page when
printing from VB, but you cannot make a silk purse out of a sow's ear (as
the saying goes!) so you will never be able to guarantee positioning to a
greater accuracy than the manufacturing tolerances of your printer allow.

> I use HP ink jet printer products. When I say accurate
> I'm looking for less than +/- 0.0025".

Unless you have an extremely expensive printer then you'll probably find
that the manufacturing tolerances are greater than that, although you will
be able to get reasonably close to it. For example I've just been looking
online at some HP printers and the acceptable positioning tolerance seems to
be in the region of 0.03 inches with an "acceptable skew" of an additional
0.03 inches over the height of a 10 inch page. These seem to be the maximum
acceptable tolerances and so if you're lucky you'll find that your own
printer performs better than that, but even so I think you'll be hard
pressed to guarantee accuracy over the whole page to the value of +/- 0.0025
inches you have asked for no matter what application you use to print the
output.

> I have found that there seem to be some force margin values
> that I have not been able to over ride in the past.

Those will be the printer's "unprintable margins", which are different sizes
at different settings, even on the same printer depending on whether or not
it is currently set to normal or borderless or "minimize margins" or
whatever setting your specific printer provides. Essentially the page has a
large rectangular "printable area" that is usually a bit smaller than the
physical page and the top left corner of which is positioned a specific
distance from the top left corner of the page.

As far as VB is concerned (by default) the Printer Object coordinates (0, 0)
point to the top left corner of the "printable area" and not to the top left
corner of the physical page. This is not a Visual basic thing, it is a
printer thing, and all applications which print stuff, including Micro$oft
Word and everything else, need to take those things into account. This is
not be a problem as far as positioning your output when printing from VB is
concerned because you can use the GetDeviceCaps API to "read" both the size
and the position of the printable area of the page and you can then take
those values into account when printing your stuff.

Neither your VB app nor any other application (MS Word or whatever) can
actually print anything into the "unprintable borders" (if there currently
are any on your printer at its current settings, which there usually are)
because ink will simply not be deposited there, but you can take them into
account when positioning your stuff by reading the details with
GetDeviceCaps and by then adjusting the Printer Object's ScaleLeft and
ScaleTop properties to effectively cause Printer Object coordinates (0, 0)
to point to the top left corner of the physical page rather than the top
left corner of the "printable area" (which is the default).

> Also, I note that height and width are twips setting,
> yet printers work in DPI.

That doesn't matter. Most devices (screens and printers for example) use
pixels as their native units, but The Visual Basic Printer Object just
happens to always use twips as the units of measurement when it tells you
the Width and Height of the page (these values relate to the width and
height of the entire physical page). However, VB knows exactly how many
twips there are in one printer pixel (a value which may be different for
different printers and may also be different for the same printer at its
different settings) so there is no problem. A twip by the way is 1/1440
inch, so there are 1440 twips in an inch. Incidentally, inches in Windows
are "logical inches" and on the screen they are not necessarily (not usually
in fact) the same size as a real world inch if you were to hold a ruler up
against the screen. However, with printers a Windows logical inch /is/
exactly the same size as a real world inch, so there are no problems there.
As far as ScaleWidth and ScaleHeight are concerned, they are the
measurements of the "printable area" of the page and are therefore not
usually the same as the Width and Height you have mentioned. Also, the
ScaleWidth and ScaleHeight can use any units of measurement you desire by
setting the Printer's ScaleMode property to the appropriate value. Since you
mentioned inches in your post then you are probably most comfortable with
those units of measurement, so it would probably be best to set the
Printer's ScaleMode to vbInches and work from there.

> I use HP ink jet printer products.

That could be a problem :-) Seriously though, it could be a slight problem
on some models of HP printer. I've had a couple myself which misreport the
size of their unprintable margins at certain printer settings. The
difference is not massive (I recall something in the region of one tenth of
an inch in the vertical direction on the worst one) but it is certainly
enough to throw things out, especially when you are printing stuff onto pre
printed forms. There may be other printers which have similar problems, but
it just happened to be an HP that I had it on and I never came across the
problem in any of the other printers I've had previously and since (except
another different HP model!). Again this is not a VB problem, but is a
printer problem. On such printers any application on your machine, including
Micros$oft Word (I keep using that as an example simply because people tend
to trust it!) and Publisher etc, would print things in the wrong place by
about a tenth of an inch. With VB of course you can write your code to
adjust for such a misreported margin if you were unfortunate enough to have
a printer which exhibited it, but it would need to be a "hard coded" value
arrived at by running a few simple trial prints and it would work only if
you applied the correction only to that one specific model which had the
problem and it would cease to work if HP ever got around to fixing the
problem for you (which by my experience is unlikely!). It is actually a
printer driver problem, but in the case of the two HP printers on which I
had the problem they never did get around to producing an updated driver for
it. I can't remember which model it was now, but it was a multi purpose
inkjet.

Your post was not very detailed regarding exactly what you want to print and
it covers a few bases that you may not need to cover, so perhaps you might
like to post again giving some more details of exactly what you want to do.
In the meantime, just to show that this stuff is by no means as complicated
as it sounds, try the following test code. Paste it into a VB Form
containing a Command Button. When you run the code and click the button a
page should be printed on your default printer with a one inch square
printed so that its top left corner is positioned at (1, 1) inches from the
top left corner of the physical page. If your printer manufacturing
tolerances are okay and if the HP model of printer you have is not one of
those which misreports its unprintable margins then the printout should be
fairly accurately sized and positioned.

Mike

Option Explicit
Private Declare Function GetDeviceCaps Lib "gdi32" _
(ByVal hdc As Long, ByVal nindex As Long) As Long
Private Const PHYSICALOFFSETX As Long = 112
Private Const PHYSICALOFFSETY As Long = 113

Private Sub SetPrinterOrigin(x As Single, y As Single)
With Printer
.ScaleLeft = .ScaleX(GetDeviceCaps(.hdc, PHYSICALOFFSETX), _
vbPixels, .ScaleMode) - x
.ScaleTop = .ScaleY(GetDeviceCaps(.hdc, PHYSICALOFFSETY), _
vbPixels, .ScaleMode) - y
.CurrentX = 0
.CurrentY = 0
End With
End Sub

Private Sub Command1_Click()
Printer.Print
Printer.ScaleMode = vbInches
' Set up Printer so that coordinates (0, 0) point
' to the top left corner of the physcial page
' rather than the top left corner of the
' printable area
SetPrinterOrigin 0, 0
' Printer.DrawWidth is unusual in that it is always
' specified in Printer pixels regardless of the ScaleMode
' so we need to perform a conversion here:
Printer.DrawWidth = Printer.ScaleX(0.01, vbInches, vbPixels)
' Draw a one inch square with the top left corner
' located at (1, 1) inches from the top left
' corner of the physical page
Printer.Line (1, 1)-(2, 2), , B
Printer.EndDoc
End Sub

19 Mar 2009 5:12 PM

Micheal Williams

Very informative!!

You are truely an exceptional talent on this site and a valued asset!!!

--
Thank you,

Randy

Show quoteHide quote

"Michael Williams" wrote:

> "Randy Gardner" <RandyGard***@discussions.microsoft.com> wrote in message
> news:5539F07E-68B2-4357-9A93-E23B63AFF7F5@microsoft.com...
>
> > Is it possible to create very accurately dimensioned templates
> > by setting printer properties: height, width, zoom, drawwidth,
> > etc. and printing from VB?
>
> Yes, if you make sure the paper is always stacked and loaded perfectly then
> you can position and size printed output accurately on the page when
> printing from VB, but you cannot make a silk purse out of a sow's ear (as
> the saying goes!) so you will never be able to guarantee positioning to a
> greater accuracy than the manufacturing tolerances of your printer allow.
>
> > I use HP ink jet printer products. When I say accurate
> > I'm looking for less than +/- 0.0025".
>
> Unless you have an extremely expensive printer then you'll probably find
> that the manufacturing tolerances are greater than that, although you will
> be able to get reasonably close to it. For example I've just been looking
> online at some HP printers and the acceptable positioning tolerance seems to
> be in the region of 0.03 inches with an "acceptable skew" of an additional
> 0.03 inches over the height of a 10 inch page. These seem to be the maximum
> acceptable tolerances and so if you're lucky you'll find that your own
> printer performs better than that, but even so I think you'll be hard
> pressed to guarantee accuracy over the whole page to the value of +/- 0.0025
> inches you have asked for no matter what application you use to print the
> output.
>
> > I have found that there seem to be some force margin values
> > that I have not been able to over ride in the past.
>
> Those will be the printer's "unprintable margins", which are different sizes
> at different settings, even on the same printer depending on whether or not
> it is currently set to normal or borderless or "minimize margins" or
> whatever setting your specific printer provides. Essentially the page has a
> large rectangular "printable area" that is usually a bit smaller than the
> physical page and the top left corner of which is positioned a specific
> distance from the top left corner of the page.
>
> As far as VB is concerned (by default) the Printer Object coordinates (0, 0)
> point to the top left corner of the "printable area" and not to the top left
> corner of the physical page. This is not a Visual basic thing, it is a
> printer thing, and all applications which print stuff, including Micro$oft
> Word and everything else, need to take those things into account. This is
> not be a problem as far as positioning your output when printing from VB is
> concerned because you can use the GetDeviceCaps API to "read" both the size
> and the position of the printable area of the page and you can then take
> those values into account when printing your stuff.
>
> Neither your VB app nor any other application (MS Word or whatever) can
> actually print anything into the "unprintable borders" (if there currently
> are any on your printer at its current settings, which there usually are)
> because ink will simply not be deposited there, but you can take them into
> account when positioning your stuff by reading the details with
> GetDeviceCaps and by then adjusting the Printer Object's ScaleLeft and
> ScaleTop properties to effectively cause Printer Object coordinates (0, 0)
> to point to the top left corner of the physical page rather than the top
> left corner of the "printable area" (which is the default).
>
> > Also, I note that height and width are twips setting,
> > yet printers work in DPI.
>
> That doesn't matter. Most devices (screens and printers for example) use
> pixels as their native units, but The Visual Basic Printer Object just
> happens to always use twips as the units of measurement when it tells you
> the Width and Height of the page (these values relate to the width and
> height of the entire physical page). However, VB knows exactly how many
> twips there are in one printer pixel (a value which may be different for
> different printers and may also be different for the same printer at its
> different settings) so there is no problem. A twip by the way is 1/1440
> inch, so there are 1440 twips in an inch. Incidentally, inches in Windows
> are "logical inches" and on the screen they are not necessarily (not usually
> in fact) the same size as a real world inch if you were to hold a ruler up
> against the screen. However, with printers a Windows logical inch /is/
> exactly the same size as a real world inch, so there are no problems there.
> As far as ScaleWidth and ScaleHeight are concerned, they are the
> measurements of the "printable area" of the page and are therefore not
> usually the same as the Width and Height you have mentioned. Also, the
> ScaleWidth and ScaleHeight can use any units of measurement you desire by
> setting the Printer's ScaleMode property to the appropriate value. Since you
> mentioned inches in your post then you are probably most comfortable with
> those units of measurement, so it would probably be best to set the
> Printer's ScaleMode to vbInches and work from there.
>
> > I use HP ink jet printer products.
>
> That could be a problem :-) Seriously though, it could be a slight problem
> on some models of HP printer. I've had a couple myself which misreport the
> size of their unprintable margins at certain printer settings. The
> difference is not massive (I recall something in the region of one tenth of
> an inch in the vertical direction on the worst one) but it is certainly
> enough to throw things out, especially when you are printing stuff onto pre
> printed forms. There may be other printers which have similar problems, but
> it just happened to be an HP that I had it on and I never came across the
> problem in any of the other printers I've had previously and since (except
> another different HP model!). Again this is not a VB problem, but is a
> printer problem. On such printers any application on your machine, including
> Micros$oft Word (I keep using that as an example simply because people tend
> to trust it!) and Publisher etc, would print things in the wrong place by
> about a tenth of an inch. With VB of course you can write your code to
> adjust for such a misreported margin if you were unfortunate enough to have
> a printer which exhibited it, but it would need to be a "hard coded" value
> arrived at by running a few simple trial prints and it would work only if
> you applied the correction only to that one specific model which had the
> problem and it would cease to work if HP ever got around to fixing the
> problem for you (which by my experience is unlikely!). It is actually a
> printer driver problem, but in the case of the two HP printers on which I
> had the problem they never did get around to producing an updated driver for
> it. I can't remember which model it was now, but it was a multi purpose
> inkjet.
>
> Your post was not very detailed regarding exactly what you want to print and
> it covers a few bases that you may not need to cover, so perhaps you might
> like to post again giving some more details of exactly what you want to do.
> In the meantime, just to show that this stuff is by no means as complicated
> as it sounds, try the following test code. Paste it into a VB Form
> containing a Command Button. When you run the code and click the button a
> page should be printed on your default printer with a one inch square
> printed so that its top left corner is positioned at (1, 1) inches from the
> top left corner of the physical page. If your printer manufacturing
> tolerances are okay and if the HP model of printer you have is not one of
> those which misreports its unprintable margins then the printout should be
> fairly accurately sized and positioned.
>
> Mike
>
> Option Explicit
> Private Declare Function GetDeviceCaps Lib "gdi32" _
> (ByVal hdc As Long, ByVal nindex As Long) As Long
> Private Const PHYSICALOFFSETX As Long = 112
> Private Const PHYSICALOFFSETY As Long = 113
>
> Private Sub SetPrinterOrigin(x As Single, y As Single)
> With Printer
>   .ScaleLeft = .ScaleX(GetDeviceCaps(.hdc, PHYSICALOFFSETX), _
>     vbPixels, .ScaleMode) - x
>   .ScaleTop = .ScaleY(GetDeviceCaps(.hdc, PHYSICALOFFSETY), _
>     vbPixels, .ScaleMode) - y
>   .CurrentX = 0
>   .CurrentY = 0
> End With
> End Sub
>
> Private Sub Command1_Click()
> Printer.Print
> Printer.ScaleMode = vbInches
> ' Set up Printer so that coordinates (0, 0) point
> ' to the top left corner of the physcial page
> ' rather than the top left corner of the
> ' printable area
> SetPrinterOrigin 0, 0
> ' Printer.DrawWidth is unusual in that it is always
> ' specified in Printer pixels regardless of the ScaleMode
> ' so we need to perform a conversion here:
> Printer.DrawWidth = Printer.ScaleX(0.01, vbInches, vbPixels)
> ' Draw a one inch square with the top left corner
> ' located at (1, 1) inches from the top left
> ' corner of the physical page
> Printer.Line (1, 1)-(2, 2), , B
> Printer.EndDoc
> End Sub
>
>
>

19 Mar 2009 6:03 PM

Michael Williams

"Micheal Williams" <Micheal Willi***@discussions.microsoft.com> wrote in
message news:00A69D93-DE67-43F7-8530-53AAE9376B11@microsoft.com...

> Very informative!! You are truely an exceptional talent
> on this site and a valued asset!!! Thank you,
> Randy

Whilst I can't argue with your sentiments [;-)] I must admit to being a
little bit curious regarding the header and declared originator of your
post. You've signed yourself Randy and your post carries a virtually
identical IP address (somewhere near Seattle) as the original post by Randy
Gardner, who I assume you are, and yet the declared name of the sender is
almost identical to my own! What's going on there?

Mike

Show quoteHide quote

>> "Michael Williams" wrote:

>> Yes, if you make sure the paper is always stacked and loaded perfectly
>> then
>> you can position and size printed output accurately on the page when
>> printing from VB, but you cannot make a silk purse out of a sow's ear (as
>> the saying goes!) so you will never be able to guarantee positioning to a
>> greater accuracy than the manufacturing tolerances of your printer allow.
>>
>> > I use HP ink jet printer products. When I say accurate
>> > I'm looking for less than +/- 0.0025".
>>
>> Unless you have an extremely expensive printer then you'll probably find
>> that the manufacturing tolerances are greater than that, although you
>> will
>> be able to get reasonably close to it. For example I've just been looking
>> online at some HP printers and the acceptable positioning tolerance seems
>> to
>> be in the region of 0.03 inches with an "acceptable skew" of an
>> additional
>> 0.03 inches over the height of a 10 inch page. These seem to be the
>> maximum
>> acceptable tolerances and so if you're lucky you'll find that your own
>> printer performs better than that, but even so I think you'll be hard
>> pressed to guarantee accuracy over the whole page to the value of +/-
>> 0.0025
>> inches you have asked for no matter what application you use to print the
>> output.
>>
>> > I have found that there seem to be some force margin values
>> > that I have not been able to over ride in the past.
>>
>> Those will be the printer's "unprintable margins", which are different
>> sizes
>> at different settings, even on the same printer depending on whether or
>> not
>> it is currently set to normal or borderless or "minimize margins" or
>> whatever setting your specific printer provides. Essentially the page has
>> a
>> large rectangular "printable area" that is usually a bit smaller than the
>> physical page and the top left corner of which is positioned a specific
>> distance from the top left corner of the page.
>>
>> As far as VB is concerned (by default) the Printer Object coordinates (0,
>> 0)
>> point to the top left corner of the "printable area" and not to the top
>> left
>> corner of the physical page. This is not a Visual basic thing, it is a
>> printer thing, and all applications which print stuff, including
>> Micro$oft
>> Word and everything else, need to take those things into account. This is
>> not be a problem as far as positioning your output when printing from VB
>> is
>> concerned because you can use the GetDeviceCaps API to "read" both the
>> size
>> and the position of the printable area of the page and you can then take
>> those values into account when printing your stuff.
>>
>> Neither your VB app nor any other application (MS Word or whatever) can
>> actually print anything into the "unprintable borders" (if there
>> currently
>> are any on your printer at its current settings, which there usually are)
>> because ink will simply not be deposited there, but you can take them
>> into
>> account when positioning your stuff by reading the details with
>> GetDeviceCaps and by then adjusting the Printer Object's ScaleLeft and
>> ScaleTop properties to effectively cause Printer Object coordinates (0,
>> 0)
>> to point to the top left corner of the physical page rather than the top
>> left corner of the "printable area" (which is the default).
>>
>> > Also, I note that height and width are twips setting,
>> > yet printers work in DPI.
>>
>> That doesn't matter. Most devices (screens and printers for example) use
>> pixels as their native units, but The Visual Basic Printer Object just
>> happens to always use twips as the units of measurement when it tells you
>> the Width and Height of the page (these values relate to the width and
>> height of the entire physical page). However, VB knows exactly how many
>> twips there are in one printer pixel (a value which may be different for
>> different printers and may also be different for the same printer at its
>> different settings) so there is no problem. A twip by the way is 1/1440
>> inch, so there are 1440 twips in an inch. Incidentally, inches in Windows
>> are "logical inches" and on the screen they are not necessarily (not
>> usually
>> in fact) the same size as a real world inch if you were to hold a ruler
>> up
>> against the screen. However, with printers a Windows logical inch /is/
>> exactly the same size as a real world inch, so there are no problems
>> there.
>> As far as ScaleWidth and ScaleHeight are concerned, they are the
>> measurements of the "printable area" of the page and are therefore not
>> usually the same as the Width and Height you have mentioned. Also, the
>> ScaleWidth and ScaleHeight can use any units of measurement you desire by
>> setting the Printer's ScaleMode property to the appropriate value. Since
>> you
>> mentioned inches in your post then you are probably most comfortable with
>> those units of measurement, so it would probably be best to set the
>> Printer's ScaleMode to vbInches and work from there.
>>
>> > I use HP ink jet printer products.
>>
>> That could be a problem :-) Seriously though, it could be a slight
>> problem
>> on some models of HP printer. I've had a couple myself which misreport
>> the
>> size of their unprintable margins at certain printer settings. The
>> difference is not massive (I recall something in the region of one tenth
>> of
>> an inch in the vertical direction on the worst one) but it is certainly
>> enough to throw things out, especially when you are printing stuff onto
>> pre
>> printed forms. There may be other printers which have similar problems,
>> but
>> it just happened to be an HP that I had it on and I never came across the
>> problem in any of the other printers I've had previously and since
>> (except
>> another different HP model!). Again this is not a VB problem, but is a
>> printer problem. On such printers any application on your machine,
>> including
>> Micros$oft Word (I keep using that as an example simply because people
>> tend
>> to trust it!) and Publisher etc, would print things in the wrong place by
>> about a tenth of an inch. With VB of course you can write your code to
>> adjust for such a misreported margin if you were unfortunate enough to
>> have
>> a printer which exhibited it, but it would need to be a "hard coded"
>> value
>> arrived at by running a few simple trial prints and it would work only if
>> you applied the correction only to that one specific model which had the
>> problem and it would cease to work if HP ever got around to fixing the
>> problem for you (which by my experience is unlikely!). It is actually a
>> printer driver problem, but in the case of the two HP printers on which I
>> had the problem they never did get around to producing an updated driver
>> for
>> it. I can't remember which model it was now, but it was a multi purpose
>> inkjet.
>>
>> Your post was not very detailed regarding exactly what you want to print
>> and
>> it covers a few bases that you may not need to cover, so perhaps you
>> might
>> like to post again giving some more details of exactly what you want to
>> do.
>> In the meantime, just to show that this stuff is by no means as
>> complicated
>> as it sounds, try the following test code. Paste it into a VB Form
>> containing a Command Button. When you run the code and click the button a
>> page should be printed on your default printer with a one inch square
>> printed so that its top left corner is positioned at (1, 1) inches from
>> the
>> top left corner of the physical page. If your printer manufacturing
>> tolerances are okay and if the HP model of printer you have is not one of
>> those which misreports its unprintable margins then the printout should
>> be
>> fairly accurately sized and positioned.
>>
>> Mike
>>
>> Option Explicit
>> Private Declare Function GetDeviceCaps Lib "gdi32" _
>> (ByVal hdc As Long, ByVal nindex As Long) As Long
>> Private Const PHYSICALOFFSETX As Long = 112
>> Private Const PHYSICALOFFSETY As Long = 113
>>
>> Private Sub SetPrinterOrigin(x As Single, y As Single)
>> With Printer
>>   .ScaleLeft = .ScaleX(GetDeviceCaps(.hdc, PHYSICALOFFSETX), _
>>     vbPixels, .ScaleMode) - x
>>   .ScaleTop = .ScaleY(GetDeviceCaps(.hdc, PHYSICALOFFSETY), _
>>     vbPixels, .ScaleMode) - y
>>   .CurrentX = 0
>>   .CurrentY = 0
>> End With
>> End Sub
>>
>> Private Sub Command1_Click()
>> Printer.Print
>> Printer.ScaleMode = vbInches
>> ' Set up Printer so that coordinates (0, 0) point
>> ' to the top left corner of the physcial page
>> ' rather than the top left corner of the
>> ' printable area
>> SetPrinterOrigin 0, 0
>> ' Printer.DrawWidth is unusual in that it is always
>> ' specified in Printer pixels regardless of the ScaleMode
>> ' so we need to perform a conversion here:
>> Printer.DrawWidth = Printer.ScaleX(0.01, vbInches, vbPixels)
>> ' Draw a one inch square with the top left corner
>> ' located at (1, 1) inches from the top left
>> ' corner of the physical page
>> Printer.Line (1, 1)-(2, 2), , B
>> Printer.EndDoc
>> End Sub
>>
>>
>>

19 Mar 2009 7:18 PM

Jeff Johnson

"Michael Williams" <M***@WhiskeyAndCoke.com> wrote in message
news:%23NpuezLqJHA.4108@TK2MSFTNGP06.phx.gbl...

> Whilst I can't argue with your sentiments [;-)] I must admit to being a
> little bit curious regarding the header and declared originator of your
> post. You've signed yourself Randy and your post carries a virtually
> identical IP address (somewhere near Seattle) as the original post by
> Randy Gardner, who I assume you are, and yet the declared name of the
> sender is almost identical to my own! What's going on there?

I noticed the name thing too. I think it's because he's using the Web
interface (yuck!) and he might have gotten a little over-zealous and tried
to type your name into the From box thinking it was the subject line or
something.

19 Mar 2009 12:21 AM

Bill McCarthy

Hi Randy,

> Setting aside paper or mylar changing size due to time and conditions:
> when
> I say accurate I'm looking for less than +/- 0.0025". (Center of line to
> center of line)

Sounds almost like you're printing circuit boards or minute bar codes. +/-
0.0025" is going to be hard to obtain *reliably*. I think you'll need to
track down a specialist printer.

Show quoteHide quote

"Randy Gardner" <RandyGard***@discussions.microsoft.com> wrote in message
news:5539F07E-68B2-4357-9A93-E23B63AFF7F5@microsoft.com...
> Is it possible to create very accurately dimensioned templates by setting
> printer properties: height, width, zoom, drawwidth, etc. and printing from
> VB?
>
> I have found that there seem to be some force margin values that I have
> not
> been able to over ride in the past.
>
> Also, I note that height and width are twips setting, yet printers work in
> DPI.
>
> I use HP ink jet printer products.
>
> Setting aside paper or mylar changing size due to time and conditions:
> when
> I say accurate I'm looking for less than +/- 0.0025". (Center of line to
> center of line)
>
> --
> Thank you,
>
> Randy

19 Mar 2009 9:53 PM

Karl E. Peterson

Bill McCarthy wrote:

>> I say accurate I'm looking for less than +/- 0.0025". (Center of line to
>> center of line)
>
> Sounds almost like you're printing circuit boards or minute bar codes. +/-
> 0.0025" is going to be hard to obtain *reliably*. I think you'll need to
> track down a specialist printer.

You think? 600dpi is 0.00167" resolution. I don't do much printing, but are you
suggesting that the standard Windows printer drivers just aren't accurate enough to
translate coordinates to dots accurately?

--
..NET: It's About Trust!
http://vfred.mvps.org

19 Mar 2009 10:01 PM

Nobody

Show quote Hide quote

If accuracy is critical, print a rectangle around the whole drawing or print
"+" signs and use a relative position to these marks rather than relying on
the distance from paper edge.

20 Mar 2009 9:09 AM

Michael Williams

"Nobody" <nob***@nobody.com> wrote in message
news:eEJU54NqJHA.4840@TK2MSFTNGP06.phx.gbl...

> If accuracy is critical, print a rectangle around the whole
> drawing or print "+" signs and use a relative position to
> these marks rather than relying on the distance from
> paper edge.

That's a good suggestion if the OP is looking for relative positional
accuracy between the various elements he is printing on a single page.
Personally I assumed from his mention of templates and from his mention of
what he called "forced margin values" which he was having problems with that
he was looking for absolute positional accuracy on the page so that other
things could be overprinted onto the template at a later date, perhaps even
on a different printer, or perhaps so that he could print things onto pre
printed templates. I did ask him to post again giving more precise details
of exactly what it is he wants to do, but in his only response so far he
never replied to that question.

Mike

20 Mar 2009 4:18 PM

Bob O`Bob

Michael Williams wrote:
Show quoteHide quote

> "Nobody" <nob***@nobody.com> wrote in message
> news:eEJU54NqJHA.4840@TK2MSFTNGP06.phx.gbl...
>
>> If accuracy is critical, print a rectangle around the whole
>> drawing or print "+" signs and use a relative position to
>> these marks rather than relying on the distance from
>> paper edge.
>
> That's a good suggestion if the OP is looking for relative positional
> accuracy between the various elements he is printing on a single page.
> Personally I assumed from his mention of templates and from his mention
> of what he called "forced margin values" which he was having problems
> with that he was looking for absolute positional accuracy on the page so
> that other things could be overprinted onto the template at a later
> date, perhaps even on a different printer, or perhaps so that he could
> print things onto pre printed templates. I did ask him to post again
> giving more precise details of exactly what it is he wants to do, but in
> his only response so far he never replied to that question.
>
> Mike
>
>

Well, there is precision, and there is accuracy. Not the same at all.
The subject line seems pretty clear.

And it's not a software issue. As Karl pointed out, the software
is going to be able to position the dots "perfectly" within any
resolution supported by the interface.

However, there is NO such printer out there, and never has been,
unless it also had "plotter" as part of its official name.

Bob

20 Mar 2009 7:02 PM

Michael Williams

"Bob O`Bob" <filter***@yahoogroups.com> wrote in message
news:utrG5dXqJHA.1248@TK2MSFTNGP03.phx.gbl...

> Well, there is precision, and there is accuracy. Not
> the same at all. The subject line seems pretty clear.

I'm not quite sure why you are making that statement in your response to my
post? It does not contradict or add anything at all to what I have said. I
never mentioned precision (apart from asking the OP to be more precise in
stating his requirements, which is a totally different use of that word). In
all my responses I talked about accuracy, not precision, so I'm not sure
what point you are making?

The OP has said he wants accuracy when making templates on a printer, and
you are of course right in that there is a difference between accuracy and
precision, but the OP has said he is talking about accuracy, and nothing in
my own responses has contradicted that. The phrase "making templates" can be
interpreted in a number of subtly different ways, depending on what the OP
is actually doing, and as far as I am concerned we still do not know whether
the OP is talking about the accurate positioning of each element he is
printing relative to the physical page (which is what I thought he might
mean if he is perhaps printing a template onto which other things need to be
printed at a later date and perhaps on another machine), or whether he is
merely talking about the accurate positioning of each element on the page
with respect to each other element he is printing on the same page at the
same time (which "Nobody" has suggested he might mean), or perhaps both.

The OP is using a HP inkjet printer and he will almost certainly not
reliably get the former (accurate positioning with respect to the page), at
least not to the degree he is asking for, as I pointed out in my initial
response. But that does not mean he should not strive for the best he can
obtain with his equipment, which I and others have helped him to do. If he
is lucky then the model of printer he is using will have a facility that
allows him to manually adjust the printing positions relative to the
physical edges of the page to compensate for manufacturing tolerances (in a
similar way to the facility that allows him to manually adjust or that
sometimes automatically adjusts the placing of the colours and black
relative to each other), or indeed he can make such adjustments in code with
some trial and error provided that he accepts the fact that the code will in
that specific respect work properly only with that specific printer, but
whatever he does, and even if he does none of those things, he still needs
to make sure that his software (his own VB program) is properly taking
account of the current position of the "printable rectangle" relative to the
physical page, as I have shown him how to do. Are you perhaps suggesting
that he should not do that?

He will of course fare better if he is interested only in the accurate
positioning of each element he is printing on the page with respect to each
other element he is printing at the same time onto the same page and if he
is not concerned about the accurate positioning of those elements relative
to the physical page, and indeed he might even get close to his stated
requirements in that respect, as long as he also takes particular care
regarding the printer settings he is using. He will not of course get
absolute accuracy, but he might get close to his stated requirements.

> And it's not a software issue. As Karl pointed out, the
> software is going to be able to position the dots "perfectly"
> within any resolution supported by the interface [1].

Actually it is both a software and a hardware issue. If the software (the
OP's VB program code) does not even attempt to position the output correctly
on the page then the hardware cannot succeed, which is why at the very least
the OP needs to make his software take account of the current size and
position of the "unprintable margins", and which is why I posted some code
which enables him to do so. Are you suggesting that he perhaps should not do
that?

> And it's not a software issue. As Karl pointed out, the
> software is going to be able to position the dots "perfectly"
> within any resolution supported by the interface [2].

If the OP wants to position the output with any accuracy relative to the
physical page then it is indeed a software issue (as well as a hardware
issue of course). It is totally pointless arranging for the software to
position the dots perfectly within the printable area if it is not the same
pixel size as the physical page (which it usually isn't), so the software
needs to also make sure that it offsets the dots within the printable area
by an amount exactly equal to the size of the current unprintable top and
left borders. Are you suggesting that the OP should not do that, or are you
saying that whatever he does he is wasting his time and that he should not
strive to get the best he can out of his current equipment?

As far as I am concerned I have tried to give the OP some help in performing
his required task, as have others. If you think he is wasting his time, and
perhaps that I and others are also wasting our time in trying to help him,
then that's your opinion and you are entitled to it. But personally,
especially until the OP comes back as requested with more details of exactly
what he is trying to do, then I (and I'm sure others) will give him whatever
help we can provide.

To the OP: You can either give the job up until you have purchased some new
equipment, as Bob seems to be suggesting, or you can stick at it and do as
well as you can with the hardware you have available. If you want to do the
latter then it would help if you told us whether you are after accurate
positioning of the printed elements relative to the physical page or whether
you are merely after accurate positioning of each element you are printing
on the page with respect to each other element you are printing on the same
page at the same time. In the former case you can get reasonable accuracy,
although not approaching the order of accuracy you have asked for, and in
the latter case you can get quite close to the accuracy you require, but
only if you make sure that your printer is not set to a setting that
restricts it relative positioning accuracy of the various elements on the
page, in which case you may not even get as good as 1.5 per cent even in the
latter case. Bob O' Bob will no doubt tell you all about that when he comes
back to moan about this latest response of mine, and he will tell you what
printer settings to avoid,

Mike