I use GRA_PU_LOMETRIC when defining a Printer Presentation Space.

:paperSize reports the following:

    width = 2159
    height = 2794
    left/bottom/right/top margins vary depending on the printer - 
essentially not useable data other than to determine where you can't print.

However, GraBox() and GraStringAt() do not position correctly on the page.

ie:  GraBox( oPrinterPS, { 2159/2, 2794/2 }, {(2159/2)+254,(2794/2)+254} )

results in the Printing being a box of approximately 265mm square 
located about 75 mm above center and about 60 mm right of center.  The 
location varies depending on the printer, but in all cases it seems to 
be oversized by about 4-5%.

This creates a lot of trouble when printing on Label Stock.  You simply 
can't position the print where it needs to be based on the actual label 
size.

Just a little update.

On Cannon Printers the vertical coordinates work 1:1
On HP Printers the vertical coordinates are approximately 1.0425 : 1

On both Canon and HP Printers the horizontal coordinates are 1:1 but the 
value of :paperSize()[3] must be subtracted to print at the correct 
location.  IOW if :aPaperSize()[3] = 50 then to print at X=185 you need 
top specify 135.  It's notable that the values of :PaperSize()[3] thru 
[6] vary quite a bit depending on the printer.

I haven't checked other makes yet, but the vertical problem would seem 
to be an HP driver error while the horizontal offset is most likely an 
error in the Xbase++ Gra.. functions.

-Joe

Joe Carrick wrote:
> I use GRA_PU_LOMETRIC when defining a Printer Presentation Space.
> 
> :paperSize reports the following:
> 
>    width = 2159
>    height = 2794
>    left/bottom/right/top margins vary depending on the printer - 
> essentially not useable data other than to determine where you can't print.
> 
> However, GraBox() and GraStringAt() do not position correctly on the page.
> 
> ie:  GraBox( oPrinterPS, { 2159/2, 2794/2 }, {(2159/2)+254,(2794/2)+254} )
> 
> results in the Printing being a box of approximately 265mm square 
> located about 75 mm above center and about 60 mm right of center.  The 
> location varies depending on the printer, but in all cases it seems to 
> be oversized by about 4-5%.
> 
> This creates a lot of trouble when printing on Label Stock.  You simply 
> can't position the print where it needs to be based on the actual label 
> size.
>

Hello Joe,

>On Cannon Printers the vertical coordinates work 1:1
>On HP Printers the vertical coordinates are approximately 1.0425 : 1
>
>On both Canon and HP Printers the horizontal coordinates are 1:1 but the 
>value of :paperSize()[3] must be subtracted to print at the correct 
>location.  IOW if :aPaperSize()[3] = 50 then to print at X=185 you need 
>top specify 135.  It's notable that the values of :PaperSize()[3] thru 
>[6] vary quite a bit depending on the printer.
>
>I haven't checked other makes yet, but the vertical problem would seem 
>to be an HP driver error while the horizontal offset is most likely an 
>error in the Xbase++ Gra.. functions.

My experience with the TD printer class over the years has not shown
any error in the Xpp Gra* functions in this regard.  I've had to deal
with this from the beginning because of using Row/Col coordinates.
Every printer has it's own unique margins and you have to use the
:papersize array to find where they are.  That's where the printer
starts counting from.  What this boils down to is we have pinpoint
accuracy relative to the margins, not relative to the paper.  This
can, of course, be a problem but there are ways to deal with it.

If you are, for example, writing code to fill out a preprinted form,
if you use coordinates based on arbitrary reduced margins, then
coordinate correction values can be determined from :papersize
regardless of which printer is used.  So in your example where X must
be 185 relative to the paper, the code, based on an arbitrary left
margin reduction of 100, could be something like this

  X := 85 + (100 - oP:papersize[3])

This is made much easier if there is a translation layer in between
(e.g. a wrapper function or method for GraStringAt).  That way in the
code you could just say X := 85 and send it to the wrapper which does
the rest.  It makes coding a lot easier.  This is the sort of thing I
do in the TD printer class for translating Row/Col coordinates.  No
Gra* functions are called from the report code, it's all printer class
methods.

