🚀 go-pugleaf

In article <10170@pasteur.Berkeley.EDU> carlson@ernie.Berkeley.EDU (Richard L. Carlson) writes:
>In article <6024@cbmvax.UUCP> daveb@cbmvax.UUCP (Dave Berezowski) writes:
>>	There is in fact a bug in the V1.3 printer.device that only affects
>>PCC_MULTI_PASS printers (like the Shinko) when smoothing is turned on.
>>Have the company contact me here at Commodore and we'll see what we can do.
>>
>>David Berezowski
>
>What about those of us that are writing our own printer drivers for
>not-so-common printers?  Is there any chance that you could post some
>suggestions for working around or solving the problem?  (i.e., can you
>set the type to something besides PCC_MULTI_PASS and just make the printer-
>dependent code go to more work to separate the colors itself?)
>Or can you at least give us a few more details about this bug?
>
	The workaround is to write a driver which is NOT a PCC_MULTI_PASS
type printer driver.  However, this requires oooodles and oooodles of
memory for a dump.  Refer to the CalComp_ColorMaster and CalComp_ColorMaster2
source code.  The former is a PCC_MULTI_PASS type printer driver, the
later is not.  You should also refer to page 4-4 of the V1.3 enhancer
manual which explains the memory requirements for the driver(s).

	Basically, the CalComp printer requires that you send it all the
yellow data for the entire picture, then all the magenta data, and
finally all the cyan data.  These means that you either have to scan
the entire screen three times (PCC_MULTI_PASS) or buffer up all three
planes before you send them to the printer (ie. use LOTS of memory).

	The only printers that I am familar with that have this strange
quirk are:

	CalComp_ColorMaster (PlotMaster and ColorView as well)
	Seiko_5300 line
	Shinko
	Mitshubishi
	Vertex
	(others I may have forgotten)

	They are all thermal transfer printers that use a three (or 4)
color donor roll.


	Hope this helps.