gimp-print-devel

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Michael S. <ms...@ms...>]

Walker,

> On Nov 2, 2021, at 4:25 PM, Walker Blackwell <fo...@wa...> wrote:
> ...
> How would you go about proposing to use PAPPL in this context? Let’s say we want to use a different ink in the P900 printer (something commonly done in it’s older brethren 3880s, P800s, etc) and need to send non RGB data in order to do that. 

Then you tell PAPPL that you have DeviceN support and hopefully have client software that can produce it.  From the standpoint of Gutenprint, once you depart from the normal colors you'll need to provide your own separation.  Any configuration of Gutenprint can be done using the existing options, which get mapped from a few IPP collection attributes and/or a web form hosted by PAPPL.

> Epson does not share ESCP APIs with the open source community even though they use Linux and a slew of other FOSS to run their machines. Are you saying we can use IPP in this case? If we don’t know the targets and slots to hit with IPP how can we use it? They aren’t broadcast by the printer

So from the standpoint of Gutenprint, you are not using the IPP endpoint of the printer when you do all of this custom ink stuff.  And I well know how little Epson documents these printers and the command set... :/

________________________
Michael Sweet

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Walker B. <fo...@wa...>]

usb://EPSON/SC-P900%20Series?serial=583757503030343009 "EPSON SC-P900 Series" "EPSON SC-P900 Series" "MFG:EPSON;CMD:ESCPL2,BDC,D4,D4PX,ESCPR7,END4,GENEP;MDL:SC-P900 Series;CLS:PRINTER;DES:EPSON SC-P900 Series;CID:EpsonRGB;RID:02;DDS:401900;ELG:13F0;" ""

Yep supports it.

P800 driver works pretty well. I’ll test various things.

I would assume the P600 driver would do well for the P700 as well . . .

best
Walker


> On Nov 4, 2021, at 3:35 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> On Thu, Nov 04, 2021 at 01:06:15PM -0400, Walker Blackwell wrote:
>> I feel slightly discouraged that we can get anything from these files as it’s ESCP/R and not ESCP/2 but who knows. 
> 
> Yeah, it's all ESCP/R.  :/
> 
> Can you supply the IEEE1284 dump?  I don't know how to do this under 
> MacOS but under linux you can just run 'sudo /usr/lib/cups/backend/usb' 
> and it'll be in the output.
> 
> That will tell us if the printer claims to support ESCP/2 at all.
> 
> - Solomon
> -- 
> Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
>                                      @pizza:shaftnet dot org   (matrix)
> High Springs, FL                      speachy (libra.chat)
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Issue : CUPS En pause "printer error: No paper

[Solomon P. <pi...@sh...>]

On Wed, Nov 03, 2021 at 11:40:43PM +0100, Quentin Vtt wrote:
> Everything work well until there is no paper in the canon Selphy CP1000
> 
> The state of the printer go to “En pause – “Printer error: No Paper (03)”
> 
> Even if load paper, turn Off then turn On the printer, the state in CUPS
> don’t change and there is no more print.

CUPS has no way of knowing that the printer error has been resolved; the 
presumption is that when the operator (ie you) resovles the issue, you 
then tell CUPS to re-start the queue.

> sudo cupsenable Canon_CP1000 work also

This is what I personally use.

> I read on the web that “ErrorPolicy retry-job” could solve this problem,
> but this rule seems to be already set by default in my CUPS version 2.2.10

ErrorPolicy only applies when the error is the more generic FAILED.

> To sum it up, the queue disabled correctly in CUPS because it is told to do
> so. 

Yes, this is the intended behavior, as the printer will not be capable 
of accepting new jobs until the error is resolved by the operator.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Solomon P. <pi...@sh...>]

On Thu, Nov 04, 2021 at 01:06:15PM -0400, Walker Blackwell wrote:
> I feel slightly discouraged that we can get anything from these files as it’s ESCP/R and not ESCP/2 but who knows. 

Yeah, it's all ESCP/R.  :/

Can you supply the IEEE1284 dump?  I don't know how to do this under 
MacOS but under linux you can just run 'sudo /usr/lib/cups/backend/usb' 
and it'll be in the output.

That will tell us if the printer claims to support ESCP/2 at all.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Walker B. <fo...@wa...>]

I have done print file pulls from the P900 driver here:

https://drive.google.com/file/d/1ifkqwp83V5_Snk-8nr3Jam_uRpkucLbQ/view?usp=sharing <https://drive.google.com/file/d/1ifkqwp83V5_Snk-8nr3Jam_uRpkucLbQ/view?usp=sharing>

Attached is a screenshot of each print file’s settings with the same name as the .prn file. I’ve attempted to only change a single setting per print file to allow for a code Dif evaluation.

I think the black selection is going to be somehow activated by the media type on this printer (aka sending Velvet Fine Art media type code should print from the MK channel) but that is just a hunch.

I feel slightly discouraged that we can get anything from these files as it’s ESCP/R and not ESCP/2 but who knows. 

I’ll try and build a dummy Gutenprint driver out of the P800 xml next . . .

Best all,
Walker