It is possible for a driver to give an incorrect value to
:papersize.  I encountered some of that back in 1999-2002 with certain
models, but I haven't received any reports of that sort from TD users
in years.  It seems like the driver writers have all gotten their act
together in that area.

Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement

Hi Clayton,

I create my presentation Space with the full size of the Paper instead 
of the area within the margins.  This means I need to offset for the 
left and bottom margins when calculating a position.  I realize that's 
not quite normal for a printerPS, but it works OK as the lower left 
corner.  So from that standpoint, you're correct in the statement that 
this isn't an Xbase++ bug, it's just that I have to make those 
adjustments myself.

However, I still have a problem - vertical placement is not consistent 
between different printers.  Try printing horizontal lines at a 1" 
spacing like this:

for i := 1 to 10
    GraLine( oPS, { 0, (i-1)*254}, {2000, (i-1)*254} )
next i

Using a Canon ip1800 Printer or a Canon 3800 imagerunner, I get lines 
perfectly spaced 254 mm
Using a HP 6210 Multifunction Printer the spacing is about 265 mm

I'm trying to figure out why I get this inaccuracy on the HP.  I've 
attempted to determine what possible relationship between the papersize 
values results in the 1.0433 vertical enlargement factor.  BTW, this is 
consistent even if I use the Xbase++ norm for creating the presentation 
space.

-Joe
 



Clayton Jones wrote:
> Hello Joe,
>
>   
>> On Cannon Printers the vertical coordinates work 1:1
>> On HP Printers the vertical coordinates are approximately 1.0425 : 1
>>
>> On both Canon and HP Printers the horizontal coordinates are 1:1 but the 
>> value of :paperSize()[3] must be subtracted to print at the correct 
>> location.  IOW if :aPaperSize()[3] = 50 then to print at X=185 you need 
>> top specify 135.  It's notable that the values of :PaperSize()[3] thru 
>> [6] vary quite a bit depending on the printer.
>>
>> I haven't checked other makes yet, but the vertical problem would seem 
>> to be an HP driver error while the horizontal offset is most likely an 
>> error in the Xbase++ Gra.. functions.
>>     
>
> My experience with the TD printer class over the years has not shown
> any error in the Xpp Gra* functions in this regard.  I've had to deal
> with this from the beginning because of using Row/Col coordinates.
> Every printer has it's own unique margins and you have to use the
> :papersize array to find where they are.  That's where the printer
> starts counting from.  What this boils down to is we have pinpoint
> accuracy relative to the margins, not relative to the paper.  This
> can, of course, be a problem but there are ways to deal with it.
>
> If you are, for example, writing code to fill out a preprinted form,
> if you use coordinates based on arbitrary reduced margins, then
> coordinate correction values can be determined from :papersize
> regardless of which printer is used.  So in your example where X must
> be 185 relative to the paper, the code, based on an arbitrary left
> margin reduction of 100, could be something like this
>
>   X := 85 + (100 - oP:papersize[3])
>
> This is made much easier if there is a translation layer in between
> (e.g. a wrapper function or method for GraStringAt).  That way in the
> code you could just say X := 85 and send it to the wrapper which does
> the rest.  It makes coding a lot easier.  This is the sort of thing I
> do in the TD printer class for translating Row/Col coordinates.  No
> Gra* functions are called from the report code, it's all printer class
> methods.
>
> It is possible for a driver to give an incorrect value to
> :papersize.  I encountered some of that back in 1999-2002 with certain
> models, but I haven't received any reports of that sort from TD users
> in years.  It seems like the driver writers have all gotten their act
> together in that area.
>
> Regards,
> Clayton
>
> Clayton Jones   www.cjcom.net 
>  Top-Down Library for Xbase++
>  X-DBU Database Utility   
>  X-MEMO Memo Field Replacement
>

Hi again Clayton,

