gimp-print-devel

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)

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 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] Drivers for a Cannon i9900 to use on Big Sur

[Steve L. <sle...@ya...>]

If this is an Intel Chip based Mac the current Mac version will work. If it is a Silicon based Mac, we should have a version out for you in about a week. 

You can determine which Mac you have by simply picking “About this Mac” under the Apple menu. A silicon will state it has an Apple M1 chip, Intel will state it has an Intel chip. 

Steve Letter
Sent from my Symbolics Lisp Machine using zmail. 

> On Aug 11, 2021, at 7:56 PM, Kenneth Leach via Gimp-print-devel <gim...@li...> wrote:
> 
> Hello
> 
> I recently lost the hard drive and mother board in my older Mac and replaced it with a new iMac.  The new computer uses Big Sur  and now I can’t use my Cannon i9900 printer.  On your web site it says that you might have experimental drivers for the i9900 but it doesn’t say if they might work on Big Sur.  I love that printer and am really hoping you might be able to help me out with drivers.  
> 
> Thank you.
> 
> Ken Leach.       Ken_lin_leach@q.com
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Drivers for a Cannon i9900 to use on Big Sur

[Gernot H. <aik...@gm...>]

On Thu, Aug 12, 2021 at 8:56 AM Kenneth Leach via Gimp-print-devel
<gim...@li...> wrote:
>
> Hello
>
> I recently lost the hard drive and mother board in my older Mac and replaced it with a new iMac.  The new computer uses Big Sur  and now I can’t use my Cannon i9900 printer.  On your web site it says that you might have experimental drivers for the i9900 but it doesn’t say if they might work on Big Sur.  I love that printer and am really hoping you might be able to help me out with drivers.

Hello Ken,
If gutenprint can install on your MacOSX version then the i9900 should
work as far as it is capable.
Best regards,
Gernot Hassenpflug

> Thank you.
>
> Ken Leach.       Ken_lin_leach@q.com
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel



-- 
Protea Wines Japan
Tel: 070-5550-9076
https://www.proteawines.jp

[Gimp-print-devel] Drivers for a Cannon i9900 to use on Big Sur

[Kenneth L. <ken...@me...>]

Hello

I recently lost the hard drive and mother board in my older Mac and replaced it with a new iMac.  The new computer uses Big Sur  and now I can’t use my Cannon i9900 printer.  On your web site it says that you might have experimental drivers for the i9900 but it doesn’t say if they might work on Big Sur.  I love that printer and am really hoping you might be able to help me out with drivers.  

Thank you.

Ken Leach.       Ken_lin_leach@q.com

Re: [Gimp-print-devel] RFC: hacks to get the SureLab D700 working

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

On Tue, Aug 10, 2021 at 08:30:52PM -0400, Robert Krawitz wrote:
> That's what I would do here.

Ok, it's done and pushed, including a blurb in the esc/p2 documentation 
about that ESC(g command.

All that now remains for D700 support are the WIP XML files.

Do you see any value in committing the current state of affairs or 
should I hold off until after things are tuned somewhat better?

> Don't do that without doing a full before/after comparison with every 
> printer via make checksums in src/testpattern.  It generates this 
> radically compressed output (sometimes it needs less than bits per 
> test case!) that can be compared via compare-checksums.  I don't 
> remember why I had to special case 720x360, but there was some old 
> printer that needed this.

I'd expect it to cause changes in output for many other models, so I 
didn't even consider doing that -- but what I could do is special-case 
the special-case so it only kicks in if it's not a roll-only model?

 - 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 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] RFC: hacks to get the SureLab D700 working

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

On 8/10/21 7:48 PM, Solomon Peachy wrote:
> Here are the non-XML changes sitting in my tree. The changes in 
> stpi_escp2_init_printer() need to be gated off some sort of feature 
> flag, perhaps <rollOnly/> in the model.xml file that defines a 
> MODEL_ROLL_ONLY capability bit?  Not sure what approach I should take 
> here.

That's what I would do here.