> On Nov 2, 2021, at 4:26 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On 11/2/21 4:15 PM, Michael Sweet via Gimp-print-devel wrote:
>> Robert,
>> 
>>> On Nov 2, 2021, at 4:04 PM, Robert Krawitz <rl...@al...> wrote:
>>> 
>>> On 11/2/21 1:25 PM, Walker Blackwell wrote:
>>>> Yes, but some people's motivations are much more elaborate: aka addressing individual channels for silk screens dye ink transparency printing, monochromatic ink sets, white inks, allowing for over-inking or under-inking (uncoated papers, fabric, etc). 
>>> 
>>> Exactly, and in the context of a printer app this is why we need all of the detailed ink options:
>>> there are people who use them, and 32 options simply isn't enough to cover these use cases.  There's
>>> no way the T-shirt people could print with IPP Everywhere.
>> 
>> I've already explained why "32 options" isn't a limitation for PAPPL-based printer applications, and given that IPP is used for ALL kinds of printing you really can't say that one particular kind of printing can't be done - it *is* done, on a regular basis.
> 
> IPP as a transport is fine.
> 
>> (and if we are being real here, most printed T-shirt stores use iron-transfer with standard inks for photos and screen printing for simpler/stock N-color designs)
> 
> Hobbyists don't.
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Gimp-print-devel] Issue : CUPS En pause "printer error: No paper

[Quentin V. <ra...@gm...>]

Hello,
I have an issue with the *Canon Selphy CP1000 *printer and *CUPS*.

Everything work well until there is no paper in the canon Selphy CP1000

The state of the printer go to “En pause – “Printer error: No Paper (03)”

Even if load paper, turn Off then turn On the printer, the state in CUPS
don’t change and there is no more print.
I need to manually click on “start the printer” in CUPS interface, then the
printer is working well.
sudo cupsenable Canon_CP1000 work also

I read on the web that “ErrorPolicy retry-job” could solve this problem,
but this rule seems to be already set by default in my CUPS version 2.2.10

Thank to help on github, from the logs :

"I can see the reason why the queue is stopped and you need to enabled it
to run it again. There are two things which need to be in place for
retry-job to be activated:

   - the job has to be in processing (IPP_JOB_PROCESSING) or completed
   (IPP_JOB_COMPLETED) states
   - the backend has to return failed (CUPS_BACKEND_FAILED) or retry
   (CUPS_BACKEND_RETRY) states

For your job, the job is in the processing state, but the gutenprint
backend itself returns CUPS_BACKEND_STOP, which disables the print queue in
CUPS.

To sum it up, the queue disabled correctly in CUPS because it is told to do
so. You can contact Gutenprint developers on their mailing list -
gim...@li... - to see whether the error code from
the backend is correct or if it is a bug."


So share with you my issue.


Thank

Best regard

Quentin HUBERT

[Gimp-print-devel] Canon Pixma G2560 problems

[Steve D. <sjd...@ta...>]

Hi

 

I am trying to set up a Raspberry pi as a network print server using CUPS.
It works fine for a HP Laserjet I have, which shows the basic configuration
is OK, but no joy for a new Canon G2560.   When trying a test page, it looks
like data is being received by the printer as a 'please wait momentarily'
message appears for a few seconds, but nothing is actually printed and the
message disappears.   I am using the G2500 series driver as it appears to be
the most applicable.

 

Any advice would be much appreciated.

 

Thanks

 

Steve

[Gimp-print-devel] Cannon iP2800 driver works!

[Dan D. <dan...@gm...>]

Thanks for all your hard work.


I'd like to report that the Cannon iP2800 driver worked perfectly for 
me. I am running ubuntu 20-04 on a fairly recent hp laptop (2 years old)

Especially gratifying is that when running in dual boot windows 10, the 
software wants me to buy a new cartridge


Thanks

dan damon

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Robert K. <rl...@al...>]

On 11/2/21 4:15 PM, Michael Sweet via Gimp-print-devel wrote:
> Robert,
> 
>> On Nov 2, 2021, at 4:04 PM, Robert Krawitz <rl...@al...> wrote:
>>
>> On 11/2/21 1:25 PM, Walker Blackwell wrote:
>>> Yes, but some people's motivations are much more elaborate: aka addressing individual channels for silk screens dye ink transparency printing, monochromatic ink sets, white inks, allowing for over-inking or under-inking (uncoated papers, fabric, etc). 
>>
>> Exactly, and in the context of a printer app this is why we need all of the detailed ink options:
>> there are people who use them, and 32 options simply isn't enough to cover these use cases.  There's
>> no way the T-shirt people could print with IPP Everywhere.
> 
> I've already explained why "32 options" isn't a limitation for PAPPL-based printer applications, and given that IPP is used for ALL kinds of printing you really can't say that one particular kind of printing can't be done - it *is* done, on a regular basis.

IPP as a transport is fine.

> (and if we are being real here, most printed T-shirt stores use iron-transfer with standard inks for photos and screen printing for simpler/stock N-color designs)

Hobbyists don't.

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Walker B. <fo...@wa...>]

Dear Michael, 


> I've already explained why "32 options" isn't a limitation for PAPPL-based printer applications, and given that IPP is used for ALL kinds of printing you really can't say that one particular kind of printing can't be done - it *is* done, on a regular basis.

How would you go about proposing to use PAPPL in this context? Let’s say we want to use a different ink in the P900 printer (something commonly done in it’s older brethren 3880s, P800s, etc) and need to send non RGB data in order to do that. 

