Flyspray:: http://bugs.shaftnet.org/ Flyspray::CUPS Dyesub Backends: Recently edited tasks 2018-09-18T18:10:15Z FS#539: Consolidate CW-01 and DNP backends http://bugs.shaftnet.org/index.php?do=details&task_id=539 2018-09-18T18:10:15Z Solomon Peachy There's a great deal of overlap; the main difference is the format of the print job. It may make sense to fold the CW-01 stuff into the DNP backend (including the spool format), but alternatively perhaps just a shared library? There's a great deal of overlap; the main difference is the format of the print job. It may make sense to fold the CW-01 stuff into the DNP backend (including the spool format), but alternatively perhaps just a shared library?

]]>
FS#550: Verify support for D707 http://bugs.shaftnet.org/index.php?do=details&task_id=550 2018-09-18T18:09:48Z Solomon Peachy Code's complete, but needs to be verified.   Code's complete, but needs to be verified.

 

]]>
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-06-28T19:03:05Z 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#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 2018-06-19T00:25:26Z 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#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#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#558: Investigate new Sinfonia S3 (CHC-S2245) http://bugs.shaftnet.org/index.php?do=details&task_id=558 2018-05-13T17:04:11Z Solomon Peachy Replacement for the S2145, it's main fature is high capacity (900 print) media. https://www.sinfo-t.jp/eng/printer/chc_s2245.htm Initial investigation implies it may require host-side image processing, not unlike the S6145. Replacement for the S2145, it's main fature is high capacity (900 print) media.

https://www.sinfo-t.jp/eng/printer/chc_s2245.htm

Initial investigation implies it may require host-side image processing, not unlike the S6145.

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

]]>