Flyspray:: http://bugs.shaftnet.org/ Flyspray::CUPS Dyesub Backends: Recently opened tasks 2019-06-04T12:37:34Z FS#614: Validate new size support and other feature additions on the EK605 http://bugs.shaftnet.org/index.php?do=details&task_id=614 2019-06-04T12:37:34Z Solomon Peachy 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..) 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..)

]]>
FS#613: Figure out how to pipeline jobs http://bugs.shaftnet.org/index.php?do=details&task_id=613 2019-05-11T22:07:27Z Solomon Peachy 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.. 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..

]]>
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#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#609: Add support for Sony UP-D898 series http://bugs.shaftnet.org/index.php?do=details&task_id=609 2019-04-21T17:50:46Z Solomon Peachy Unlike the D895 and D897, the jobs are wrapped in HP-PJL. No idea if the data format is equivalent. Unlike the D895 and D897, the jobs are wrapped in HP-PJL. No idea if the data format is equivalent.

]]>
FS#608: Make Gutenprint more cross-compile friendly http://bugs.shaftnet.org/index.php?do=details&task_id=608 2019-01-17T14:36:14Z Solomon Peachy 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.. 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..

]]>
FS#604: Use a simpler URI scheme http://bugs.shaftnet.org/index.php?do=details&task_id=604 2018-09-18T18:08:41Z Solomon Peachy 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. 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.

]]>
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.

]]>
FS#602: Support combining print jobs http://bugs.shaftnet.org/index.php?do=details&task_id=602 2018-06-17T17:57:58Z Solomon Peachy 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. 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.

]]>
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...

]]>