> The other change disables the special-case in 720x360 resolution so the 
> ESC(U command matches what the windows driver sends the printer, but 
> there doesn't seem to be any adverse effects to leaving it unchanged.

Don't do that without doing a full before/after comparison with every printer via make checksums in
src/testpattern.  It generates this radically compressed output (sometimes it needs less than bits
per test case!) that can be compared via compare-checksums.  I don't remember why I had to special
case 720x360, but there was some old printer that needed this.

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.

[Gimp-print-devel] RFC: hacks to get the SureLab D700 working

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

Here are the non-XML changes sitting in my tree. The changes in 
stpi_escp2_init_printer() need to be gated off some sort of feature 
flag, perhaps <rollOnly/> in the model.xml file that defines a 
MODEL_ROLL_ONLY capability bit?  Not sure what approach I should take 
here.

The other change disables the special-case in 720x360 resolution so the 
ESC(U command matches what the windows driver sends the printer, but 
there doesn't seem to be any adverse effects to leaving it unchanged.

diff --git a/src/main/escp2-driver.c b/src/main/escp2-driver.c
index 13c39e73..011a43e1 100644
--- a/src/main/escp2-driver.c
+++ b/src/main/escp2-driver.c
@@ -405,6 +405,16 @@ escp2_set_dot_size(stp_vars_t *v)
     stp_send_command(v, "\033(e", "bcc", 0, pd->drop_size);
 }
 
+static void
+escp2_set_cutter(stp_vars_t *v)
+{
+  escp2_privdata_t *pd = get_privdata(v);
+  int l = pd->page_true_height * 2880 / 72;
+  /* always 2880, independent of configured resolutions */
+
+  stp_send_command(v, "\033(g", "bl", l);
+}
+
 static void
 escp2_set_page_height(stp_vars_t *v)
 {
@@ -623,9 +633,12 @@ stpi_escp2_init_printer(stp_vars_t *v)
   escp2_set_printer_weave(v);
   escp2_set_printhead_speed(v);
   escp2_set_dot_size(v);
+  escp2_set_cutter(v);
   escp2_set_printhead_resolution(v);
+#if 0
   escp2_set_page_height(v);
   escp2_set_margins(v);
+#endif
   escp2_set_paper_dimensions(v);
 }
 
diff --git a/src/main/print-escp2.c b/src/main/print-escp2.c
index a1814eac..24463843 100644
--- a/src/main/print-escp2.c
+++ b/src/main/print-escp2.c
@@ -3889,8 +3889,10 @@ adjusted_vertical_resolution(const stp_vars_t *v, const res_t *res)
 {
   if (res->vres >= escp2_base_separation(v) * 2)
     return res->vres;
+#if 0 // XXX this causes ESC(U to differ from the Windows driver
   else if (res->hres >= escp2_base_separation(v) * 2)	/* Special case 720x360 */
     return escp2_base_separation(v) * 2;
+#endif
   else if (res->vres % 90 == 0)
     return res->vres;
   else


 - 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

[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

[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

[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

[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

[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] Need inputs on supporting Epson M200 printer

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

On 8/4/21 7:23 AM, Adhiti Sharma wrote:
> All,
> 
> Have query regarding Epson M200 printer.
> 
> My requirement is to generate prn and then send data to printer via usb for printing.
> 
> I am able to generate raster file and followed by prn file using rastertoescpx.c from cups-filter.
> 
> Further sending data via usb has no response or sometimes prints garbage chars.
> 
> I also don't see anyway to send commands to printer via command line.

Hi,

Unfortunately, we do not support this printer in Gutenprint, although it is possible that one of our
drivers (most likely the Stylus C120 driver) might work in black and white mode.

[Gimp-print-devel] request for support datamax-oneil e-4304

[Martin D. <al...@de...>]

After trying my hand at getting a new old stock datamax-oneil e-4304
direct thermal printer to work with cups and failing; are there any plans
to support this printer model in guten-print? Currently there is a driver
for Datamax-ONeil E4304B Mark III datamax_oneil_E4304B however that is much
newer and did not work. I also reviewed the honeywell docs that just say to
use ZPL emulation mode but this appears to also be for newer models. There
are still quite a few of these printers out there spitting out shipping
labels that I'm sure would appreciate some linux love.

Thank you!

[Gimp-print-devel] Need inputs on supporting Epson M200 printer

[Adhiti S. <toa...@gm...>]

All,

Have query regarding Epson M200 printer.

My requirement is to generate prn and then send data to printer via usb for
printing.

I am able to generate raster file and followed by prn file using
rastertoescpx.c from cups-filter.

Further sending data via usb has no response or sometimes prints garbage
chars.

I also don't see anyway to send commands to printer via command line.

Thanks,
Adhiti

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

[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

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