The more I think about this, the more sense it makes to set up the 
presentation space with aSize := {aPaperSize[1,],aPaperSize[2]}
This means that {0,0} should be at the bottom left corner of the paper 
and {asize} should be the upper right corner of the paper.

Naturally, you should not be able to print within the margins.  However, 
IMO the Gra.... functions should position relative to the lower left 
corner of the paper and not automatically attempt to position relative 
to the left and bottom margins.  In point of fact, my HP 6210 returns 
values for aPaperSize { 2159, 2794, 33, 148, 2125, 2776 } but only the 
1,2,3 & 5 are correct.  I can print successfully at {33,33} to {2125,2761}.

My program calculates the lower left corner of the lower left label 
position (assume 1" high x 4" wide labels with a horizontal separation 
of  40 mm as follows:

    nX := (aPaperSize[1]/2) - 20 - (4*254)  
    nY := (aPaperSize[2]-2540)/2

IOW:

   nX := 43.5
   nY := 127

These simply are absolute paper coordinates.  It's the simplest form of 
graphic positioning and is consistent with drawing on a standard window 
such as a microPS.

Because the Gra.... functions automatically add the left and bottom 
margins to the aPos coordinates all print is offset according to the 
values of aPaperSize[3] and aPaperSize[5], I have to subtract those 
values when I specify graphic positions.  Obviously there's a lot of 
existing code that relies on this strange behavior.  BTW, this only 
seems to be true when the device context returns left and bottom margins 
other than 0.  Apparently, they actually check the :papersize() 
internally and add the margin values because there's no way that it's in 
my code.

Apparently I will need to create translation routines to adjust 
coordinates.  That will be much easier than going thru all printing 
routines and adjusting in each Gra.... function call.

-Joe

The margins are there because the printer can not print at the edge of
the paper and there needs so be an offset from all edges. That offset is
for the most part manufacturer dependent, though all should be close for
a given size paper. If the print driver is reporting incorrect values
then it is its fault. Not the first time HP had screwed up drivers,

The spacing problem could be a bad conversion from internal metric
position to english positions. The stepping motor may only move in even
numbers of mm.

Jim

Joe Carrick wrote:
> Hi again Clayton,
> 
> The more I think about this, the more sense it makes to set up the
> presentation space with aSize := {aPaperSize[1,],aPaperSize[2]}
> This means that {0,0} should be at the bottom left corner of the paper
> and {asize} should be the upper right corner of the paper.
> 
> Naturally, you should not be able to print within the margins.  However,
> IMO the Gra.... functions should position relative to the lower left
> corner of the paper and not automatically attempt to position relative
> to the left and bottom margins.  In point of fact, my HP 6210 returns
> values for aPaperSize { 2159, 2794, 33, 148, 2125, 2776 } but only the
> 1,2,3 & 5 are correct.  I can print successfully at {33,33} to {2125,2761}.
> 
> My program calculates the lower left corner of the lower left label
> position (assume 1" high x 4" wide labels with a horizontal separation
> of  40 mm as follows:
> 
>    nX := (aPaperSize[1]/2) - 20 - (4*254)     nY := (aPaperSize[2]-2540)/2
> 
> IOW:
> 
>   nX := 43.5
>   nY := 127
> 
> These simply are absolute paper coordinates.  It's the simplest form of
> graphic positioning and is consistent with drawing on a standard window
> such as a microPS.
> 
> Because the Gra.... functions automatically add the left and bottom
> margins to the aPos coordinates all print is offset according to the
> values of aPaperSize[3] and aPaperSize[5], I have to subtract those
> values when I specify graphic positions.  Obviously there's a lot of
> existing code that relies on this strange behavior.  BTW, this only
> seems to be true when the device context returns left and bottom margins
> other than 0.  Apparently, they actually check the :papersize()
> internally and add the margin values because there's no way that it's in
> my code.
> 
> Apparently I will need to create translation routines to adjust
> coordinates.  That will be much easier than going thru all printing
> routines and adjusting in each Gra.... function call.
> 
> -Joe

Hi Jim,

You might be right about the stepping motors in the HP Printer(s).  But 
as for the margins, IMO the Gra.. functions should not automatically add 
to the coordinates in order to position printed output.

ie:

If you set up a presentation space that's exactly the same size as the 
paper - for 8-1/2" x 11" that's 2159 mm x 2794 mm - then the coordiantes 
of printed output should be relative to the bottom left corner of the 
paper.  It should be up the the programmer to check the margins and 
limit printed output to the printable area.

Currently, the Xbase++ Gra... functions add :paperSize()[3] to the x 
coordinate and :paperSize()[4] to the y coordinate.  It doesn't matter 
what size you specify for the presentation space - these values are 
always added - which is a mistake by Xbase++.

Let me give you a couple examples:

*************

   oDC := XbpPrinter():new()
   oDC:create()
   oPrinterPS := XbpPresSpace():new()
   aPaperSize := oDC:paperSize()
   aSize := {aPaperSize[1],aPaperSize[2]}    Actual Paper Size
   oPrinterPS:create( oDC, aSize, GRA_PU_LOMETRIC )

vs:

   oDC := XbpPrinter():new()
   oDC:create()
   oPrinterPS := XbpPresSpace():new()
   aPaperSize := oDC:paperSize()
   aSize := {aPaperSize[5],aPaperSize[6]}    Right & Top Margins
   oPrinterPS:create( oDC, aSize, GRA_PU_LOMETRIC )

vs:

   oDC := XbpPrinter():new()
   oDC:create()
   oPrinterPS := XbpPresSpace():new()
   aPaperSize := oDC:paperSize()
   aSize := {aPaperSize[5]-aPaperSize[3],aPaperSize[6]-aPaperSize[4]}   
 Printable Size
   oPrinterPS:create( oDC, aSize, GRA_PU_LOMETRIC )

It doesn't matter which of the above is used, the following will always 
result in a box being printed in the incorrect position on the page and 
also at exactly the same position. 

   GraBox( oPrinterPS, {200,200}, {400,400} )

In order for the positioning to be correct, the code has to be:

   GraBox( oPrinterPS, {200-aPaperSize[3],200-aPaperSize[4]}, {400,400} )

******************

This problem exists because no matter what size you specify for the 
presentation space, the origin doesn't actually change -it's always { 
0,0 } - but the Gra... functions internally look at the values of 
oPS:device():paperSize()[3] and oPS:device():paperSize()[4] and adjust 
the printed output accordingly. 

With Screen output this problem doesn't exist because these to values 
are always zero or nil.  But with Printed output it's always a crapshoot.

I for one don't want Xbase++ arbitrarily adjusting the coordinates.  
That just doesn't make sense!
I don't have a problem with putting code into my routines to check the 
margins and make sure that the coordinates I specify are sufficiently 
limited to make sure I'm not trying to print within the margins ( BTW, 
if you do it only results in the printed output being cropped ) but for 
Xbase++ to assume that the coordinates need to be increased is 
ridiculous and just makes it almost impossible to properly calculate the 
correct coordinate values to get the proper output on the page.

-Joe

James Loughner wrote:
> The margins are there because the printer can not print at the edge of
> the paper and there needs so be an offset from all edges. That offset is
> for the most part manufacturer dependent, though all should be close for
> a given size paper. If the print driver is reporting incorrect values
> then it is its fault. Not the first time HP had screwed up drivers,
>
> The spacing problem could be a bad conversion from internal metric
> position to english positions. The stepping motor may only move in even
> numbers of mm.
>
> Jim
>
> Joe Carrick wrote:
>   
>> Hi again Clayton,
>>
>> The more I think about this, the more sense it makes to set up the
>> presentation space with aSize := {aPaperSize[1,],aPaperSize[2]}
>> This means that {0,0} should be at the bottom left corner of the paper
>> and {asize} should be the upper right corner of the paper.
>>
>> Naturally, you should not be able to print within the margins.  However,
>> IMO the Gra.... functions should position relative to the lower left
>> corner of the paper and not automatically attempt to position relative
>> to the left and bottom margins.  In point of fact, my HP 6210 returns
>> values for aPaperSize { 2159, 2794, 33, 148, 2125, 2776 } but only the
>> 1,2,3 & 5 are correct.  I can print successfully at {33,33} to {2125,2761}.
>>
>> My program calculates the lower left corner of the lower left label
>> position (assume 1" high x 4" wide labels with a horizontal separation
>> of  40 mm as follows:
>>
>>    nX := (aPaperSize[1]/2) - 20 - (4*254)     nY := (aPaperSize[2]-2540)/2
>>
>> IOW:
>>
>>   nX := 43.5
>>   nY := 127
>>
>> These simply are absolute paper coordinates.  It's the simplest form of
>> graphic positioning and is consistent with drawing on a standard window
>> such as a microPS.
>>
>> Because the Gra.... functions automatically add the left and bottom
>> margins to the aPos coordinates all print is offset according to the
>> values of aPaperSize[3] and aPaperSize[5], I have to subtract those
>> values when I specify graphic positions.  Obviously there's a lot of
>> existing code that relies on this strange behavior.  BTW, this only
>> seems to be true when the device context returns left and bottom margins
>> other than 0.  Apparently, they actually check the :papersize()
>> internally and add the margin values because there's no way that it's in
>> my code.
>>
>> Apparently I will need to create translation routines to adjust
>> coordinates.  That will be much easier than going thru all printing
>> routines and adjusting in each Gra.... function call.
>>
>> -Joe
>>

Hello Joe,

>Currently, the Xbase++ Gra... functions add :paperSize()[3] to the x 
>coordinate and :paperSize()[4] to the y coordinate.  It doesn't matter 
>what size you specify for the presentation space - these values are 
>always added - which is a mistake by Xbase++.

Are you sure about this?  I have not experienced this in my code.  I
just went back and checked a TD printer class method and it's
calculations are based on the oPS point of origin (with oPS set to the
margins).  IOW, an X value of 1 will print just inside the left
margin.  


>but the Gra... functions internally look at the values of 
>oPS:device():paperSize()[3] and oPS:device():paperSize()[4] and adjust 
>the printed output accordingly. 

I've never seen any evidence of this.  How would Gra* know it's oPS is
associated with a printer object?  I can't help but think that there's
something else going on here that's making it look that way.


Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement

After a lot of testing with different printers I find that the results of:

    oDC:paperSize() --> aPaperSize

are allways correct ( at least for the printers I tested )  for the 
first 3 values.  IOW,

    aPaperSize[1] --> width of paper
    aPaperSize[2] --> height of paper
    aPaperSize[3] --> left margin

If aPaperSize[4] > 2*aPaperSize[3] then all of the remaining values are 
suspect and it's best to assume that the bottom, right and top margins 
are about the same size as the left margin.

That said, there's no way to be sure what the exact values should be.  
The fact is that not all printer drivers return correct values.  Maybe 
Alaska should do some testing and verify that :paperSize is getting the 
right information.

I'm going to compile a list of printers that I can verify printable 
area's for and post the results.  I have only Canon, HP and a few other 
printers.  If anyone else has printers they can test it would be helpful.

A good way to test is:

    GraLine( oPS, { -200,400 }, {2500,400 } )
    GraLine( oPS, ( 400,-200 }, { 400,3000 } )

This should draw 2 lines that will only be visible within the actual 
printable area of an 8.5" x 11" sheet of paper.  You can then measure 
the limits and compare them against the values of oPS:device():paperSize()

-Joe

Hello Joe,

>The more I think about this, the more sense it makes to set up the 
>presentation space with aSize := {aPaperSize[1,],aPaperSize[2]}
>This means that {0,0} should be at the bottom left corner of the paper 
>and {asize} should be the upper right corner of the paper.

It doesn't really matter.  Either way you do it, you are going to have
to use the margin values to calculate where to place the text.  If you
set oPS to papersize then you have to consider the margin in your
calculations.  If you set oPS to the margins, then you've
automatically included them and calculations are simpler.  It's just
two different ways of arriving at the same answer.

As for the values the driver gives us, as I mentioned before they have
been known to be incorrect but seem to be much better these days.


>However, IMO the Gra.... functions should position relative to the lower left 
>corner of the paper and not automatically attempt to position relative 
>to the left and bottom margins. 

Are you sure that's what they're doing?  Isn't their point of origin
relative to the oPS?  The Gra* funcs don't even know they're dealing
with a printer.  We just give it an oPS and coordinates.   



>Apparently I will need to create translation routines to adjust 
>coordinates.  That will be much easier than going thru all printing 
>routines and adjusting in each Gra.... function call.

That was my last point.  However you want to structure the
calculations, the day-to-day report coding is easier with wrapper
routines to do the grunt work.  For example, if you wanted to use
either row/col or upper-left x/y values to make it easier to
conceptualize text placement going down the page, wrapper funcs for
GraStringAt can do this easily (if you're using lower-left values then
there's probably no advantage if oPS is set to margins).  For example
the Top-Down printer class uses row/col coordinates and has output
methods to do the calculations
   oP:PrLn(nRow,nCol,cText)
Having a method or function allows simple preprocessing so we can do
things like this
   @ nRow,nCol SAY cText
(great for converting existing Clipper reports).


The power of OOP!  


Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement

Hi Clayton,

I am sure.  I've been in touch with Andreas at Alaska and have 
confirmation that the Gra.... functions were designed to offset to the 
margins.  IOW, the printed output will be relative to the lowere left 
corner of the "visible" area of the printer.  This means that {0,0} is 
equivalent to { oDC:paperSize()[3], oDC:paperSize()[4] }.

For my purposes, I am only interested in printing relative to the actual 
lower left corner of the actual paper.  The reason for this is that each 
printer has different margins and relying on the "visible area" as 
Xbase++ currently does means that the print is located differently on 
different printers.

Please see my post "Exact Printer Positioning" in the "p.x.generic" NG.

If you're just printing text and you want to use the default printer 
margins it doesn't matter.  However, if you need to be precise - like 
printing consistently on pre-cut label stock - then you need to be able 
to basically ignore the margins and specify coordinates relative to the 
edges of the paper.

-Joe

Clayton Jones wrote:
> Hello Joe,
> 
>> The more I think about this, the more sense it makes to set up the 
>> presentation space with aSize := {aPaperSize[1,],aPaperSize[2]}
>> This means that {0,0} should be at the bottom left corner of the paper 
>> and {asize} should be the upper right corner of the paper.
> 
> It doesn't really matter.  Either way you do it, you are going to have
> to use the margin values to calculate where to place the text.  If you
> set oPS to papersize then you have to consider the margin in your
> calculations.  If you set oPS to the margins, then you've
> automatically included them and calculations are simpler.  It's just
> two different ways of arriving at the same answer.
> 
> As for the values the driver gives us, as I mentioned before they have
> been known to be incorrect but seem to be much better these days.
> 
> 
>> However, IMO the Gra.... functions should position relative to the lower left 
>> corner of the paper and not automatically attempt to position relative 
>> to the left and bottom margins. 
> 
> Are you sure that's what they're doing?  Isn't their point of origin
> relative to the oPS?  The Gra* funcs don't even know they're dealing
> with a printer.  We just give it an oPS and coordinates.   
> 
> 
> 
>> Apparently I will need to create translation routines to adjust 
>> coordinates.  That will be much easier than going thru all printing 
>> routines and adjusting in each Gra.... function call.
> 
> That was my last point.  However you want to structure the
> calculations, the day-to-day report coding is easier with wrapper
> routines to do the grunt work.  For example, if you wanted to use
> either row/col or upper-left x/y values to make it easier to
> conceptualize text placement going down the page, wrapper funcs for
> GraStringAt can do this easily (if you're using lower-left values then
> there's probably no advantage if oPS is set to margins).  For example
> the Top-Down printer class uses row/col coordinates and has output
> methods to do the calculations
>    oP:PrLn(nRow,nCol,cText)
> Having a method or function allows simple preprocessing so we can do
> things like this
>    @ nRow,nCol SAY cText
> (great for converting existing Clipper reports).
> 
> 
> The power of OOP!  
> 
> 
> Regards,
> Clayton
> 
> Clayton Jones   www.cjcom.net 
>  Top-Down Library for Xbase++
>  X-DBU Database Utility   
>  X-MEMO Memo Field Replacement
>

Clayton Jones wrote:
> 
> It doesn't really matter.  Either way you do it, you are going to have
> to use the margin values to calculate where to place the text.  If you
> set oPS to papersize then you have to consider the margin in your
> calculations.  If you set oPS to the margins, then you've
> automatically included them and calculations are simpler.  It's just
> two different ways of arriving at the same answer.
>


Actually the positioning is the same regardless of the oPS size.  This 
is because setting the size doesn't adjust relative to the device.  In 
fact, you will find that subsequent calls to oDC:paperSize() will give 
the same results as previous calls.  Creating a presentation space and 
connecting it to a device has no effect on the device parameters.

> 
>> However, IMO the Gra.... functions should position relative to the lower left 
>> corner of the paper and not automatically attempt to position relative 
>> to the left and bottom margins. 
> 
> Are you sure that's what they're doing?  Isn't their point of origin
> relative to the oPS?  The Gra* funcs don't even know they're dealing
> with a printer.  We just give it an oPS and coordinates.   
>

That's my point - the oPS is just a window but with the caveat that 
printer output is adjusted by the Gra... functions by the values of the 
printer margins.  In fact, Xbase++ does the same for TabPages because 
they also have margins.

Another Test which gives a clue is to print to PDF995 which has values 
of 0 for the margins.

-Joe

I previously reported some anomalies with the results of the XbpPrinter 
class :paperSize() method.

Ive now tested the following Printers and in all cases the results were 
correct:

Canon ip1800
Canon imagerunner 3380 - Shared printer on a Win2K domain
HP Officejet 7100 series
HP Deskjet 5500 series
HP Deskjet 3820 series
HP Deskjet 895Cse
Samsung ML-2010 series
PDF995

However on the following the results were incorrect:

HP OfficeJet 6210 - Shared printer on a Windows workgroup.
	In this case the printer is connected to a WinXP SP2 computer
	It is shared and the test was run from a WinVista Ultimate SP1
	 laptop system.
	The actual margins on this printer are 33 mm on each side and
          at the bottom and top of the page.
	 :paperSize() reports:
	    width	= 2159	- correct
	    height	= 2794	- correct
	    left	= 33	- correct
	    bottom	= 148	- should be 33
	    right	= 2125	- correct
	    top		= 2776	- correct
	In addition, on this printer the vertical print spacing is
	 increased in size by a factor of 1.0433

Conclusion:
	The communication with this printer driver over a workgroup
	network is giving inaccurate results.  I still need to test this
	printer directly connected to see if it works correctly in that
	case.

None of the above changes my opinion that the Gra... functions should 
not add left and bottom margins to position printed output.

It's notable that the PDF995 printer driver returns:

	width	= 2159	- correct
	height	= 2794	- correct
	left	= 0	- correct
	bottom	= 0	- correct
	right	= 2159	- correct
	top	= 2794	- correct

Screen presentation spaces also return 0 margins.

-Joe

Hello Joe,

>Ive now tested the following Printers and in all cases the results were 
>correct:
>
>Canon ip1800
>Canon imagerunner 3380 - Shared printer on a Win2K domain
>HP Officejet 7100 series
>HP Deskjet 5500 series
>HP Deskjet 3820 series
>HP Deskjet 895Cse
>Samsung ML-2010 series
>PDF995



>However on the following the results were incorrect:
>HP OfficeJet 6210 - 

Yep.  Good ol' HP.  We saw a lot of this back in 1999-2002.  One thing
to try which often worked is to download and try various driver
versions for the printer.  Quite often a correct one can be found.


Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement