Gutenprint / CUPS Dye-sublimation drivers

When you have more than one printer in the system, how about ignoring the ones that are busy when trying to service a print job?

For printers that support multiple media types, it would be handy to be able to return which media the printer has loaded, so we
can more intelligently route print jobs.

This is probably beyond the scope of a CUPS backend, but may be handy for standalone operation.

Just a WIBNI.

The remaining chunk of the patch set Ake Koomsin sent over considerably improves error detection, handling, and recovery from the CP-XXX handler. (The other models are TBD)

Wade through the patch set to make sure everything relevant is integrated.

(FWIW, this is a lot easier now that the backend is unified; it simplified the code quite a bit)

It looks like this printer needs a backend.

Also, the '-S' suffixed models probably use a different comms mechanism.

At first blush it looks like the "professional" version of the K60DW-S with higher-speed operation.

Should be straightforward.

The 8800 seems to be related to the Kodak 9810

The work's done, but it's not merged yet.

*OPIcon Manufacturer: "...."

*OPIcon ModelName: "...."

The data is UUEncoded/Base64 64x64 PNG or an SVG image.

I see printers.xml gaining a reference to the image files, and the PPD generation code reading the image, encoding it, and shoving it into the PPD.  It's a minor thing, but nice to have.

Now that the P95 is in solid shape, I don't imagine that the other models would pose much of a problem.

We don't get much info, but we can at least find out if any errors are pending, and if the printer is busy..

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.

A backend's in place that can read the printer status but it doesn't parse/send over jobs yet.  Still haven't figured out the image dara format.

Duplexing 8x12" models, capable of cuts along both axes.

It's a duplexing "electro-photographic" (AKA laser) printer @600x1200dpi.  They target photo books and calendars with it.

Appears to be a rebranded version of the Oki Data C712dn.

300 dpi, 4" or 5" wide media.

Not sure if it uses sheet or roll media.

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.

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.

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.

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.