Printing accuracy

[Conrad Hoffman]

When I print from my CAD program, the results are typically within a few thousandths of an inch for both axis. From this I assume my printer and Windows driver are good. I just wrote something where I need similar accuracy, but found an error of about 0.15" over 8". Try the following and check the aspect ratio of the circles. I've got to be doing something wrong with the printer scaling but it's eluding me. Any ideas?

Thanks,
CH

'Printer accuracy check

#COMPILER PBWIN 9
#COMPILE EXE
#MESSAGES COMMAND
#OPTIMIZE SPEED
#REGISTER DEFAULT
#DEBUG ERROR ON
#DEBUG DISPLAY ON
#DIM ALL

FUNCTION PBMAIN () AS LONG
    LOCAL hBmp AS DWORD
    LOCAL NativeResX, NativeResY AS LONG
    LOCAL NativeSizeX, NativeSizeY AS SINGLE
    LOCAL nLeft, nTop, nRight, nBottom AS SINGLE
    LOCAL NativeX, NativeY AS SINGLE
    LOCAL dpiRatioX, dpiRatioY AS SINGLE
    LOCAL dpi AS SINGLE
    dpi = 300
    
    GRAPHIC BITMAP NEW 3000, 3000 TO hBmp                            '10x10" based on 300dpi
    IF hBmp = 0 THEN                                                 'check that bitmap is created
        ? "Sorry, insufficient video memory."
        EXIT FUNCTION
    END IF

    GRAPHIC ATTACH hBmp, 0
    GRAPHIC SCALE (-1500, 1500)-(1500, -1500)                        'move zero to center
    GRAPHIC COLOR %BLACK, %WHITE
    GRAPHIC PAINT (0,0), %WHITE
 
    GRAPHIC ELLIPSE (-1200, 1200)-(1200, -1200)                      'draw a 8" diameter circle based on 300dpi
    
    XPRINT ATTACH CHOOSE
    IF ERR = 0 AND LEN(XPRINT$) > 0 THEN
        XPRINT SET ORIENTATION 2                                     'put printer in landscape mode
        XPRINT GET PPI TO NativeResX, NativeResY                     'get pixels per inch
        XPRINT GET SIZE TO NativeSizeX, NativeSizeY                  'get full page size
        XPRINT GET MARGIN TO nLeft, nTop, nRight, nBottom            'get margins
        NativeX = NativeSizeX - nLeft - nRight                       'calculate printable width
        NativeY = NativeSizeY - nTop - nBottom                       'calculate printable height
        dpiRatioX = NativeResX/dpi                                   'calculate dpi multipliers for different printers
        dpiRatioY = NativeResY/dpi
        XPRINT SCALE (-NativeX/2/dpiRatioX, NativeY/2/dpiRatioY)- _  'set new coordinate system
                     (NativeX/2/dpiRatioX, -NativeY/2/dpiRatioY)     'with scaling for size correction

        XPRINT STRETCH hBmp, 0, (-1500, 1500)-(1500, -1500) TO _
                                  (-1500, 1500)-(1500, -1500)
        XPRINT ELLIPSE (-1175, 1175)-(1175, -1175), %BLACK           'see if this one has the same aspect ratio
       
   END IF
   XPRINT CLOSE

END FUNCTION

[Walt Thompson]

Hi Conrad;

On my printer the spacing between the 2 circles is 2.5 mm for the circumferance of the circles.

[Conrad Hoffman]

Yes, but measure the height and width of the outside circle. It should be exactly 8 inches both ways. I did the second circle just to see if the problem was in the ellipse command or the transfer of the bitmap, but I'm sure it's the scaling I use, probably something with the margin calculation. I need to look at that scaling again!

CH

[keith shelton]

On my brother hl-1440 the outer circle has a height of 8 inchs and a width of 8 3/16 inches. The distance between circles is 2 cm.
KS

[Conrad Hoffman]

That's exactly what I get, so it's my programming, not the printer!

Thanks,
CH

[Paul Dixon]

Conrad,
I get circles to within 0.01" of 8" on a HP CP2025 but my Laserjet 4MP give circles about 1/32" to small.

Paul.

[Conrad Hoffman]

I can live with a slight size discrepancy, but not aspect ratio. I have an old HP 5P and a Canon i9900, and both show an aspect problem. Does what I'm doing with the scaling on XPRINT SCALE make sense to get equal dimensions for x and y?

[Simon Morgan]

I don't think you should be using the widths of the margins in your scaling calculations. In my experience, the values returned by XPRINT GET MARGIN (or retrieved directly from the printer structure) are approximate anyway.

[Conrad Hoffman]

Simon, I think you've hit on it. If I send data to the printer using its native coordinate system, the sizes come out near to perfect. The problem is when I try to rescale the printer. Even when I get the client area directly, my scaling is still off. It's a pain, but it seems I have to scale my data based on the dpi retrieved, and get it positioned without any shift or rescale of the printer client area. I'm a bit surprised that the client area would be less than perfect, but also doubt there's any problem with the PB retrieval of the numbers.

[Dennis Pearson]

Yep, printer hardware and software can have errors too. Darn human programmers...

I always allow the user to manually adjust margins in case the driver/printer reports the margins incorrectly, or feeds the paper a bit sloppy. I can certainly see where scaling something based on any information provided by the printer or the driver would cause a problem.

[Walt Thompson]

Hi Conrad;

When I reported my results yesterday, I should have mentioned that the circles were < .5mm out of round. This leads me to wonder if your printer uses square pixels or rectangular pixels.

Older computer monitors used rectangular pixels. This necessitated distorting a circle in order to get the monitor display it as a circle.

[Conrad Hoffman]

I've been reading my printer docs, and the ppi is 600 both ways, and is reported thus by PBWin. It turns out dots themselves aren't tied directly to the ppi, thus they don't use the term dpi. As long as I do all my scaling to my data, and don't rely on things like XPRINT STRETCH, the results are fine, but that's very inconvenient. I'm investigating this further to see if there's some strategy that overcomes the problem, or even if there's some issue with the client area retrieved from the printer driver, as I find it very hard to accept that this could be off by 2%.

[Dennis Pearson]

YES, there are drivers that report the printer capabilities incorrectly.

[Conrad Hoffman]

Naw, can't accept it that easily. My CAD program does all sorts of windowing, sliding & scaling, and it's dead accurate using the same printer and driver I'm using for my app. I'm trying to find out if they rely on any info from the printer driver other than dpi, or if the only assumption they make is the dpi. IMO, dpi can't be wrong.

What I don't understand how to do is calculate coordinates for XPRINT STRETCH that are accurate, without accurate knowledge of the client area.

[Conrad Hoffman]

Well, FWIW I have my app humming away nicely. The secret seems to be not to use XPRINT SCALE because one has no way of knowing exactly what numbers to use. STRETCH can be done ratiometrically, so it isn't the cause of the problem. Once I moved all my scaling into my initial point calculations, I got full accuracy from the printer. I still have a place for the user to make minor tweaks to the scaling, but in general it's only necessary if the paper does funny things going through the fuser, or maybe when the ink dries on an inkjet.