Epson does not share ESCP APIs with the open source community even though they use Linux and a slew of other FOSS to run their machines. Are you saying we can use IPP in this case? If we don’t know the targets and slots to hit with IPP how can we use it? They aren’t broadcast by the printer.

> 
> (and if we are being real here, most printed T-shirt stores use iron-transfer with standard inks for photos and screen printing for simpler/stock N-color designs)

I can tell you from first hand experience, that the industry is only slowly moving away from trans film towards Direct To Film inks but these require white still. A majority of small outfits are still silk screen and are forced to use the 1430 platform. A working 1430 goes upwards of 2grand per printer now where it used to cost $350 new.

best
Walker


> 
> 
>> In a lot of ways, I'm more concerned with these exotic uses than with day-to-day printing,
>> especially with IPP Everywhere and driverless printers.  These are niche markets, but they're
>> underserved and as we're not a business we're in a good position to support these use cases.
>> 
>>>> On Nov 2, 2021, at 8:22 AM, Michael Sweet via Gimp-print-devel <gim...@li...> wrote:
>>>> 
>>>> FWIW, the P900 is an AirPrint printer, which means you should be able to use it out of the box without drivers using CUPS' IPP Everywhere support.  And it should support both sRGB and AdobeRGB like the P800...
>>>> 
>>>> 
>>>>> On Nov 2, 2021, at 8:06 AM, Walker Blackwell <fo...@wa...> wrote:
>>>>> 
>>>>> I just got a P900 in-house. I gotta boot a linux machine and start cracking. . .
>>>>> 
>>>>> I’m going to assume the P900 requirements are pretty close to the P800 (2 picoliter SureColor head though so maybe close to P600) but won’t know for sure until I get at it.
>>>>> 
>>>>> Best,
>>>>> Walker
>>>>> 
>>>>> 
>>>>>> On Nov 2, 2021, at 3:00 AM, Oliver Kowalke <oli...@gm...> wrote:
>>>>>> 
>>>>>> I checked out the git repo (branch master) and I started reading "The Developer’s Guide to Gutenprint".
>>>>>> Unfortunately I can not find the printers.xml as mentioned in the guide - instead ./src/xml/printers/escp2.xml contains the Epson models. Is this the correct file? Maybe the guide is not up-to-date?
>>>>>> 
>>>>>> In ./src/xml/printers/escp2.xml the SC-P700 and SC-P900 is not listed. Does this mean that both models are not supported yet or is it the wrong file?
>>>>>> 
>>>>>> 
>>>>>> Am Mo., 1. Nov. 2021 um 23:47 Uhr schrieb Robert Krawitz <rl...@al...>:
>>>>>> On 11/1/21 1:29 AM, Oliver Kowalke wrote:
>>>>>>> 
>>>>>>>  It should be possible to support this, other than the violet channel.  We could support the violet
>>>>>>>  channel for raw printing (i. e. the user has to do the separations), but actually supporting the
>>>>>>>  violet ink for normal printing would be a fair bit of tuning work and would need to be hands-on.  If
>>>>>>>  you're interested in doing this, be prepared to put a lot of time and a fair bit of consumables
>>>>>>>  into it.
>>>>>>> 
>>>>>>>  The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
>>>>>>>  tree to see an example of what we did for the R1800 and R800, which is CMYK+red+blue (which is
>>>>>>>  actually closer to purple, but Epson calls it blue).  The most non-standard part of this is the
>>>>>>>  <Curves> section, which is a set of transfer curves for each ink channel by hue, starting with
>>>>>>>  blue=0.  I always tested these by printing a rainbow sweep pattern and trying to get as good of a
>>>>>>>  match as I could with ordinary CMY(K).
>>>>>>> 
>>>>>>>  My thought about this is that we should at least at first only support the violet ink in raw mode,
>>>>>>>  as effectively a spot color.
>>>>>>> 
>>>>>>> Your description applies to the violett channel?!
>>>>>>> Because I'm new to print driver development I'd like to start with supporting the matte black
>>>>>>> channel. At least I think it should be easier, right?
>>>>>>> What  would be your advice to start?
>>>>>> 
>>>>>> The channel ID for matte black will probably be the same as it is on every other printer that uses
>>>>>> matte black.
>> 
>> 
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 
> ________________________
> Michael Sweet
> 
> 
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li... <mailto:Gim...@li...>
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel <https://lists.sourceforge.net/lists/listinfo/gimp-print-devel>

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Michael S. <ms...@ms...>]

Robert,

> On Nov 2, 2021, at 4:04 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On 11/2/21 1:25 PM, Walker Blackwell wrote:
>> Yes, but some people's motivations are much more elaborate: aka addressing individual channels for silk screens dye ink transparency printing, monochromatic ink sets, white inks, allowing for over-inking or under-inking (uncoated papers, fabric, etc). 
> 
> Exactly, and in the context of a printer app this is why we need all of the detailed ink options:
> there are people who use them, and 32 options simply isn't enough to cover these use cases.  There's
> no way the T-shirt people could print with IPP Everywhere.

I've already explained why "32 options" isn't a limitation for PAPPL-based printer applications, and given that IPP is used for ALL kinds of printing you really can't say that one particular kind of printing can't be done - it *is* done, on a regular basis.

