Vexed by a Printer

[Eric Pearson Member Find all posts View Profile Close Eric Pearson]

I've got a Graphics Tools licensee with a printing problem, and I'm stumped.

The function -- the heart of the GT print-image and print-area functions -- has been working fine in wide distribution since 2002 when the last print-related bug was reported and fixed. Now a user is reporting that his programs can't print on his Kodak 5100 All-in-One. The print job gets stuck in the queue and no paper comes out. I thought it was probably something peculiar with his hardware, OS, or network, but Jules, who also owns a Kodak 5100, was kind enough to run a test program for me. It fails to print on his computer too.

My usual strategy was to install a problem-printer's drivers on a test system, and set it up for "print to file". That way I can talk to the driver without the actual printer being installed. Unfortunately the Kodak All-in-One driver-install program refuses to install anything until it actually detects the printer.

So I sent the customer another test program, which created a text "trace" file. The file shows that the return value of every API function is exactly what it is supposed to be. Every handle/etc value is valid, and GetLastError always returns zero immediately after an API call. Every single line of code is doing exactly what I am asking it to do, but the image is not making it onto paper.

By the way the test program sends text to the printer with TextOut, as well as copying an image to the printer DC. Even if the printer caps were being handled incorrectly, or something like that, it seems like we'd at least get a piece of paper with one line of text. But no, the job just hangs in the queue.

(This may or may not be important: The first problem I ran into was that the runtime system would not let me create a trace file in the root of C. Permission denied. I was able to create it in a folder called C:\tmp2 but not
C:\tmp. Is there something new in Vista that disallows root access? Again, I don't know whether or not this is related to the printer problem, but it makes me wonder whether the printing code is working correctly with Vista, rather than the Kodak printer.)

Does this ring a bell with anybody?

-- Eric Pearson, Perfect Sync, Inc.

[Fred Buffington Member Find all posts View Profile Close Fred Buffington]

Eric, I don't know if this will help but I used dllprint for several years with
my applications that I sell. I rewrote the print routines using graphic and
xprint because a user was unable to print because he had an all-in-one printer
and the output kept going to the fax instead of the printer.

Dllprint uses the port whereas, of course, with xprint i can use the description
instead.

[Marc Giao Member Find all posts View Profile Close Marc Giao]

Does this ring a bell with anybody?

Yep, does ring a bell. My wife has a Kodak (the OS is Vista) and it does the same thing, sometimes, when printing from Corel Draw or Corel Photo Paint, it just hangs with the job in the queue.

The only way I can get the thing to work is to clear the queue, exit Corel, turn the printer off and back on and try again... most times it'll work.

Neither Corel nor Kodak have been of any use so far but I'll keep working on them

[Chris Boss Member Find all posts View Profile Close Chris Boss]

First thing I would do is send the customer a test app which calls:

GetDeviceCaps

for the printer DC, to see what it returns for all the possible flags.

It may offer some clues as to what GDI API's the printer supports.
Even if a GDI API is not supported by the printer, it may not properly return an error value. GetDeviceCaps should be able to tell you want is and is not supported by the printer.

[Chris Boss Member Find all posts View Profile Close Chris Boss]

Eric,

Does Graphic Tools call the:

OpenPrinter

API function ?

If so, does your code test to see if the operating system is NT based ?

The CreateDC function (called after OpenPrinter) works differently on NT based systems than it does on 95/98/ME.

Also when calling GetVersionEx to test for the platform number, if you test with a comparison for .dwPlatformID with an equal sign, rather than greater than, Vista may not be tested correctly.

ie.

IF GetVersionEx(OSV) THEN
    ' use:
    IF OSV.dwPlatformId>=%VER_PLATFORM_WIN32_NT THEN
 
    END IF
    ' don't use:
    IF OSV.dwPlatformId=%VER_PLATFORM_WIN32_NT THEN
 
    END IF
END IF

[Eric Pearson Member Find all posts View Profile Close Eric Pearson]

Thanks to all who responded!

Even if a GDI API is not supported by the printer, it may not properly return an error value.

I didn't know that, Chris. It can happen with the ODBC API so I guess I should have guessed it might happen with GDI. Man, that's scary. I am sending a new test DLL to the licensee, to get all of the valid DeviceCaps values.

-- Eric

[Chris Boss Member Find all posts View Profile Close Chris Boss]

Eric,

I can't say for sure that the GDI APIs may not return an error value, if a function is not supported, since they should.

The problem though is that the GDI passes calls to the printer driver and there is no way of knowing whether the printer drivers are written very well. I would assume that if a printer driver does not support a specific feature, it should return an error value, but the developer of the driver may simply just ignore the call and not return an error value.

GetDeviceCaps is Windows way of testing whether a driver supports a feature and not return values of the GDI calls. It only makes sense to find out what GetDeviceCaps returns for each flag (which effects the GDI calls you plan to make) before making the GDI calls to a printer driver.

[Shawn Anderson Member Find all posts View Profile Close Shawn Anderson]

my brother had a Kodak laser printer (not a 5100) that did that.
I could get it to empty the queue and print by just sending a form feed chr$(12) to the printer.

[Eric Pearson Member Find all posts View Profile Close Eric Pearson]

Shawn, thanks for the suggestion. I have asked the customer to use SLEEP 2000: LPRINT FORMFEED after my function returns, as an experiment. Cross your fingers for me.

Chris, I have looked at all of the GetDeviceCaps values from the new trace file and I don't see anything that should cause a problem. My routine was already asking GetDeviceCaps for RASTERCAPS to see which image-blt API to use; LOGPIXELSX and Y; and PHYSICALOFFSETX and Y. I don't see anything else that seems pertinent.

It's a DT_RASPRINTER as expected, the pixel values are all reasonable... I must be missing something.

-- Eric

[Chris Boss Member Find all posts View Profile Close Chris Boss]

Eric,

I assume you are printing some kind of Bitmap image to the printer.

Are you using the StretchDIBits API function to do this ?

[Eric Pearson Member Find all posts View Profile Close Eric Pearson]

If DeviceCaps says that the driver supports RC_STRETCHDIB, then Yes. If not, then I have RC_STRETCHBLT and RC_BITBLT as fallbacks.

DeviceCaps says RASTERCAPS is x6E99 so the routine is deciding to use StretchDIB (x0800).

In any event, I am sending a string to TextOut so even if the image-copy failed, it wouldn't be an empty page. Right?

I hate hardware.

-- Eric

[Eric Pearson Member Find all posts View Profile Close Eric Pearson]

I'm back.

I hate to say it, but I am still stumped by this printer problem, and the customer is quite understandably getting impatient. I have put together a small test program, and I'd like to run it with as many different printer makes/models as possible.

If you can help me out, please download this file and unzip it into a temporary folder. Run the EXE, click Print, and report here 1) make/model of printer(s) tested, 2) the operating system, and 3) whether or not a page was printed.

