Re: [Gimp-print-devel] Raw input mode via CUPS?

[Marius S. <ma...@ma...>]

Thanks very much for this explanation - I’m unsure whether I’d be able to study and reconstruct this with reasonable effort and I’m not even sure about the benefit would be worth the effort to me.

Kind regards
Marius Steffen
ma...@ma...



> Am 05.06.2021 um 17:20 schrieb Robert Krawitz <rl...@al...>:
> 
> On 6/4/21 8:21 PM, Marius Steffen wrote:
>> Hi everbody,
>> 
>> I’m currently trying to partially replace Epson’s driver for my SureColor P800 printer. My specific
>> reason is the driver’s inability to print CMYK and directly access all the printers ink channels.
>> While I found out how to do CMYK prints using Gutenprint, I’m failing to do CcMmYKkk prints with
>> files provided in DeviceN space.
>> 
>> I’ve found this rather old message in the mailing list
>> archive: https://sourceforge.net/p/gimp-print/mailman/message/19908513/
>> <https://sourceforge.net/p/gimp-print/mailman/message/19908513/>
>> Essentially, what I’m trying to do is what Robert described in 2) as „raw input with raw color
>> correction“, but I’m failing to see how to do that via CUPS - is this even possible, or is one
>> forced to do this outside of cups, with „pure“ Gutenprint?
>> 
>> Either way, how am I to do this?
> 
> You would have to do this outside of CUPS, at least.  CUPS (at least at the time we wrote the CUPS
> driver for Gutenprint) doesn't support DeviceN.
> 
> Gutenprint provides (for Epson printers, at any rate) the underlying API to do this, but there
> hasn't been enough interest to write a decent user tool to do this.  There is a hack in the
> testpattern generator (src/testpattern) to do this, but to be honest I wrote this years ago just as
> a demo and I don't remember myself how to use it.  What it amounts to is that you need to create a
> file header with the required options (which there are examples of) and use the Raw output mode, and
> then the data has to be provided in binary at the end of the file.  As I said, I (or somebody) would
> have to study this myself to reconstruct how to use it.  The file format is straightforward enough,
> 8 or 16 byte native endian data in pixel order, but I just don't recall the details.