1 of 1 people found this helpful
Hmmm that IS an interesting one, David. Whilst I've not seen it before, personally, I can think of a few things you could possibly try doing to try and narrow down the cause of the issue?
Are you in a position to print from the lab machines directly to the colour printer? Doing this would use a different print queue and, presumably, a different driver (unless you're using a Universal driver, as we do)... if these prints work and are charged appropriately, then you can point your finger at either the driver, or the configuration of the B&W queue. At least that narrows down the scope of your investigation considerably. If it doesn't work properly... well, at least you've tried sometihng else
Have you tried creating a new queue for the same printer, to see if that also has the overcharge issue?
Actually - what kind of charging method are you using? Are you using Attribute charging, by any chance?? Could it be that you have a "per job" charge, as well as a per page charge configured?
The print jobs from our lab to the color queue are correctly charged, and we're using the same universal print driver on both queues. I've been all over the settings on both queue repeatedly and can't find a difference (other than settings relating to color). I even tried changing the charging method on the B&W queue to the same one used by the color queue and it still charges for a phantom page.
But I had not tried creating a new B&W queue. I've done that, and print jobs to the new queue are charged at the proper rate. No more extra charge for a phantom page. I still can't find a difference between the new queue and the old one, but this solution works for me. Thanks for your help!
Excellent! Glad you got it up and running
I'm glad you fixed your problem. I had something similar happen when I was running version 7.1 (I guess that was awhile ago now). I don't know if this applies, but if someone else is having trouble maybe this could help. Pharos told me to make these registry changes on the print server:
MyComputer\HKEY_LOCAL_MACHINE\SOFTWARE\Pharos\Page Counter\No Blank Pages = 1
MyComputer\HKEY_LOCAL_MACHINE\SOFTWARE\Pharos\Print Server\One Duplex Page Mod = 1
Like Edmund, I want to add some more detail in case it helps anyone else out there. Creating a new print queue as a described above stopped the overcharging when printing from our lab, but I subsequently found that some people were being overcharged when using the popup print client (though I was never able to directly replicate this myself). Looking in Pharos Administrator at System->Transactions, and then expanding the "general" node for a given job, I could see some jobs that looked like this:
1 page(s) of "612x792,Letter,Mono,Duplex,Collate"; 1 page(s) of "612x792,Letter,Blank,Duplex,Collate"
Jobs like the one above had an additional blank page at the end that was being charged for, but apparently not printing out. I had what I thought was the latest version of pcounter.exe for my version of Pharos, but our reseller sent me a link for a newer version. Updating pcounter.exe to version 8.4.8013.0 appears to have resolved the problem. I haven't seen a single charge for a blank page since updating that file.
Also, I got some info on regkeys as well, so I'll post them here, but I personally didn't have to use these, so I can't speak to their efficacy:
The following reg keys can be applied on a per print server basis to modify how pages are handled. The zero in the far column is the default behavior which indicates false. Creating the key(s) – or modifying the key(s) – to a 1 will enable that feature. No change control is necessary.
(x86) = HKEY_LOCAL_MACHINE\SOFTWARE\Pharos\Page Counter
(x64) = HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Pharos\Page Counter
Last Page Simplex
This setting has to be manually added to the registry to determine how to charge the last page of odd number pages in duplex job.
If this value is set to 0 or does not exist, the behavior depends on the version of Uniprint installed. For versions earlier than 8.2 , last page odd number pages will be treated as duplex. Beginning with 8.2, they will be treated as simplex.
If this value is set to 1, last page odd number pages will be treated as simplex.
If this value is set to 2, last page odd number pages will be treated as duplex.
No Blank Pages
If this value is set to 1, the page counter will not include blank pages in the page count for a document. If this value is set to 2, the page counter ignores blank pages at the end of the document.