Flyspray:: http://bugs.shaftnet.org/ Flyspray::CUPS Dyesub Backends: Recently closed tasks 2019-06-04T12:39:59Z FS#564: D70 fails to print on Raspberry Pi systems http://bugs.shaftnet.org/index.php?do=details&task_id=564 2019-06-04T12:39:59Z Solomon Peachy We get failures when sending the printjob to the printer, with libusb reporting USB timeouts at random places.  There seems to be no consistency to when a transfer fails.  Using a hub makes this worse. I have an additional two reports of a RPi3 failing USB transfers to a D80 when there is no ethernet cable plugged into the interface!   The K60/EK305 appears to work okay. We get failures when sending the printjob to the printer, with libusb reporting USB timeouts at random places.  There seems to be no consistency to when a transfer fails.  Using a hub makes this worse.

I have an additional two reports of a RPi3 failing USB transfers to a D80 when there is no ethernet cable plugged into the interface!

 

The K60/EK305 appears to work okay.

]]>
FS#612: Unify the various Shinko/Sinfonia backends http://bugs.shaftnet.org/index.php?do=details&task_id=612 2019-05-25T13:59:44Z Solomon Peachy For the most part, the shinko/sinfonia printers are quite similar in how they operate. There are unfortunately differences in specific commands and how some of the fields in the headers are parsed. So, now that the backend infrastructure is decoupled from the "model name", look into unifying: Sinfonia S2145 Sinfonia S6145 Sinfonia S6245 Kodak 605 These two are different than the others, but close to each other: Sinfonia S1245 Kodak 6800/6850 Meanwhile, these new models are likely similar to models in the first set: Sinfonia 2245 Kodak 7000/7010/7015 Sinfonia 8145 Kodak 8810 Sinfonia DP-1045 Kodak D4000 What I expect to do is that when/if support for one or more of these new models is implemented, it will be bolted onto an existing backend, and that will be the basis for merging in the others. For the most part, the shinko/sinfonia printers are quite similar in how they operate. There are unfortunately differences in specific commands and how some of the fields in the headers are parsed.

So, now that the backend infrastructure is decoupled from the "model name", look into unifying:

  • Sinfonia S2145
  • Sinfonia S6145
  • Sinfonia S6245
  • Kodak 605

These two are different than the others, but close to each other:

  • Sinfonia S1245
  • Kodak 6800/6850

Meanwhile, these new models are likely similar to models in the first set:

  • Sinfonia 2245
  • Kodak 7000/7010/7015
  • Sinfonia 8145
  • Kodak 8810
  • Sinfonia DP-1045
  • Kodak D4000

What I expect to do is that when/if support for one or more of these new models is implemented, it will be bolted onto an existing backend, and that will be the basis for merging in the others.

]]>
FS#538: Add support for DS80DX http://bugs.shaftnet.org/index.php?do=details&task_id=538 2019-05-21T15:11:55Z Solomon Peachy It has all the joy of the DS80, but also supports sheet-fed simplex and duplex operation. It's a veritable mess to support cleanly. It has all the joy of the DS80, but also supports sheet-fed simplex and duplex operation. It's a veritable mess to support cleanly.

]]>
FS#611: Support Kodak 6900 (aka HiTi M610 / X610) http://bugs.shaftnet.org/index.php?do=details&task_id=611 2019-05-13T13:38:02Z Solomon Peachy The Kodak 6900 looks to be a rebadged HiTi M610, which itself is closely related to the X610. Figure out the spool format to get preliminary support! The Kodak 6900 looks to be a rebadged HiTi M610, which itself is closely related to the X610.

Figure out the spool format to get preliminary support!

]]>
FS#575: Investigate Sony B&W Thermal MedSci models http://bugs.shaftnet.org/index.php?do=details&task_id=575 2019-03-26T00:48:06Z Solomon Peachy UPD-897MD, UP-X898MD, and so forth the UP-D898MD appears to be superficially similar to the Mitsubishi models, complete with the 1280 pixel print head (maxing out at 1280x4000ish) and similar adjustment knobs. They may have the same engine under the hood, but they're not likely to be semi-compatible with the Mitsubishi models. UPD-897MD, UP-X898MD, and so forth