(and if we are being real here, most printed T-shirt stores use iron-transfer with standard inks for photos and screen printing for simpler/stock N-color designs)


> In a lot of ways, I'm more concerned with these exotic uses than with day-to-day printing,
> especially with IPP Everywhere and driverless printers.  These are niche markets, but they're
> underserved and as we're not a business we're in a good position to support these use cases.
> 
>>> On Nov 2, 2021, at 8:22 AM, Michael Sweet via Gimp-print-devel <gim...@li...> wrote:
>>> 
>>> FWIW, the P900 is an AirPrint printer, which means you should be able to use it out of the box without drivers using CUPS' IPP Everywhere support.  And it should support both sRGB and AdobeRGB like the P800...
>>> 
>>> 
>>>> On Nov 2, 2021, at 8:06 AM, Walker Blackwell <fo...@wa...> wrote:
>>>> 
>>>> I just got a P900 in-house. I gotta boot a linux machine and start cracking. . .
>>>> 
>>>> I’m going to assume the P900 requirements are pretty close to the P800 (2 picoliter SureColor head though so maybe close to P600) but won’t know for sure until I get at it.
>>>> 
>>>> Best,
>>>> Walker
>>>> 
>>>> 
>>>>> On Nov 2, 2021, at 3:00 AM, Oliver Kowalke <oli...@gm...> wrote:
>>>>> 
>>>>> I checked out the git repo (branch master) and I started reading "The Developer’s Guide to Gutenprint".
>>>>> Unfortunately I can not find the printers.xml as mentioned in the guide - instead ./src/xml/printers/escp2.xml contains the Epson models. Is this the correct file? Maybe the guide is not up-to-date?
>>>>> 
>>>>> In ./src/xml/printers/escp2.xml the SC-P700 and SC-P900 is not listed. Does this mean that both models are not supported yet or is it the wrong file?
>>>>> 
>>>>> 
>>>>> Am Mo., 1. Nov. 2021 um 23:47 Uhr schrieb Robert Krawitz <rl...@al...>:
>>>>> On 11/1/21 1:29 AM, Oliver Kowalke wrote:
>>>>>> 
>>>>>>   It should be possible to support this, other than the violet channel.  We could support the violet
>>>>>>   channel for raw printing (i. e. the user has to do the separations), but actually supporting the
>>>>>>   violet ink for normal printing would be a fair bit of tuning work and would need to be hands-on.  If
>>>>>>   you're interested in doing this, be prepared to put a lot of time and a fair bit of consumables
>>>>>>   into it.
>>>>>> 
>>>>>>   The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
>>>>>>   tree to see an example of what we did for the R1800 and R800, which is CMYK+red+blue (which is
>>>>>>   actually closer to purple, but Epson calls it blue).  The most non-standard part of this is the
>>>>>>   <Curves> section, which is a set of transfer curves for each ink channel by hue, starting with
>>>>>>   blue=0.  I always tested these by printing a rainbow sweep pattern and trying to get as good of a
>>>>>>   match as I could with ordinary CMY(K).
>>>>>> 
>>>>>>   My thought about this is that we should at least at first only support the violet ink in raw mode,
>>>>>>   as effectively a spot color.
>>>>>> 
>>>>>> Your description applies to the violett channel?!
>>>>>> Because I'm new to print driver development I'd like to start with supporting the matte black
>>>>>> channel. At least I think it should be easier, right?
>>>>>> What  would be your advice to start?
>>>>> 
>>>>> The channel ID for matte black will probably be the same as it is on every other printer that uses
>>>>> matte black.
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

________________________
Michael Sweet

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Robert K. <rl...@al...>]

On 11/2/21 1:25 PM, Walker Blackwell wrote:
> Yes, but some people's motivations are much more elaborate: aka addressing individual channels for silk screens dye ink transparency printing, monochromatic ink sets, white inks, allowing for over-inking or under-inking (uncoated papers, fabric, etc). 

Exactly, and in the context of a printer app this is why we need all of the detailed ink options:
there are people who use them, and 32 options simply isn't enough to cover these use cases.  There's
no way the T-shirt people could print with IPP Everywhere.

In a lot of ways, I'm more concerned with these exotic uses than with day-to-day printing,
especially with IPP Everywhere and driverless printers.  These are niche markets, but they're
underserved and as we're not a business we're in a good position to support these use cases.

