ed@zaphod.uchicago.edu (Ed Friedman) (02/18/89)
We are looking to buy a custom printer driver for a Shinko color printer. The company that makes it claims that they are unable to do smoothing in the screendump because of a bug in the 1.3 printer.dev file. They claim that Commodore knows about and have a fix for it but will not release the fix. Does anyone know if such a bug does in fact exist and when a fix might be available? Thanks in advance, Ed Friedman ed@zaphod.uchicago.edu friedman@uchicago.BITNET
daveb@cbmvax.UUCP (Dave Berezowski) (02/21/89)
In article <1899@tank.uchicago.edu> ed@zaphod.uchicago.edu (Ed Friedman) writes: >We are looking to buy a custom printer driver for a Shinko color printer. >The company that makes it claims that they are unable to do smoothing in >the screendump because of a bug in the 1.3 printer.dev file. They claim >that Commodore knows about and have a fix for it but will not release the >fix. Does anyone know if such a bug does in fact exist and when a fix >might be available? > 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 (215) 431-9100
carlson@betelgeuse (Richard L. Carlson) (02/22/89)
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? Thank you. -- Richard {tektronix,dual,sun,decvax,...}!ucbvax!ernie!carlson carlson@ernie.berkeley.edu
daveb@cbmvax.UUCP (Dave Berezowski) (02/22/89)
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.