Trying to decode ESC/POS data where I have come across the GS 8 L command to send the raster data and according to the documentation the width and height should be [40x22] (which is the 14th and 16th byte of the bin file), however there are only 64 bytes of data present. Interestingly the p1 variable is 64 bytes, but I don't get why the xL, xH, yL, yH bits point to a different size.
When I try to send these bytes to the printer, I get the desired output. But when trying to parse it myself, there is insufficient image data. I'm using an Epson TM-T82x printer. Strangely though, if I modify any data in the d1..dk bits I get no output (ideally I should get some malformed output)
Here is the binary file in question - https://hexed.it#base64:t2-mod-2.bin;HThMQAAAADBwMQEBMSgAFgB4nGNgZxBgYLA/YMHAUH+ghoGhgAHIegASe8DAACOYf0AI+f8NEhACKEEKwfz/AJgAAGeMG4AdKEwCADAyHVZBAA==
I have tried to also use esc-pos tools and various other esc/pos decoding methods. All error out saying there is insufficient data. This problem only occurs when I try to print from Windows, when printing things from Linux, the output is perfectly readable.
The reason why you can't print even if you have enough length of data is because the tone parameter is an undefined value.
According to the specification page, the only possible values for the 10th byte 'a specifies the tone of the stored data.' data is 48(0x30) or 52(0x34), but 49(0x31) is specified in the data you presented.
Therefore, it is thought that it was not considered a valid ESC/POS command and was ignored.
In addition to the insufficient amount of image data, there seems to be a problem with the program that creates the ESC/POS command on Windows, so please investigate.
Taking the release of .NET 8.0 as a good opportunity, I fixed the issue where my tool was interrupting an exception in the situation in question so that it could continue processing.
It simply displays a message that the graphics data was invalid, but allows you to continue processing.