Genuine thanks in advance!

-- Eric

[Marco Pontello Member Find all posts View Profile Close Marco Pontello]

1) Canon Pixma MP750
2) XP Pro SP2
3) Printed OK with no issue

Bye!

[Tom Cone Jr Member Find all posts View Profile Close Tom Cone Jr]

1) HP OfficeJet J5780 All-in-one
2) XP Pro SP2
3) Nothing printed. The printer made a brief sound, as though it was beginning to position the inkjet cartridges, but then nothing else happens. The document is not in the printer's queue when I check the status of the printer object in Windows.

Later...
Disregard the previous for time being. I've returned to the office where I have the same type printer and the file prints just fine there. Perhaps I've fouled up the test at home somehow. Will check again this evening and let you know. In the meantime, from the office I can report:

1) HP LaserJet 4Plus
2) XP PRO SP 2
3) prints fine (black and white)

1) HP OfficeJet J5780 All-in-one
2) XP Pro SP 2
3) prints fine (color) - - though I notice that when I remove the printed sheet it had not been fully ejected

Still later...
The OfficeJet at home still won't print. On inspection it seems the two machines are using different drivers. Not sure if this will help but the machine at the office is using:
Unidrv Printer Driver (Microsoft) version 5.2.3790.109 and
HP GPD version 062.34100

at home, on the machine that won't print your graphic:
Unidrv Printer Driver (Microsoft) version 6.0.6000.16438 and
HP GPD version 063.24700

Yes. The machine at home has newer drivers and it's the one that won't print your graphic image.

-- tom

[Michael Mattias Member Find all posts View Profile Close Michael Mattias]

Deja Vu all over again....

1) HP DeskJet D4260
2) XP Pro SP2
3) Nothing printed. The printer made a brief sound, as though it was beginning to position the inkjet cartridges, but then nothing else happens. The document is not in the printer's queue when I check the status of the printer object in Windows.

MCM

[Paul Squires Member Find all posts View Profile Close Paul Squires]

(1) Lexmark Optra E312 (local); and Lexmark T644 (network)
(2) Windows XP SP2
(3) Worked perfectly. Granted, these are black & white printers rather than color (if that makes any difference).

[Shawn Anderson Member Find all posts View Profile Close Shawn Anderson]

all from xp pro sp2
I don't have a printer physically connected to my computer, these are all over a network.

hp laserjet6l
printed OK

hp deskjet 720c
printed OK

konica-minolta 2300dl
printed OK

[Paul D. Elliott Member Find all posts View Profile Close Paul D. Elliott]

1) Epson Color 740 inkjet and HP Laserjet 1018
2) Windows 2000
3) no problems ( Epson in color and HP in bw )

[Marc Giao Member Find all posts View Profile Close Marc Giao]

Hi Eric,

My effort...

1 - HP LaserJet 2300L PLC 5
2 - Vista
3 - No problems

1 - Kodak 5500 AiO (inkjet)
2 - Vista
3 - Will not print (5 tries)

This is what the Kodak does:
-Loads the paper and readies the print head
-Display reads "Printing"
-Then the print head makes a noise, continuously, that sounds like the print head is about to move but then aborts

This is what happens on the software side:
-The print manager says the file was sent, but, the line continues to show on the print manager
-The Kodak software says it's "Spooling" and stays at 0%

When I cancel the job on the PC both the Kodak software and the print manager seem to do the job.
However the printer continues to say printing... until I cancel the job on the printer.

I've done this 5 times, reset the printer and the PC.

Hope this is of some help

[Elias Montoya Member Find all posts View Profile Close Elias Montoya]

• HP LaserJet 6L
• Windows XP SP2
• Prints OK

I think the problem is with the printer and not with the software...