Flyspray:: http://bugs.shaftnet.org/ Flyspray::CUPS Dyesub Backends: Recently closed tasks 2018-05-20T02:11:13Z FS#541: Validate Mitsubishi CP-D90 support http://bugs.shaftnet.org/index.php?do=details&task_id=541 2018-05-20T02:11:13Z Solomon Peachy It looks like it's an evolution of the D70 family, with one critical exception -- it appears as if the color/thermal compensation is performed in the printer instead of the driver! It looks like it's an evolution of the D70 family, with one critical exception -- it appears as if the color/thermal compensation is performed in the printer instead of the driver!

]]>
FS#601: Figure out a way to add a generic test harness for file parsing http://bugs.shaftnet.org/index.php?do=details&task_id=601 2018-05-13T13:09:37Z Solomon Peachy Right now there's no way to parse the input files without the printer being attached first. Would require shimming libusb... Right now there's no way to parse the input files without the printer being attached first.

Would require shimming libusb...

]]>
FS#600: Add support for CUPS Command files http://bugs.shaftnet.org/index.php?do=details&task_id=600 2018-04-28T21:53:04Z Solomon Peachy CUPS defines a "command filter" that gives the ability to perform some actions and queries. ReportLevels -- marker-levels and whatnot.  Highly useful. ReportStatus -- Once we get unified reporting in place, will be handy. AutoConfigure -- Allows the PPD defaults to be updated based on printer configuration.  (!!) PrintSelfTestPage -- For printers that support it [and others that don't matter] There appears to be no way to distinguish betwen a command filter vs print filter via the cmdline or environment.  traditionally these are seperate executables that expect different input data.  I'd like to figure out a way to make the backends detect the command stream vs the normal backend data, and do it all in one executable. CUPS defines a "command filter" that gives the ability to perform some actions and queries.

  • ReportLevels -- marker-levels and whatnot.  Highly useful.
  • ReportStatus -- Once we get unified reporting in place, will be handy.
  • AutoConfigure -- Allows the PPD defaults to be updated based on printer configuration.  (!!)
  • PrintSelfTestPage -- For printers that support it
  • [and others that don't matter]

There appears to be no way to distinguish betwen a command filter vs print filter via the cmdline or environment.  traditionally these are seperate executables that expect different input data.  I'd like to figure out a way to make the backends detect the command stream vs the normal backend data, and do it all in one executable.

]]>
FS#596: Figure out if Citizen CW-02/OP900II are closer to CX or CY series http://bugs.shaftnet.org/index.php?do=details&task_id=596 2018-03-27T00:04:19Z Solomon Peachy ...or if they need their own designation in Gutenprint and selphy_print. It looks like they don't map entirely cleanly to either for avialable print options, but the real question is the firmware version tests for features. ...or if they need their own designation in Gutenprint and selphy_print.

It looks like they don't map entirely cleanly to either for avialable print options, but the real question is the firmware version tests for features.

]]>
FS#599: Enhance Magicard driver to allow for different options on the duplex side. http://bugs.shaftnet.org/index.php?do=details&task_id=599 2018-03-18T18:45:05Z Solomon Peachy At minimum, the overcoat hole is different on front vs back (eg smartcard vs magstripe). Magstripe probably only belongs on the back, smartcard on the front. Holokote and holopatch likely need to be different too. At minimum, the overcoat hole is different on front vs back (eg smartcard vs magstripe).

Magstripe probably only belongs on the back, smartcard on the front.

Holokote and holopatch likely need to be different too.

]]>
FS#597: Allow for aliases in backend names? http://bugs.shaftnet.org/index.php?do=details&task_id=597 2018-03-16T19:38:04Z Solomon Peachy That would allow us to present a 'modern' name for the backend but still provide backwards compatibility. eg: dnpds40 -> dnp_citizen or mitsu9550 -> mitsu9xxx or mitsup95d->mitsu_p9x Another approach would be to make things more fine-grained.   That would allow us to present a 'modern' name for the backend but still provide backwards compatibility.

eg: dnpds40 -> dnp_citizen or mitsu9550 -> mitsu9xxx or mitsup95d->mitsu_p9x

Another approach would be to make things more fine-grained.

 

]]>
FS#532: Verify support for S1245 http://bugs.shaftnet.org/index.php?do=details&task_id=532 2018-01-27T01:29:07Z Solomon Peachy Code complete, but needs testing. Code complete, but needs testing.

]]>
FS#519: Investigate Mitsubishi CP-W5000 http://bugs.shaftnet.org/index.php?do=details&task_id=519 2018-01-26T01:47:49Z Solomon Peachy The CP-W5000 is a duplex 8" model, apparenltly a rebadged Kodak D4000 The CP-W5000 is a duplex 8" model, apparenltly a rebadged Kodak D4000

]]>
FS#577: Add ability to query status from cmdline http://bugs.shaftnet.org/index.php?do=details&task_id=577 2018-01-08T12:22:24Z Solomon Peachy We don't get much info, but we can at least find out if any errors are pending, and if the printer is busy.. We don't get much info, but we can at least find out if any errors are pending, and if the printer is busy..

]]>
FS#581: Add status query to Canon Selphy backends http://bugs.shaftnet.org/index.php?do=details&task_id=581 2018-01-04T15:00:50Z Solomon Peachy Query printer status -- eg loaded paper type, error codes, and whatnot. The raw data is already there, but it would require a different code path to parse things for human output. Query printer status -- eg loaded paper type, error codes, and whatnot.

The raw data is already there, but it would require a different code path to parse things for human output.

]]>