Description
The last four bytes of the IMAGE_SUPPORT_INFO struct seem to contain the maximum image size that the printer will support. On my Link Wide, it's 0x52800 = 337920 = 330 * 1024:
-> b'Ab\x00\x08\x00\x02\x00R'
<- b'aB\x00\x13\x00\x02\x00\x00\x04\xec\x03H\x02{\x00\x05(\x00b'
EventType.SUPPORT_FUNCTION_INFO 000004ec0348027b00052800
I can confirm that this is in fact the max supported image size by experimenting with PRINT_IMAGE_DOWNLOAD_START. If you give it a valid image size, it responds with the printer's desired chunk size, but if you give it a size that's too big, it seems to respond with 0x81:
337919
-> b"Ab\x00\x0f\x10\x00\x02\x00\x00\x00\x00\x05'\xff\x10"
<- b'aB\x00\x0c\x10\x00\x00\x00\x00\x03\x84\xb9'
EventType.PRINT_IMAGE_DOWNLOAD_START 0000000384
337920
-> b'Ab\x00\x0f\x10\x00\x02\x00\x00\x00\x00\x05(\x00\x0e'
<- b'aB\x00\x0c\x10\x00\x00\x00\x00\x03\x84\xb9'
EventType.PRINT_IMAGE_DOWNLOAD_START 0000000384
337921
-> b'Ab\x00\x0f\x10\x00\x02\x00\x00\x00\x00\x05(\x01\r'
<- b'aB\x00\x08\x10\x00\x81\xc3'
EventType.PRINT_IMAGE_DOWNLOAD_START 81
This is 3x higher than the currently hardcoded value of 105kb and can allow for significantly higher quality.
Also, I think there's a bug in pil_image_to_bytes: img_buffer is never cleared between calls to save_img_with_quality, so it never actually shrinks in size. If you call save_img_with_quality(80), then save_img_with_quality(50), you will get a buffer that has the same length as the quality-80 JPEG but contains the quality-50 JPEG followed by leftover trailing bytes from the quality-80 one. Because print_image then does len(imgData), it will get an invalid value, and printing might fail if the buffer was too long on any iteration of the binary search.