>> On Nov 2, 2021, at 8:22 AM, Michael Sweet via Gimp-print-devel <gim...@li...> wrote:
>>
>> FWIW, the P900 is an AirPrint printer, which means you should be able to use it out of the box without drivers using CUPS' IPP Everywhere support.  And it should support both sRGB and AdobeRGB like the P800...
>>
>>
>>> On Nov 2, 2021, at 8:06 AM, Walker Blackwell <fo...@wa...> wrote:
>>>
>>> I just got a P900 in-house. I gotta boot a linux machine and start cracking. . .
>>>
>>> I’m going to assume the P900 requirements are pretty close to the P800 (2 picoliter SureColor head though so maybe close to P600) but won’t know for sure until I get at it.
>>>
>>> Best,
>>> Walker
>>>
>>>
>>>> On Nov 2, 2021, at 3:00 AM, Oliver Kowalke <oli...@gm...> wrote:
>>>>
>>>> I checked out the git repo (branch master) and I started reading "The Developer’s Guide to Gutenprint".
>>>> Unfortunately I can not find the printers.xml as mentioned in the guide - instead ./src/xml/printers/escp2.xml contains the Epson models. Is this the correct file? Maybe the guide is not up-to-date?
>>>>
>>>> In ./src/xml/printers/escp2.xml the SC-P700 and SC-P900 is not listed. Does this mean that both models are not supported yet or is it the wrong file?
>>>>
>>>>
>>>> Am Mo., 1. Nov. 2021 um 23:47 Uhr schrieb Robert Krawitz <rl...@al...>:
>>>> On 11/1/21 1:29 AM, Oliver Kowalke wrote:
>>>>>
>>>>>    It should be possible to support this, other than the violet channel.  We could support the violet
>>>>>    channel for raw printing (i. e. the user has to do the separations), but actually supporting the
>>>>>    violet ink for normal printing would be a fair bit of tuning work and would need to be hands-on.  If
>>>>>    you're interested in doing this, be prepared to put a lot of time and a fair bit of consumables
>>>>>    into it.
>>>>>
>>>>>    The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
>>>>>    tree to see an example of what we did for the R1800 and R800, which is CMYK+red+blue (which is
>>>>>    actually closer to purple, but Epson calls it blue).  The most non-standard part of this is the
>>>>>    <Curves> section, which is a set of transfer curves for each ink channel by hue, starting with
>>>>>    blue=0.  I always tested these by printing a rainbow sweep pattern and trying to get as good of a
>>>>>    match as I could with ordinary CMY(K).
>>>>>
>>>>>    My thought about this is that we should at least at first only support the violet ink in raw mode,
>>>>>    as effectively a spot color.
>>>>>
>>>>> Your description applies to the violett channel?!
>>>>> Because I'm new to print driver development I'd like to start with supporting the matte black
>>>>> channel. At least I think it should be easier, right?
>>>>> What  would be your advice to start?
>>>>
>>>> The channel ID for matte black will probably be the same as it is on every other printer that uses
>>>> matte black.

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Walker B. <fo...@wa...>]

Yes, but some people's motivations are much more elaborate: aka addressing individual channels for silk screens dye ink transparency printing, monochromatic ink sets, white inks, allowing for over-inking or under-inking (uncoated papers, fabric, etc). 

best
Walker



> On Nov 2, 2021, at 8:22 AM, Michael Sweet via Gimp-print-devel <gim...@li...> wrote:
> 
> FWIW, the P900 is an AirPrint printer, which means you should be able to use it out of the box without drivers using CUPS' IPP Everywhere support.  And it should support both sRGB and AdobeRGB like the P800...
> 
> 
>> On Nov 2, 2021, at 8:06 AM, Walker Blackwell <fo...@wa...> wrote:
>> 
>> I just got a P900 in-house. I gotta boot a linux machine and start cracking. . .
>> 
>> I’m going to assume the P900 requirements are pretty close to the P800 (2 picoliter SureColor head though so maybe close to P600) but won’t know for sure until I get at it.
>> 
>> Best,
>> Walker
>> 
>> 
>>> On Nov 2, 2021, at 3:00 AM, Oliver Kowalke <oli...@gm...> wrote:
>>> 
>>> I checked out the git repo (branch master) and I started reading "The Developer’s Guide to Gutenprint".
>>> Unfortunately I can not find the printers.xml as mentioned in the guide - instead ./src/xml/printers/escp2.xml contains the Epson models. Is this the correct file? Maybe the guide is not up-to-date?
>>> 
>>> In ./src/xml/printers/escp2.xml the SC-P700 and SC-P900 is not listed. Does this mean that both models are not supported yet or is it the wrong file?
>>> 
>>> 
>>> Am Mo., 1. Nov. 2021 um 23:47 Uhr schrieb Robert Krawitz <rl...@al...>:
>>> On 11/1/21 1:29 AM, Oliver Kowalke wrote:
>>>> 
>>>>    It should be possible to support this, other than the violet channel.  We could support the violet
>>>>    channel for raw printing (i. e. the user has to do the separations), but actually supporting the
>>>>    violet ink for normal printing would be a fair bit of tuning work and would need to be hands-on.  If
>>>>    you're interested in doing this, be prepared to put a lot of time and a fair bit of consumables
>>>>    into it.
>>>> 
>>>>    The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
>>>>    tree to see an example of what we did for the R1800 and R800, which is CMYK+red+blue (which is
>>>>    actually closer to purple, but Epson calls it blue).  The most non-standard part of this is the
>>>>    <Curves> section, which is a set of transfer curves for each ink channel by hue, starting with
>>>>    blue=0.  I always tested these by printing a rainbow sweep pattern and trying to get as good of a
>>>>    match as I could with ordinary CMY(K).
>>>> 
>>>>    My thought about this is that we should at least at first only support the violet ink in raw mode,
>>>>    as effectively a spot color.
>>>> 
>>>> Your description applies to the violett channel?!
>>>> Because I'm new to print driver development I'd like to start with supporting the matte black
>>>> channel. At least I think it should be easier, right?
>>>> What  would be your advice to start?
>>> 
>>> The channel ID for matte black will probably be the same as it is on every other printer that uses
>>> matte black.
>>> 
>>> 
>>> _______________________________________________
>>> Gimp-print-devel mailing list
>>> Gim...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>>> _______________________________________________
>>> Gimp-print-devel mailing list
>>> Gim...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>> 
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 
> ________________________
> Michael Sweet
> 
> 
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Michael S. <ms...@ms...>]

