gimp-print-devel

[Gimp-print-devel] Advice on how to add the Epson SL-D700

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

I'm trying to make sense of the ESC/P2 driver xml files to add support 
for the commercially-focused SL-D700 printer.  It's roll-fed, 
1440x720dpi, 180-mozzle variable-dropsize printhead), and uses a 6-ink 
set ("Ultrachrome D6-S" CcMmYK).  According to the IEEE1284 data, it 
supports the ESCPL2, BDC, D4, and D4PX command sets.

If I understand things correctly, I will need to create a new 
model(+baseline?) xml file, which in turn will reference media, 
inputslots, qualitypresets, inkgroup, and mediasiszes xml files, along 
with a metric boatload of miscellaneous parameters.

I will be able to derive a lot of what will go into these secondary XML 
files, though a lot of additional tuning will probably be necessary, but 
when it comes to the stuff that goes into the baseline/model files, I'm 
wondering if there is a good candidate to use as a quasi-sane starting 
point.

I know I'm going to make a lot of mistakes, so any advice on how to 
minimize footgunning myself will be appreciated.

Thanks,

 - 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] Advice on how to add the Epson SL-D700

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

On 8/1/21 3:51 PM, Solomon Peachy wrote:
> I'm trying to make sense of the ESC/P2 driver xml files to add support 
> for the commercially-focused SL-D700 printer.  It's roll-fed, 
> 1440x720dpi, 180-mozzle variable-dropsize printhead), and uses a 6-ink 
> set ("Ultrachrome D6-S" CcMmYK).  According to the IEEE1284 data, it 
> supports the ESCPL2, BDC, D4, and D4PX command sets.
> 
> If I understand things correctly, I will need to create a new 
> model(+baseline?) xml file, which in turn will reference media, 
> inputslots, qualitypresets, inkgroup, and mediasiszes xml files, along 
> with a metric boatload of miscellaneous parameters.
> 
> I will be able to derive a lot of what will go into these secondary XML 
> files, though a lot of additional tuning will probably be necessary, but 
> when it comes to the stuff that goes into the baseline/model files, I'm 
> wondering if there is a good candidate to use as a quasi-sane starting 
> point.
> 
> I know I'm going to make a lot of mistakes, so any advice on how to 
> minimize footgunning myself will be appreciated.

I would start with the Expression XP-860 (model 134), L130 (model 130), or SC-P600 (model 115).
Those have the most similar head configuration and 6 (or more) color ink.  Try it at low resolution.
 Unless you have some sample output that you can parse with parse-escp2, there's going to be cutting
and trying for higher resolutions.

I know that all of the including makes things more confusing in some ways, but it also saves a lot
of duplication.

Once you find one that works, then it's a matter of tuning the drop sizes and all.  But first things
first.

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Sun, Aug 01, 2021 at 09:00:47PM -0400, Robert Krawitz wrote:
> I would start with the Expression XP-860 (model 134), L130 (model 
> 130), or SC-P600 (model 115). Those have the most similar head 
> configuration and 6 (or more) color ink.  Try it at low resolution.

Ok, will do.  (I suppose the channel/ink ordering is also anyone's 
guess, but I imagine it will be quite easy to sort out once I get this 
thing printing...)

The windows drivers don't speak of "resolutions", only "quality" -- 
fast, standard, and high, which supposedly correspond to 720x360, 
720x720, and 720x1440dpi.

There are also only three media types, glossy, matte, and lustre, though 
those come in differerent roll widths.

>  Unless you have some sample output that you can parse with 
> parse-escp2, there's going to be cutting and trying for higher 
> resolutions.

I do have sample output and parse-escp2 seems to accept it, though I still
need to make sense of it all.  :)

> I know that all of the including makes things more confusing in some 
> ways, but it also saves a lot of duplication.

Of course!  
 
> Once you find one that works, then it's a matter of tuning the drop 
> sizes and all.  But first things first.

That and the ink shades.  The smallest drop size is supposedly 2.5pl, 
and the literature mentions "up to three different drop sizes per row"
(which I'm not exactly sure how to interpret)

(Also, the head alignment adjustment goes from +-6, and the paper feed 
 alignment is +-16..)

Thanks for the advice!  I'm sure I'll come back with more questions but 
there's a lot to tackle before then.

 - 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] Advice on how to add the Epson SL-D700

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

