Flyspray:: http://bugs.shaftnet.org/ Flyspray::CUPS Dyesub Backends: Recently opened tasks 2018-05-13T13:09:37Z 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#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#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#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 2018-02-16T12:11:44Z 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#592: Investigate Sony UPCX1 http://bugs.shaftnet.org/index.php?do=details&task_id=592 2018-01-28T13:39:04Z Solomon Peachy 300 dpi, 4" or 5" wide media. Not sure if it uses sheet or roll media. 300 dpi, 4" or 5" wide media.

Not sure if it uses sheet or roll media.

]]>
FS#591: Investigate Kodak DL2100 http://bugs.shaftnet.org/index.php?do=details&task_id=591 2018-01-27T01:27:42Z Solomon Peachy It's a duplexing "electro-photographic" (AKA laser) printer @600x1200dpi.  They rarget photo books and calendars with it.   Appears to be a rebranded version of the Oki C712. It's a duplexing "electro-photographic" (AKA laser) printer @600x1200dpi.  They rarget photo books and calendars with it.

 

Appears to be a rebranded version of the Oki C712.

]]>
FS#590: Investigate Kodak D4600 / Mitsubishi CP-W5000 http://bugs.shaftnet.org/index.php?do=details&task_id=590 2018-01-26T01:46:29Z Solomon Peachy Duplexing 8x12" models, capable of cuts along both axes. Duplexing 8x12" models, capable of cuts along both axes.

]]>
FS#589: Fix 8bpp->6bpp color scaling http://bugs.shaftnet.org/index.php?do=details&task_id=589 2018-01-04T01:58:57Z Solomon Peachy Right now we just shift the color data over by 2bits.  It looks like that's naive; it looks like we need some sort of gamma-aware 8->6 mapping on a per-channel basis.  This may require Gutenprint to spit out RGB data, and we perform the YMC conversion at the same time we apply gamma?  (not unlike the Mitsu D70 family..) The printer's "gamma curve" settings don't seem to have any major effect. It's also possible that my printer's head is just plain shot (there's already a bad row of pixels..), and that everything is actually fine. Right now we just shift the color data over by 2bits.  It looks like that's naive; it looks like we need some sort of gamma-aware 8->6 mapping on a per-channel basis.  This may require Gutenprint to spit out RGB data, and we perform the YMC conversion at the same time we apply gamma?  (not unlike the Mitsu D70 family..)

The printer's "gamma curve" settings don't seem to have any major effect.

It's also possible that my printer's head is just plain shot (there's already a bad row of pixels..), and that everything is actually fine.

]]>