FWIW, the P900 is an AirPrint printer, which means you should be able to use it out of the box without drivers using CUPS' IPP Everywhere support.  And it should support both sRGB and AdobeRGB like the P800...


> On Nov 2, 2021, at 8:06 AM, Walker Blackwell <fo...@wa...> wrote:
> 
> I just got a P900 in-house. I gotta boot a linux machine and start cracking. . .
> 
> I’m going to assume the P900 requirements are pretty close to the P800 (2 picoliter SureColor head though so maybe close to P600) but won’t know for sure until I get at it.
> 
> Best,
> Walker
> 
> 
>> On Nov 2, 2021, at 3:00 AM, Oliver Kowalke <oli...@gm...> wrote:
>> 
>> I checked out the git repo (branch master) and I started reading "The Developer’s Guide to Gutenprint".
>> Unfortunately I can not find the printers.xml as mentioned in the guide - instead ./src/xml/printers/escp2.xml contains the Epson models. Is this the correct file? Maybe the guide is not up-to-date?
>> 
>> In ./src/xml/printers/escp2.xml the SC-P700 and SC-P900 is not listed. Does this mean that both models are not supported yet or is it the wrong file?
>> 
>> 
>> Am Mo., 1. Nov. 2021 um 23:47 Uhr schrieb Robert Krawitz <rl...@al...>:
>> On 11/1/21 1:29 AM, Oliver Kowalke wrote:
>> > 
>> >     It should be possible to support this, other than the violet channel.  We could support the violet
>> >     channel for raw printing (i. e. the user has to do the separations), but actually supporting the
>> >     violet ink for normal printing would be a fair bit of tuning work and would need to be hands-on.  If
>> >     you're interested in doing this, be prepared to put a lot of time and a fair bit of consumables
>> >     into it.
>> > 
>> >     The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
>> >     tree to see an example of what we did for the R1800 and R800, which is CMYK+red+blue (which is
>> >     actually closer to purple, but Epson calls it blue).  The most non-standard part of this is the
>> >     <Curves> section, which is a set of transfer curves for each ink channel by hue, starting with
>> >     blue=0.  I always tested these by printing a rainbow sweep pattern and trying to get as good of a
>> >     match as I could with ordinary CMY(K).
>> > 
>> >     My thought about this is that we should at least at first only support the violet ink in raw mode,
>> >     as effectively a spot color.
>> > 
>> > Your description applies to the violett channel?!
>> > Because I'm new to print driver development I'd like to start with supporting the matte black
>> > channel. At least I think it should be easier, right?
>> > What  would be your advice to start?
>> 
>> The channel ID for matte black will probably be the same as it is on every other printer that uses
>> matte black.
>> 
>> 
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

________________________
Michael Sweet

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Robert K. <rl...@al...>]

On 11/2/21 3:00 AM, Oliver Kowalke wrote:
> I checked out the git repo (branch master) and I started reading "The Developer’s Guide to Gutenprint".
> Unfortunately I can not find the printers.xml as mentioned in the guide - instead
> ./src/xml/printers/escp2.xml contains the Epson models. Is this the correct file? Maybe the guide is
> not up-to-date?

The guide is out of date.

> In ./src/xml/printers/escp2.xml the SC-P700 and SC-P900 is not listed. Does this mean that both
> models are not supported yet or is it the wrong file?

It means that they're not supported yet.

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Walker B. <fo...@wa...>]

I just got a P900 in-house. I gotta boot a linux machine and start cracking. . .

I’m going to assume the P900 requirements are pretty close to the P800 (2 picoliter SureColor head though so maybe close to P600) but won’t know for sure until I get at it.

Best,
Walker


> On Nov 2, 2021, at 3:00 AM, Oliver Kowalke <oli...@gm...> wrote:
> 
> I checked out the git repo (branch master) and I started reading "The Developer’s Guide to Gutenprint".
> Unfortunately I can not find the printers.xml as mentioned in the guide - instead ./src/xml/printers/escp2.xml contains the Epson models. Is this the correct file? Maybe the guide is not up-to-date?
> 
> In ./src/xml/printers/escp2.xml the SC-P700 and SC-P900 is not listed. Does this mean that both models are not supported yet or is it the wrong file?
> 
> 
> Am Mo., 1. Nov. 2021 um 23:47 Uhr schrieb Robert Krawitz <rl...@al... <mailto:rl...@al...>>:
> On 11/1/21 1:29 AM, Oliver Kowalke wrote:
> > 
> >     It should be possible to support this, other than the violet channel.  We could support the violet
> >     channel for raw printing (i. e. the user has to do the separations), but actually supporting the
> >     violet ink for normal printing would be a fair bit of tuning work and would need to be hands-on.  If
> >     you're interested in doing this, be prepared to put a lot of time and a fair bit of consumables
> >     into it.
> > 
> >     The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
> >     tree to see an example of what we did for the R1800 and R800, which is CMYK+red+blue (which is
> >     actually closer to purple, but Epson calls it blue).  The most non-standard part of this is the
> >     <Curves> section, which is a set of transfer curves for each ink channel by hue, starting with
> >     blue=0.  I always tested these by printing a rainbow sweep pattern and trying to get as good of a
> >     match as I could with ordinary CMY(K).
> > 
> >     My thought about this is that we should at least at first only support the violet ink in raw mode,
> >     as effectively a spot color.
> > 
> > Your description applies to the violett channel?!
> > Because I'm new to print driver development I'd like to start with supporting the matte black
> > channel. At least I think it should be easier, right?
> > What  would be your advice to start?
> 
> The channel ID for matte black will probably be the same as it is on every other printer that uses
> matte black.
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li... <mailto:Gim...@li...>
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel <https://lists.sourceforge.net/lists/listinfo/gimp-print-devel>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Oliver K. <oli...@gm...>]