On Mon, Aug 02, 2021 at 02:38:57PM -0400, Solomon Peachy wrote:
> I do have sample output and parse-escp2 seems to accept it, though I still
> need to make sense of it all.  :)

Ok, I've worked my way through the dumps, and I've learned a few more 
things:

ESC(D == 40 38 50 14  (== printhead res 180*720)
ESC(i == 00           (== default weave?)
ESC(S == d4 10 00 00 64 23 52 00 (== 6" width, 7480" length!)
FP 03 00  00 ec 00    (== zero margin offset of -19, or -0.75mm)

HQ mode:
 ESC(U == 02 02 01 a0 05 == 1440dpi base, 720p, 720v, 1440h
 ESC(m == 70     (PrintMethod in media tables)
 ESC(e == 00 23  (escp2_ink_type in resolutions table, == 35pl?)
Standard mode:
 ESC(U == 02 02 02 a0 05 (== 1440dpi base, 720p, 720v, 720h)
 ESC(m == 50
 ESC(e == 00 22  (== 34)
Fast mode:
 ESC(U == 04 04 02 a0 05 (== 1440dpi base, 360p, 360v, 720h)
 ESC(m == 40
 ESC(e == 00 21 (== 33)

There are no "PP", "PM", "MI", "EX", or "SN" remote commands in the 
dumps, nor anything that indicates explicit print size or cutter 
control, just the typical ESCi ESC(v, ESC($ sequences until the "JE" 
command after a form feed which I presume cuts+ejects the print.

Also, I see these in the dump, but I haven't found how to interpret yet:

   HD 03 00  00 03 02           # set driver info ?
   LB 03 00  00 01 01           # sent before FP

   1b  (  g 04 00  30 2d 00 00  # seen right before image data starts

I can insert the LB sequence into an inputslots InitSequence, but I'm 
not sure what to do about that ESC(g sequence.

 - 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] Advice on how to add the Epson SL-D700

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

On 8/2/21 7:36 PM, Solomon Peachy wrote:
> On Mon, Aug 02, 2021 at 02:38:57PM -0400, Solomon Peachy wrote:
>> I do have sample output and parse-escp2 seems to accept it, though I still
>> need to make sense of it all.  :)
> 
> Ok, I've worked my way through the dumps, and I've learned a few more 
> things:
> 
> ESC(D == 40 38 50 14  (== printhead res 180*720)
> ESC(i == 00           (== default weave?)

Usually means use softweave.  But we'll learn that from the print data command.

> ESC(S == d4 10 00 00 64 23 52 00 (== 6" width, 7480" length!)
> FP 03 00  00 ec 00    (== zero margin offset of -19, or -0.75mm)
> 
> HQ mode:
>  ESC(U == 02 02 01 a0 05 == 1440dpi base, 720p, 720v, 1440h
>  ESC(m == 70     (PrintMethod in media tables)
>  ESC(e == 00 23  (escp2_ink_type in resolutions table, == 35pl?)

The ink type is a magic number; it means "use the drop sizes corresponding to 0x23 in the printer's
firmware table".  You'll want to use these as-is.  Other settings are not likely to do anything useful.

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Mon, Aug 02, 2021 at 07:36:10PM -0400, Solomon Peachy wrote:
>  ESC(U == 02 02 01 a0 05 (== 1440dpi base, 720p, 720v, 1440h)
>  ESC(U == 02 02 02 a0 05 (== 1440dpi base, 720p, 720v, 720h)
>  ESC(U == 04 04 02 a0 05 (== 1440dpi base, 360p, 360v, 720h)

I'm trying to translate this into the <resolution> table in the 
model.xml file.

Am I correct in translating these as:

  <resolution translate="text" name="1440x720sw" text="1440 x 720">
   <physicalResolution>1440 720</physicalResolution>
   <parameter type="integer" name="escp2_base_res">720</parameter>
  </resolution>
  <resolution translate="text" name="720x720sw" text="720 x 720">
   <physicalResolution>720 720</physicalResolution>
   <parameter type="integer" name="escp2_base_res">720</parameter>
  </resolution>
  <resolution translate="text" name="720x360sw" text="720 x 360">
   <physicalResolution>720 360</physicalResolution>
   <parameter type="integer" name="escp2_base_res">360</parameter>
  </resolution>

(I only included the properties that apply to my question..)

Meanwhile, I've managed to mangle the XML files into enough semblance of 
shape that the dumps at least look sane, though there remains one major 
difference in Gutenprint's output vs what the Windows driver emits:

 Gutenprint:

   1b  (  S 08 00 e0 10 00 00 80 16 00 00 
   1b  (  C 04 00 80 16 00 00 
   1b  (  c 08 00 30 fd ff ff 5a 19 00 00 

 Windows:

   1b  (  S 08 00  d4 10 00 00 64 2e 52 00 

If I'm reading this correctly, it looks like the windows driver always 
tells the printer it has a huuuuuge paper size (6x7480") and doesn't 
set any explicit page height/margins, whereas Gutenprint does.

This is in addition to the stuff that the Windows drivers send that I'm 
still unable to interpret:

    HD 03 00 00 03 02           # set driver info, can ignore?
    LB 03 00 00 01 01           # sent before FP?

    1b  (  g 04 00 30 2d 00 00   # sent after the "print method" and "dot size" commands

I've hard-coded the LB into <preInitRemoteSequence> but that ESC(g still 
eludes explanation.

Thanks,

 - 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] Advice on how to add the Epson SL-D700

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

On 8/8/21 1:22 PM, Solomon Peachy wrote:
> On Mon, Aug 02, 2021 at 07:36:10PM -0400, Solomon Peachy wrote:
>>  ESC(U == 02 02 01 a0 05 (== 1440dpi base, 720p, 720v, 1440h)
>>  ESC(U == 02 02 02 a0 05 (== 1440dpi base, 720p, 720v, 720h)
>>  ESC(U == 04 04 02 a0 05 (== 1440dpi base, 360p, 360v, 720h)
> 
> I'm trying to translate this into the <resolution> table in the 
> model.xml file.
> 
> Am I correct in translating these as:
> 
>   <resolution translate="text" name="1440x720sw" text="1440 x 720">
>    <physicalResolution>1440 720</physicalResolution>
>    <parameter type="integer" name="escp2_base_res">720</parameter>
>   </resolution>
>   <resolution translate="text" name="720x720sw" text="720 x 720">
>    <physicalResolution>720 720</physicalResolution>
>    <parameter type="integer" name="escp2_base_res">720</parameter>
>   </resolution>
>   <resolution translate="text" name="720x360sw" text="720 x 360">
>    <physicalResolution>720 360</physicalResolution>
>    <parameter type="integer" name="escp2_base_res">360</parameter>
>   </resolution>
> 
> (I only included the properties that apply to my question..)

Yep.  Usually those resolutions are pretty sane.  It's normally 1440x1440 that has to be treated
specially.

> Meanwhile, I've managed to mangle the XML files into enough semblance of 
> shape that the dumps at least look sane, though there remains one major 
> difference in Gutenprint's output vs what the Windows driver emits:
> 
>  Gutenprint:
> 
>    1b  (  S 08 00 e0 10 00 00 80 16 00 00 
>    1b  (  C 04 00 80 16 00 00 
>    1b  (  c 08 00 30 fd ff ff 5a 19 00 00 
> 
>  Windows:
> 
>    1b  (  S 08 00  d4 10 00 00 64 2e 52 00 
> 
> If I'm reading this correctly, it looks like the windows driver always 
> tells the printer it has a huuuuuge paper size (6x7480") and doesn't 
> set any explicit page height/margins, whereas Gutenprint does.

I agree.  This is a roll feed printer, so maybe that's why this is being treated specially, and
given its purpose, it's always borderless with no margins.

> This is in addition to the stuff that the Windows drivers send that I'm 
> still unable to interpret:
> 
>     HD 03 00 00 03 02           # set driver info, can ignore?
>     LB 03 00 00 01 01           # sent before FP?

I don't remember either of these commands.

>     1b  (  g 04 00 30 2d 00 00   # sent after the "print method" and "dot size" commands
> 
> I've hard-coded the LB into <preInitRemoteSequence> but that ESC(g still 
> eludes explanation.

So let's try to decode it from the structure.  Other than ESC(U, 4-byte commands are typically two
little endian words, or maybe one little endian 4-byte words.  If we interpret this as one or two
little endian words, we get 11568 (and 0, if it's 2 words, but I suspect not).  It's also possible
that it's based on a hard base of 2880, in which case it would be 4.0167

What size are you printing in Windows?  What happens to that command as you change resolutions?

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Sun, Aug 08, 2021 at 01:22:45PM -0400, Solomon Peachy wrote:
>   <resolution translate="text" name="720x360sw" text="720 x 360">
>    <physicalResolution>720 360</physicalResolution>
>    <parameter type="integer" name="escp2_base_res">360</parameter>
>   </resolution>

FWIW, there's a special-case in adjusted_vertical_resolution() that seems to
things on this printer for 720x360.  I commented it out for now.

>     1b  (  g 04 00 30 2d 00 00   # sent after the "print method" and "dot size" commands

This turns out to be the cutter control, in units of 2880 rows/inch.  
Without it the printer cuts and stops after something like a single 
inch.

The good news is that with some hacked-in changes, I'm now able to 
print, and the color channels appear to be correct!  The bad news is 
that the ink drop/density levels are _quite_ wonky, but that was 
expected.

More seriously, there is a major page margin definition problem in play, 
and I'm not sure how to tackle it.

I think I need to add about an inch of vertical margin to start of the 
printed page, eg a 6x8" print becomes a 6x9", but with the first inch 
blank. This seems to jive with what I see in the windows dump, with the 
first vertical position command at position 1374:

   1b  (  v 04 00  5e 05 00 00   # == 1374

But from gutenprint it's this:

   1b  (  v 04 00 00 00 00 00

Interestingly, this extra inch-ish gets automatically cut off by the 
printer, and that explicit (g cutter control is relative to this first 
cut point, so as far as the user is concerned, what comes out is a 
perfect 6x8" print.

Is there a simple way to force-add this margin from within the escp2 
driver in a way that won't get reported back to the user as a page 
margin?

Thanks,

 - 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] Advice on how to add the Epson SL-D700

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

On 8/8/21 5:54 PM, Solomon Peachy wrote:
> On Sun, Aug 08, 2021 at 01:22:45PM -0400, Solomon Peachy wrote:
>>   <resolution translate="text" name="720x360sw" text="720 x 360">
>>    <physicalResolution>720 360</physicalResolution>
>>    <parameter type="integer" name="escp2_base_res">360</parameter>
>>   </resolution>
> 
> FWIW, there's a special-case in adjusted_vertical_resolution() that seems to
> things on this printer for 720x360.  I commented it out for now.

Yeah, we'll get that fixed.

>>     1b  (  g 04 00 30 2d 00 00   # sent after the "print method" and "dot size" commands
> 
> This turns out to be the cutter control, in units of 2880 rows/inch.  
> Without it the printer cuts and stops after something like a single 
> inch.

That's what I was thinking too; our emails on the subject crossed.

> The good news is that with some hacked-in changes, I'm now able to 
> print, and the color channels appear to be correct!  The bad news is 
> that the ink drop/density levels are _quite_ wonky, but that was 
> expected.

Right.  That's one of the two final problems to solve (the other being the light/dark ratios, but
there's a good chance that those will match other UltraChrome inks).

> More seriously, there is a major page margin definition problem in play, 
> and I'm not sure how to tackle it.
> 
> I think I need to add about an inch of vertical margin to start of the 
> printed page, eg a 6x8" print becomes a 6x9", but with the first inch 
> blank. This seems to jive with what I see in the windows dump, with the 
> first vertical position command at position 1374:
> 
>    1b  (  v 04 00  5e 05 00 00   # == 1374
> 
> But from gutenprint it's this:
> 
>    1b  (  v 04 00 00 00 00 00
> 
> Interestingly, this extra inch-ish gets automatically cut off by the 
> printer, and that explicit (g cutter control is relative to this first 
> cut point, so as far as the user is concerned, what comes out is a 
> perfect 6x8" print.

More like 0.954166, presumably expressed in base units.

> Is there a simple way to force-add this margin from within the escp2 
> driver in a way that won't get reported back to the user as a page 
> margin?

initialVerticalOffset and blackInitialVerticalOffset may be what you want (you'll need to set both
in the model file).  They're expressed in units of baseSeparation, which is 360; 1374 would be
343.5, so you'd have to use either 343 or 344 for this purpose.  If that's not good enough -- if you
really need it more precise -- we'll have to come up with something else.

This was designed for a different purpose, printers with offset heads, where the offset is negative;
I've never tried it with a positive offset.

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Sun, Aug 08, 2021 at 07:03:33PM -0400, Robert Krawitz wrote:
> initialVerticalOffset and blackInitialVerticalOffset may be what you 
> want (you'll need to set both in the model file).  They're expressed 
> in units of baseSeparation, which is 360; 1374 would be 343.5, so 
> you'd have to use either 343 or 344 for this purpose.  If that's not 
> good enough -- if you really need it more precise -- we'll have to 
> come up with something else.

Hmm, initialVerticalOffset seems to only be used as an input to ESC(c, 
which I'd commented out.  Re-enabling it and plugging both positive and 
negative numbers in seems to have no effect on the printer behavior:

   1b  (  c 08 00 82 fa ff ff 5a 19 00 00
   1b  (  c 08 00 18 01 00 00 5a 19 00 00 

So that's not going to work.  However, I discovered what we really want 
is pd->printing_initial_vertical_offset, but there is no way to set it 
via XML and it is currently hardcoded to 0.  Force-setting that to an 
appropriate value works great, so I added the code to read it from the 
model XML.

Since that value needs to be specified in terms of base_res * 2, which 
varies based on the print resolution. it either needs to be specified in 
resolution-independent units (and get converted) or has to be pushed 
made into a <resolution> parameter.  Which is your preference?

BTW, I don't get the results I want until I push the offset out slightly 
over an inch.  Chalk it all up to margin differences with the Windows 
driver.

So, the hacks I still have in my code:

 * Always bypass sending ESC(c and ESC(C
 * Always send ESC(g based on paper height
 * Disable the special case for 720x360 in adjusted_vertical_resolution()

I think the prudent thing to do is add some sort of model flag that says 
a model is roll-only, and those first two things can key off of that?
 
I suspect we'll need something similar for print size 
selection/filtering; this model is most commonly used to produce 
standard photo sizes (eg 5x7, 6x8, 8x10) but thanks to the roll-only 
media even under Windows it supports arbitrary print lengths.

 - 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] Advice on how to add the Epson SL-D700

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

On Sun, Aug 08, 2021 at 09:49:03PM -0400, Solomon Peachy wrote:
> Since that value needs to be specified in terms of base_res * 2, which 
> varies based on the print resolution. it either needs to be specified in 
> resolution-independent units (and get converted) or has to be pushed 
> made into a <resolution> parameter.  Which is your preference?

I have it currently specified in units of base_separation (ie 360).  All 
resolutions now function properly, so I've moved on to trying to tune 
this thing a bit better, but there are a lot of knobs:

 * Inks:  relative intensity of sub-channels
 * Model: density & dropsizes (per-resolution)
 * Media: density, subchannelcutoff, YMCbalance, gamma, Ktrans/GCR, HSV maps
 * External: ICC profile

If I understand correctly, the drop sizes are specified relative to 
"largest possible" so presumably one would tune the overall 
model/resolution density until the media is sufficient saturated, and 
from there tune each successively smaller drop size until the output is 
sane. From there you'd add in the subchannels (eg light C/M in this 
case) and adjust their relative intensity until things look right.

Then you'd fine-tune the different media types for color balance, 
relative density, and whatnot. Subchannelcutoff and gamma being the most 
interesting.

Is all of this ultimately a matter of (systematic) trial and error?
Am I on the right track here?

Lacking any better idea, flipped a coin and used the pro_ultrachrome.xml 
CcMmYK ink and pro_ultrachrome.xml media definitions as a starting point 
(which IIUC are printhead-independent) Should I have used 
f360_ultrachrome.xml (or one of the many ultrachrome_* variants) instead? 

(I noticed that the pro_* stuff seems to have a 1.0 gamma where the 
 f360_* stuff seems to have a 0.92 gamma..)

For the resolution-specific density/dropsizes, I started with the 
pro_x600 baseline which turned out to be quite wrong but I guess I had 
to start somewhere...

 - 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] Advice on how to add the Epson SL-D700

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

On 8/10/21 3:28 PM, Solomon Peachy wrote:
> On Sun, Aug 08, 2021 at 09:49:03PM -0400, Solomon Peachy wrote:
>> Since that value needs to be specified in terms of base_res * 2, which 
>> varies based on the print resolution. it either needs to be specified in 
>> resolution-independent units (and get converted) or has to be pushed 
>> made into a <resolution> parameter.  Which is your preference?
> 
> I have it currently specified in units of base_separation (ie 360).  All 
> resolutions now function properly, so I've moved on to trying to tune 
> this thing a bit better, but there are a lot of knobs:

You might instead want to specify it in terms of the base unit (14400 on most printers)

>  * Inks:  relative intensity of sub-channels
>  * Model: density & dropsizes (per-resolution)
>  * Media: density, subchannelcutoff, YMCbalance, gamma, Ktrans/GCR, HSV maps
>  * External: ICC profile
> 
> If I understand correctly, the drop sizes are specified relative to 
> "largest possible" so presumably one would tune the overall 
> model/resolution density until the media is sufficient saturated, and 
> from there tune each successively smaller drop size until the output is 
> sane. From there you'd add in the subchannels (eg light C/M in this 
> case) and adjust their relative intensity until things look right.

When you tune drop sizes, you don't want to tune them at anywhere near saturation, because
overlapping dots result in non-linear response.  I usually tune them somewhere around 25% IIRC.  For
light inks, it's very important not to be saturated.  You might want to tune those at the smallest
possible drop size so you have the least speckling.

> Then you'd fine-tune the different media types for color balance, 
> relative density, and whatnot. Subchannelcutoff and gamma being the most 
> interesting.

Yep.

> Is all of this ultimately a matter of (systematic) trial and error?
> Am I on the right track here?

That's how I've always done it.

> Lacking any better idea, flipped a coin and used the pro_ultrachrome.xml 
> CcMmYK ink and pro_ultrachrome.xml media definitions as a starting point 
> (which IIUC are printhead-independent) Should I have used 
> f360_ultrachrome.xml (or one of the many ultrachrome_* variants) instead? 

The f360 inks are for printers that use 1/180" spacing, but half of the inks are offset 1/360" from
the others.  For the tuning, it doesn't matter, but don't use the f360 unless you determine that
that printer has that offset.  I would start with one of the ultrachrome ones.

> (I noticed that the pro_* stuff seems to have a 1.0 gamma where the 
>  f360_* stuff seems to have a 0.92 gamma..)

Not sure why, to be honest.

> For the resolution-specific density/dropsizes, I started with the 
> pro_x600 baseline which turned out to be quite wrong but I guess I had 
> to start somewhere...

I wish I could say I have a more scientific procedure, but not really.

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Tue, Aug 10, 2021 at 08:23:20PM -0400, Robert Krawitz wrote:
> You might instead want to specify it in terms of the base unit (14400 on most printers)

That would be 'resolutionScale' in the model.xml file?

FWIW I went with baseSeparation units because initialVerticalOffset and 
blackVerticalOffset were already in baseSeparation units.

> When you tune drop sizes, you don't want to tune them at anywhere near saturation, because
> overlapping dots result in non-linear response.  I usually tune them somewhere around 25% IIRC.  For

Yeah, I'd managed to dial it back to where pure CYMK colors looked 
pretty good but when two inks had to mix (especially Y+C=G) it was 
actually puddling on the paper..

> light inks, it's very important not to be saturated.  You might want 
> to tune those at the smallest possible drop size so you have the least 
> speckling.

Any advice on how to deliberately generate the smallest drop sizes?

> I wish I could say I have a more scientific procedure, but not really.

Ok, glad to hear I'm not making this unnecessary complicated for myself.

Thanks!

 - 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] Advice on how to add the Epson SL-D700

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

On 8/10/21 8:43 PM, Solomon Peachy wrote:
> On Tue, Aug 10, 2021 at 08:23:20PM -0400, Robert Krawitz wrote:
>> You might instead want to specify it in terms of the base unit (14400 on most printers)
> 
> That would be 'resolutionScale' in the model.xml file?
> 
> FWIW I went with baseSeparation units because initialVerticalOffset and 
> blackVerticalOffset were already in baseSeparation units.

That makes sense.

>> When you tune drop sizes, you don't want to tune them at anywhere near saturation, because
>> overlapping dots result in non-linear response.  I usually tune them somewhere around 25% IIRC.  For
> 
> Yeah, I'd managed to dial it back to where pure CYMK colors looked 
> pretty good but when two inks had to mix (especially Y+C=G) it was 
> actually puddling on the paper..

Yep, you're going to need to back off from there.

>> light inks, it's very important not to be saturated.  You might want 
>> to tune those at the smallest possible drop size so you have the least 
>> speckling.
> 
> Any advice on how to deliberately generate the smallest drop sizes?

Modify (temporarily) the drop sizes to only include the smallest size.

>> I wish I could say I have a more scientific procedure, but not really.
> 
> Ok, glad to hear I'm not making this unnecessary complicated for myself.

I probably should have tried to make it easier.

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Mon, Aug 02, 2021 at 07:36:10PM -0400, Solomon Peachy wrote:
>    LB 03 00  00 01 01           # sent before FP

It turns out this changes based on the media type.

 Glossy: 00 01 00
 Luster: 00 01 01
 Matte:  00 01 32

I currently have this specified in the model.xml's preInitRemoteSequence 
but that obviously won't do. 

I've been trying to add it as a parameter from within a <paper> definition:

   <parameter type="raw" name="escp2_preinit_remote_sequence">LB\003\000\000\001\001</parameter>

But it seems pd->preinit_remote_sequence is set in setup_basic(), far 
before the paper definition is parsed. I added a hack in 
adjust_density_and_ink_type() to explicitly check for that parameter:

  if (pv && stp_check_raw_parameter(pv, "escp2_preinit_remote_sequence", STP_PARAMETER_ACTIVE))
    pd->preinit_remote_sequence = escp2_preinit_remote_sequence(pv);

but that's a pretty ugly hack IMO. It perhaps makes more sense to add a 
generic LB command send into escp2_set_remote_sequence() and create a 
parameter to configure it.  But what should I call it?

 - 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] Advice on how to add the Epson SL-D700

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

On 8/15/21 8:58 PM, Solomon Peachy wrote:
> On Mon, Aug 02, 2021 at 07:36:10PM -0400, Solomon Peachy wrote:
>>    LB 03 00  00 01 01           # sent before FP
> 
> It turns out this changes based on the media type.
> 
>  Glossy: 00 01 00
>  Luster: 00 01 01
>  Matte:  00 01 32
> 
> I currently have this specified in the model.xml's preInitRemoteSequence 
> but that obviously won't do. 
> 
> I've been trying to add it as a parameter from within a <paper> definition:
> 
>    <parameter type="raw" name="escp2_preinit_remote_sequence">LB\003\000\000\001\001</parameter>
> 
> But it seems pd->preinit_remote_sequence is set in setup_basic(), far 
> before the paper definition is parsed. I added a hack in 
> adjust_density_and_ink_type() to explicitly check for that parameter:
> 
>   if (pv && stp_check_raw_parameter(pv, "escp2_preinit_remote_sequence", STP_PARAMETER_ACTIVE))
>     pd->preinit_remote_sequence = escp2_preinit_remote_sequence(pv);
> 
> but that's a pretty ugly hack IMO. It perhaps makes more sense to add a 
> generic LB command send into escp2_set_remote_sequence() and create a 
> parameter to configure it.  But what should I call it?

Device Drivers Are Ugly (tm)

There are already a bunch of special cases for papers starting at line 289 of print-escp2-data.c.
On the one hand, I hate adding yet one more.  On the other, I don't really want to restructure the
XML data for every existing printer and paper, and it would be a lot of work to rework all of the
existing PaperThickness/FeedSequence/PlatenGap options (there are 566 as it stands), and converting
them to fixed remote mode strings would reduce flexibility for people who want to tune them for
funky media of their own.

As ugly as it is, I'd say either come up with a new integer parameter for this or add an escape
hatch remote sequence per-paper that you can set for the papers for this printer.

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Sun, Aug 15, 2021 at 09:31:46PM -0400, Robert Krawitz wrote:
> Device Drivers Are Ugly (tm)

That's practically the caption of my career.  :D

> As ugly as it is, I'd say either come up with a new integer parameter 
> for this or add an escape hatch remote sequence per-paper that you can 
> set for the papers for this printer.

I ended up doing the former.  Lacking a better name I just defined it as 
an internal parameter:

  PARAMETER_INT(roll_lb)

Which is only referenced in escp2_set_remote_sequence():

      if (stp_check_int_parameter(pv, "escp2_roll_lb", STP_PARAMETER_ACTIVE))
       stp_send_command(v, "LB", "bccc", 0, 1,
                        stp_get_int_parameter(pv, "escp2_roll_lb"));

And in the paper definition:

  <parameter type="integer" name="escp2_roll_lb">0x32</parameter>

It seems to work okay.

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