Beverly Howard wrote:
The PCL factor tends to point directly to the printer drivers...

PCL code should exist only in the printer output stream and is only put
into the printer output by the printer driver itself, not the app doing
the printing.
PCL may only be a coincidence, since I don't have any other printers.

The problem with blaming the printer driver is that it only ever happens in Seamonkey 2.0.x. Every other app prints just fine and it never happened in Seamonkey 1.x. I always thought if something starts not working you looked at what changed.

Not sure about all of the printers you list, but think several of them
are fairly old, and at least one, the 2100, the latest direct drivers
are from 2004, so, I would consider them suspect. You might consider
trying the "universal Print Driver" for PCL6 from the page at

http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=14914&prodTypeId=18972&prodSeriesId=25469&swLang=8&taskId=135&swEnvOID=228


Being old doesn't mean they shouldn't work, they seem to work fine for everything else. But I have installed the Universal Printer driver for the 2100 and it seems to work much better, although it is a lot bigger and slower.

All of the drivers have been updated to the latest release since I installed Seamonkey 2.0.x, but the old ones worked fine in Seamonkey 1.x. Something changed for the worse in Seamonkey 2.0.x

On the other hand the 8500 is less than three months old and a current HP model.

If there is PCL code in the output sent by the app to the _printer
driver_ there is a mistake somewhere along the line. I can't conceive of
any app itself generating PCL in the printer output unless that app is
running custom code designed to send to and in order to manually control
a pcl printer.

In the case that an app needs to do this, the output should not go
through a printer driver, but be sent raw directly to the printer,
normally sent directly to the port that the printer is connected to.

A related issue (apparently not yours) recently, tcpip "network
printers" connected directly to a network connection have become more
common and, since the only way to get to a network printer is via a
printer driver, this may create similar problems.

Actually most of these printers are network printers. However that would not explain garbled Print Preview display. The Officejet 5600 is the only printer directly connected to a computer and it seem to have the worst problem. Sometimes an email will print on one printer and not another. I beleive that Seamonkey is not sending consistent output to the printers.

In the case of mozilla, I would expect that the only time this might
happen would be if a pcl _printer output file_ is opened by mozilla that
already contains PCL code and then "printed" rather than downloaded and
redirected to the printer.

My take is that Mozilla is not properly selecting the code to send to the printer driver. Many of the problems are printing emails created in Seamonkey and printed in Seamonkey, no stary code possible there. They are often emails I wrote.


Looking forward to a url to see this in action.

Beverly Howard

_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey

Reply via email to