the UP-D898MD appears to be superficially similar to the Mitsubishi models, complete with the 1280 pixel print head (maxing out at 1280x4000ish) and similar adjustment knobs. They may have the same engine under the hood, but they're not likely to be semi-compatible with the Mitsubishi models.

]]>
FS#571: Check for error statuses in the Kodak 605 processing loops. http://bugs.shaftnet.org/index.php?do=details&task_id=571 2019-01-30T03:17:19Z Solomon Peachy We don't check any error codes at all.  In part because I don't know what's an error and what isn't.  With access to a printer this would be a lot easier.. We don't check any error codes at all.  In part because I don't know what's an error and what isn't.  With access to a printer this would be a lot easier..

]]>
FS#552: Write network backend for CPnP printers http://bugs.shaftnet.org/index.php?do=details&task_id=552 2019-01-30T01:01:59Z Solomon Peachy The 'selphy_go' code showed how to detect CPnP models and send JPGs over to be printed.. Using the CP900, I discovered how to send raw YMC data over CPnP.  This means we can write a native CPnP CUPS+Gutenprint backend for that model. Unfortunately we won't know if the newer selphyneo models support non-jpeg CPnP printing -- The Windows driver uses WSA/WSD and Macs appear to use AirPrint.  The only way to find out is to write it first. The 'selphy_go' code showed how to detect CPnP models and send JPGs over to be printed..

Using the CP900, I discovered how to send raw YMC data over CPnP.  This means we can write a native CPnP CUPS+Gutenprint backend for that model.

Unfortunately we won't know if the newer selphyneo models support non-jpeg CPnP printing -- The Windows driver uses WSA/WSD and Macs appear to use AirPrint.  The only way to find out is to write it first.

]]>
FS#540: Investigate Fuji ASK 2000/2500/4000 (aka Nidec Copal DPB-6000/7000/4000) http://bugs.shaftnet.org/index.php?do=details&task_id=540 2019-01-29T22:01:39Z Solomon Peachy They are all related; The 4000 is an 8" version, and the 2000 is an older, slower version of the 2500, both 6" models.   All are rebadged versions of Nidec Copal printers -- ASK4000 == DPB-4000C1, ASK2500 == DPB-7000, ASK2000 == DPB-6000 They are all related; The 4000 is an 8" version, and the 2000 is an older, slower version of the 2500, both 6" models.

 

All are rebadged versions of Nidec Copal printers -- ASK4000 == DPB-4000C1, ASK2500 == DPB-7000, ASK2000 == DPB-6000

]]>
FS#595: When trying to enumerate printers, don't block for a long time when one's busy http://bugs.shaftnet.org/index.php?do=details&task_id=595 2019-01-17T14:43:54Z Solomon Peachy This is a particular problem when we have more than one model of the same printer family attached, and one or more of them are busy doing something -- but we can't query the serial number when the printer is claimed. This may require a two pass approach -- first try to probe everything with minimal timeouts.  If we don't succeed in finding the one we want, re-try the probe with longer timeouts.  In both cases, we shouldn't report a failure until we finish walking the entire list. This is a particular problem when we have more than one model of the same printer family attached, and one or more of them are busy doing something -- but we can't query the serial number when the printer is claimed.

This may require a two pass approach -- first try to probe everything with minimal timeouts.  If we don't succeed in finding the one we want, re-try the probe with longer timeouts.  In both cases, we shouldn't report a failure until we finish walking the entire list.

]]>
FS#603: Support using external LUT http://bugs.shaftnet.org/index.php?do=details&task_id=603 2018-12-16T01:23:59Z Solomon Peachy The official drivers come with a file called 'P95D.lut' that consists of a 16-byte header followed by 34 bytes of LUT that neatly fit into the "gamma" header.  I see two approaches: Add another gamma enumeration, for "external LUT" Have the backend read the file and fil the job at runtime Permanently store the file in the backend, fill job at runtime Have Gutenprint fill in the gamma table from hardcoded value Allow gutenprint's gamma table to be overridden. I'm thinking that pushing this into Gutenprint (hardcoded, but overridable via an option) is the right way to do this. The official drivers come with a file called 'P95D.lut' that consists of a 16-byte header followed by 34 bytes of LUT that neatly fit into the "gamma" header.  I see two approaches:

  1. Add another gamma enumeration, for "external LUT"
    • Have the backend read the file and fil the job at runtime
    • Permanently store the file in the backend, fill job at runtime
  2. Have Gutenprint fill in the gamma table from hardcoded value
  3. Allow gutenprint's gamma table to be overridden.

I'm thinking that pushing this into Gutenprint (hardcoded, but overridable via an option) is the right way to do this.

]]>