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?