Flyspray:: Flyspray::CUPS Dyesub Backends: Recently opened tasks http://bugs.shaftnet.org/ 2019-06-04T12:37:34Z FS#614: Validate new size support and other feature additions on the EK605 2019-06-04T12:37:34Z 2019-05-13T01:31:01Z

Additional print sizes in latest firmware, plus all of the extra features pulled in via the Sinfonia framework (eg firmware version detection, LED blinking, status and error reporting, and so forth..)

Solomon Peachy http://bugs.shaftnet.org/:614
FS#613: Figure out how to pipeline jobs 2019-05-11T22:07:27Z 2019-05-11T22:07:27Z

Right now the backend won't attempt to send anything over if a given deck is printing. However, the printer has 4*num_banks buffers that can be used to pipeline jobs!

So, try to figure out a way to overlap things. We'll have to be smarter about jobids..

Solomon Peachy http://bugs.shaftnet.org/:613
FS#612: Unify the various Shinko/Sinfonia backends 2019-05-25T13:59:44Z 2019-04-28T13:20:32Z

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.

Solomon Peachy http://bugs.shaftnet.org/:612
FS#611: Support Kodak 6900 (aka HiTi M610 / X610) 2019-05-13T13:38:02Z 2019-04-10T18:07:38Z

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!

Solomon Peachy http://bugs.shaftnet.org/:611
FS#609: Add support for Sony UP-D898 series 2019-04-21T17:50:46Z 2019-03-26T00:54:03Z

Unlike the D895 and D897, the jobs are wrapped in HP-PJL. No idea if the data format is equivalent.

Solomon Peachy http://bugs.shaftnet.org/:609
FS#608: Make Gutenprint more cross-compile friendly 2019-01-17T14:36:14Z 2019-01-17T14:36:14Z

The problem is that, at compile time, we rely on some host-compiled stuff to generate data files and whatnot. We need to compile the same stuff for the target.

I wonder if it may be worth moving to a more unified Make environment..

Solomon Peachy http://bugs.shaftnet.org/:608
FS#604: Use a simpler URI scheme 2018-09-18T18:08:41Z 2018-08-14T20:25:58Z

Currently the URI scheme is a little convoluted:

     prefix://iManufacturer/iModel?backend=XXX&serial=YYYY

I'd like to move to something much simpler:

     prefix://backend/serial

Now that the core code returns a unique, per-model string that can be used to look up the backend, this is a far simpler approach to take.  We'll have to support the old scheme indefinitely though.

Solomon Peachy http://bugs.shaftnet.org/:604
FS#603: Support using external LUT 2018-12-16T01:23:59Z 2018-06-28T19:03:05Z

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.

Solomon Peachy http://bugs.shaftnet.org/:603
FS#602: Support combining print jobs 2018-06-17T17:57:58Z 2018-06-15T20:58:23Z

As a way to prevent wasting media, when using 6x8" media, automagically combine consecutive 4x6" jobs to a single 8x6" print and submit that to the printer behind the scenes.

The D90 and Kodak 68xx do this automatically in the printer, and others (eg Mitsu D70 family) do this in the driver.

Extend the backend core to support this generically, and try to add specific support to printers/families that can use this feature.

Solomon Peachy http://bugs.shaftnet.org/:602
FS#601: Figure out a way to add a generic test harness for file parsing 2018-05-13T13:09:37Z 2018-05-10T02:14:19Z

Right now there's no way to parse the input files without the printer being attached first.

Would require shimming libusb...

Solomon Peachy http://bugs.shaftnet.org/:601