I checked out the git repo (branch master) and I started reading "The
Developer’s Guide to Gutenprint".
Unfortunately I can not find the printers.xml as mentioned in the guide -
instead ./src/xml/printers/escp2.xml contains the Epson models. Is this the
correct file? Maybe the guide is not up-to-date?

In ./src/xml/printers/escp2.xml the SC-P700 and SC-P900 is not listed. Does
this mean that both models are not supported yet or is it the wrong file?


Am Mo., 1. Nov. 2021 um 23:47 Uhr schrieb Robert Krawitz <rl...@al...>:

> On 11/1/21 1:29 AM, Oliver Kowalke wrote:
> >
> >     It should be possible to support this, other than the violet
> channel.  We could support the violet
> >     channel for raw printing (i. e. the user has to do the separations),
> but actually supporting the
> >     violet ink for normal printing would be a fair bit of tuning work
> and would need to be hands-on.  If
> >     you're interested in doing this, be prepared to put a lot of time
> and a fair bit of consumables
> >     into it.
> >
> >     The first thing to do would be to look at
> src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
> >     tree to see an example of what we did for the R1800 and R800, which
> is CMYK+red+blue (which is
> >     actually closer to purple, but Epson calls it blue).  The most
> non-standard part of this is the
> >     <Curves> section, which is a set of transfer curves for each ink
> channel by hue, starting with
> >     blue=0.  I always tested these by printing a rainbow sweep pattern
> and trying to get as good of a
> >     match as I could with ordinary CMY(K).
> >
> >     My thought about this is that we should at least at first only
> support the violet ink in raw mode,
> >     as effectively a spot color.
> >
> > Your description applies to the violett channel?!
> > Because I'm new to print driver development I'd like to start with
> supporting the matte black
> > channel. At least I think it should be easier, right?
> > What  would be your advice to start?
>
> The channel ID for matte black will probably be the same as it is on every
> other printer that uses
> matte black.
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Robert K. <rl...@al...>]

On 11/1/21 1:29 AM, Oliver Kowalke wrote:
> 
>     It should be possible to support this, other than the violet channel.  We could support the violet
>     channel for raw printing (i. e. the user has to do the separations), but actually supporting the
>     violet ink for normal printing would be a fair bit of tuning work and would need to be hands-on.  If
>     you're interested in doing this, be prepared to put a lot of time and a fair bit of consumables
>     into it.
> 
>     The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
>     tree to see an example of what we did for the R1800 and R800, which is CMYK+red+blue (which is
>     actually closer to purple, but Epson calls it blue).  The most non-standard part of this is the
>     <Curves> section, which is a set of transfer curves for each ink channel by hue, starting with
>     blue=0.  I always tested these by printing a rainbow sweep pattern and trying to get as good of a
>     match as I could with ordinary CMY(K).
> 
>     My thought about this is that we should at least at first only support the violet ink in raw mode,
>     as effectively a spot color.
> 
> Your description applies to the violett channel?!
> Because I'm new to print driver development I'd like to start with supporting the matte black
> channel. At least I think it should be easier, right?
> What  would be your advice to start?

The channel ID for matte black will probably be the same as it is on every other printer that uses
matte black.

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Robert K. <rl...@al...>]

On 10/31/21 9:22 AM, Walker Blackwell wrote:
> The problem as I understand it from Roy Harrington is that ESCP/R (the protocol used to communicate with these newer printer) is a totally different and it's hard to identify channel selections (if channel selection are even a think anymore because it’s an RGB protocol apparently). But essentially you need to scrape the data from the USB communication or print-file? when you print a Photo Black glossy print and another one with Matte Black but essentially the same settings otherwise. This way it’s easier to identify any changes to the data.
> 
> I’m sure Robert can elaborate. 

ESCP/R will not help with ESC/P2.  If the driver is sending ESCP/R it isn't going to help me figure
out the code for violet.  Matte black usually has a certain code.  The good news is that there
aren't a lot of possibilities for what it can be.

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Walker B. <fo...@wa...>]

The problem as I understand it from Roy Harrington is that ESCP/R (the protocol used to communicate with these newer printer) is a totally different and it's hard to identify channel selections (if channel selection are even a think anymore because it’s an RGB protocol apparently). But essentially you need to scrape the data from the USB communication or print-file? when you print a Photo Black glossy print and another one with Matte Black but essentially the same settings otherwise. This way it’s easier to identify any changes to the data.

