A few months back I wrote an article aptly titled Epson: A horror story and today, after all this time, there was finally a breakthrough (granted there’s been a few months of ignoring the problem in resignation in between).
Not that it’s not a horror story still, a month ago I was informed that my issue had been elevated to level 2 support…yesterday I emailed them informing them I’d not heard for Level 2 yet, and got a fun little response; My concerns over not hearing from level 2 had been elevated to level 2…
Any way, since others may stumble upon the same issues as me, I’ll outline the problem, what caused the confusion and problems, and the solution to the nightmare (which is so simple I should feel ashamed for not having thought of trying it).

The problem

I needed to print out logos on our POS (Point of Sale) thermal printers, we’ve tried a few of them, Epson so far had the best interface for configuring them, and everything in general just seemed a lot cleaner up until the image part.
I opted to use an NV image for my logos (images are stored to the internal memory of the printer it self, making for faster prints, and allowing me to provide multiple images if I so desired), this provides you with a key code, the default being two consecutive spaces.

The confusion

The programmers documentation form Epson (which they couldn’t help me interpret I might add…horror!) has the following entry for printing data from the NV memory;

The main confusion here was caused by the format line, I worked off the Decimal line, converting each entry to their ASCII value using PHPs chr() function,
kc1 and kc2 represent KeyCode1 and Keycode2 for the NV image (the two spaces), since it had the same word on each line, I expected the value provided belonging to the ASCII line, and I would then provide the Decimal of this, I thus interpreted the above as follows;
29 40 76 6 0 48 69 32 32 49 49

This was my mistake.

The solution

After a lot of back and forth, I was trying to describe my approach, and the documentation to people in multiple channels on IRC getting all the help I could to crack this nut, and in doing so I confused many many users.
That’s good though, because the outside perspectives they provided showed me what I was doing wrong, and where the documentation fails on a high grade in my opinion.
Turns out the x and y values are both provided in Decimal format, where as the debug output form the printer shows the keycodes in ASCII I made the presumption that that’s what I could be fed with (especially since they provide both hex and decimal values, it makes little sense to then further down only provide a decimal value).
The CORRECT representation of the above should thus be
29 40 76 6 0 48 69 32 32 1 1
That I had not even thought to try this before baffles me…I tried many variations with the decimal string above, but never ever thought to try providing the x and y values in that manner.
 
 
I’ll be over there, in the corner…