gimp-print-devel

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.

[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] raster imaging processor

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

On 7/22/21 3:20 PM, a_v...@nx... wrote:
> good gay!
> I'm interesting you soft. Can you help me? My image sources (png and pdf) have got some pages (from
> 1 to 30 pages). Why I can modify your soft, that's I can printing automatic some pages. Thank you!
> Best regards, Belousov Alexander. Saint-Petersburg, Russia.

Hi,

I'm afraid I don't understand your question.  Gutenprint is not by itself a RIP; it's simply the
drivers required for the printer to print.

[Gimp-print-devel] raster imaging processor

[<a_v...@nx...>]

<div>good gay!</div><div>I'm interesting you soft. Can you help me? My image sources (png and pdf) have got some pages (from 1 to 30 pages). Why I can modify your soft, that's I can printing automatic some pages. Thank you!</div><div>Best regards, Belousov Alexander. Saint-Petersburg, Russia.</div><div>Tel.: +7-921-758-64-39</div><div> </div>

[Gimp-print-devel] Thank you

[Feroz M. <fme...@an...>]

Just used your driver for my Samsung printer - it worked really well - thank you - Feroz

Feroz Merchant
The Merchant Law Firm, P.C.
440 Louisiana Street, Suite 200
Houston, Texas 77002

(713) 224-8200
(713) 481-1729 (fax)
fme...@an...

PRIVILEGED AND CONFIDENTIAL - - NOTICE; The Electronic Communications Privacy Act, 19 USC §§ 2510 et seq., protects this transmission, which is intended only for the use of the individual or entity to which it is addressed. This transmission may contain information that is (1) attorney-client privileged, (2) attorney work-product, (3) confidential, and (4) exempt from disclosure under applicable law. If the reader of this message is not the addressee or agent responsible for delivering this transmission to the addressee, you are hereby notified that any dissemination, distribution or copying of this transmission is strictly prohibited. If you received this transmission in error, please immediately notify the sender by return email or by telephone. Thank you
 

[Gimp-print-devel] checking in:

[Olha K. <moy...@ho...>]

Hi

Please let me know when you get this?

I hope you are staying indoors today; I'd like to ask you for a favor.

Stay safe.

Thanks,
Olha

Re: [Gimp-print-devel] Regarding building and usage of Gimp-print and Android

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

On 7/14/21 3:38 AM, Adhiti Sharma wrote:
> Hi Gimp team,
> 
> I am trying to support USB printing on Android. Need info on below items to proceed further.
> 
> 1> Steps to build Gutenprint source for Android (I am using Android 10).
> 2> Further I need to integrate as part of the NDK app and use it. Regarding this, I would like to
> know if there is a developer guide that I could follow.

Hi,

In response to your questions:

1) We don't have any Android support in Gutenprint.  It might be possible to port; I don't know
whether anyone has done it and I personally have no Android experience.

2) The same applies to the NDK.  In addition, be aware that if you want to redistribute the result,
you may only do so under the terms of the GPL(v2 or later).  If you intend to use this only
personally without redistribution there are no restrictions.  You will need to make that
determination; I can't give you any legal advice beyond what I said, as I'm not a lawyer.

Re: [Gimp-print-devel] [5.3.4] Fixes for XML files

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

On Thu, Jul 15, 2021 at 03:09:15PM +0200, Zdenek Dohnal wrote:
> we ran XML linter as a part of rpminspect project[1] on any package
> containing XML files during CentOS Stream development and found out the
> linter reports errors (attached file 'errors') for several XML files in
> Gutenprint 5.3.4.
>
> Would you mind applying the patch to the project?

It's applied!  Thank you for the cleanup!

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

[Gimp-print-devel] [5.3.4] Fixes for XML files

[Zdenek D. <zd...@re...>]

Hi,

we ran XML linter as a part of rpminspect project[1] on any package 
containing XML files during CentOS Stream development and found out the 
linter reports errors (attached file 'errors') for several XML files in 
Gutenprint 5.3.4.

The attached patch applies cleanly on current GIT master of gutenprint 
and linter in rpminspect doesn't report errors for XML files anymore.

Would you mind applying the patch to the project?

Thank you in advance!


Zdenek


[1] https://github.com/rpminspect/rpminspect

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C