I’m sure Robert can elaborate. 

Best all
Walker


> On Oct 31, 2021, at 3:17 AM, Oliver Kowalke <oli...@gm...> wrote:
> 
> Hello,
> I've some background in programming and I own a P900 too - how can I support you to get the full channel support?
> 
> Oliver
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Oliver K. <oli...@gm...>]

> It should be possible to support this, other than the violet channel.  We
> could support the violet
> channel for raw printing (i. e. the user has to do the separations), but
> actually supporting the
> violet ink for normal printing would be a fair bit of tuning work and
> would need to be hands-on.  If
> you're interested in doing this, be prepared to put a lot of time and a
> fair bit of consumables into it.
>
> The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in
> the Gutenprint source
> tree to see an example of what we did for the R1800 and R800, which is
> CMYK+red+blue (which is
> actually closer to purple, but Epson calls it blue).  The most
> non-standard part of this is the
> <Curves> section, which is a set of transfer curves for each ink channel
> by hue, starting with
> blue=0.  I always tested these by printing a rainbow sweep pattern and
> trying to get as good of a
> match as I could with ordinary CMY(K).
>
> My thought about this is that we should at least at first only support the
> violet ink in raw mode,
> as effectively a spot color.
>

Your description applies to the violett channel?!
Because I'm new to print driver development I'd like to start with
supporting the matte black channel. At least I think it should be easier,
right?
What  would be your advice to start?

Oliver

Re: [Gimp-print-devel] was - P700 and P900 full channel support

[Robert K. <rl...@al...>]

On 10/31/21 3:17 AM, Oliver Kowalke wrote:
> Hello,
> I've some background in programming and I own a P900 too - how can I support you to get the full
> channel support?

It should be possible to support this, other than the violet channel.  We could support the violet
channel for raw printing (i. e. the user has to do the separations), but actually supporting the
violet ink for normal printing would be a fair bit of tuning work and would need to be hands-on.  If
you're interested in doing this, be prepared to put a lot of time and a fair bit of consumables into it.

The first thing to do would be to look at src/xml/escp2/inks/cmykrb.xml in the Gutenprint source
tree to see an example of what we did for the R1800 and R800, which is CMYK+red+blue (which is
actually closer to purple, but Epson calls it blue).  The most non-standard part of this is the
<Curves> section, which is a set of transfer curves for each ink channel by hue, starting with
blue=0.  I always tested these by printing a rainbow sweep pattern and trying to get as good of a
match as I could with ordinary CMY(K).

My thought about this is that we should at least at first only support the violet ink in raw mode,
as effectively a spot color.

[Gimp-print-devel] was - P700 and P900 full channel support

[Oliver K. <oli...@gm...>]

Hello,
I've some background in programming and I own a P900 too - how can I
support you to get the full channel support?

Oliver

Re: [Gimp-print-devel] P700 and P900 full channel support

[Robert K. <rl...@al...>]

On 10/29/21 3:37 PM, Walker Blackwell wrote:
> MK = Matte Black (sorry for the lingo).

That's interesting.  We support matte black for a lot of other printers, and the channel/subchannel
are always the same.  I'm very surprised matte black isn't working out of the box.

Violet's an interesting one.  I wonder if that really is violet, and what the use case is.  It's not
especially easy to get good results from red, orange, green, and blue (which some other printers
have).  But violet is really out of gamut for just about anything.

> We’ll get these printers in and I’ll do a parse.
> 
> best
> Walker
> 
> 
> 
>> On Oct 29, 2021, at 12:54 PM, Robert Krawitz <rl...@al...> wrote:
>>
>> On 10/25/21 9:20 AM, Walker Blackwell wrote:
>>> Hey everyone,
>>>
>>> Does anyone want to do USB scrapes and/or support work for Epson P700 and P900 printers? Current ESCP/2 channel addresses work for everything but MK and Violet. I can get my hands on these two printers I think though. I could also do the scrapes and send but I don’t have the knowledge to decipher the channels selection code myself.
>>
>> Sure, that would be great.  Unfortunately, there's not a lot I can do other than add them as a raw
>> channel.  The byte stream is sufficient; parse-escp2 will give me the channel identifiers.
>>
>> What is MK?

Re: [Gimp-print-devel] P700 and P900 full channel support

[Walker B. <fo...@wa...>]

MK = Matte Black (sorry for the lingo).

We’ll get these printers in and I’ll do a parse.

best
Walker



> On Oct 29, 2021, at 12:54 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On 10/25/21 9:20 AM, Walker Blackwell wrote:
>> Hey everyone,
>> 
>> Does anyone want to do USB scrapes and/or support work for Epson P700 and P900 printers? Current ESCP/2 channel addresses work for everything but MK and Violet. I can get my hands on these two printers I think though. I could also do the scrapes and send but I don’t have the knowledge to decipher the channels selection code myself.
> 
> Sure, that would be great.  Unfortunately, there's not a lot I can do other than add them as a raw
> channel.  The byte stream is sufficient; parse-escp2 will give me the channel identifiers.
> 
> What is MK?
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel