Add option to use "GS v 0" for ESC/POS image printing (Raw Printing)

[wahyubaskara]

When printing images with the ESCPOS language type, QZ Tray's ImageWrapper class converts the image into raw printer commands. Currently, it exclusively uses the "ESC *" (bit-image) command. This is a widely supported command, but it's not always the most efficient or capable, especially on modern printers.

Many Epson printers and compatible models also support the GS v 0 command, which can offer better performance, handle larger image data, and is often the recommended method for printing graphics. The current implementation does not allow the user to select this alternative command.

I would like to propose adding a new option to the print configuration that allows the user to specify which command QZ Tray should use for image conversion.

For example, a new option like imageCommand could be added:

qz.print(config, [
  {
    type: 'raw',
    format: 'image',
    flavor: 'file',
    data: 'https://example.com/example.png',
    options: {
      language: 'ESCPOS',
      imageCommand: 'gs_v_0', // New option
    },
  },
]);

• When imageCommand is set to 'gs_v_0', QZ Tray would generate the necessary GS v 0 (store graphics) and GS ( L (print graphics) commands.
• If the option is not provided, it would default to the current behavior, using ESC * for backward compatibility.

Adding this feature would provide developers with more control over the printer output, allowing them to leverage the best features of their specific hardware. This would lead to improved print speed and quality for supported printers, making QZ Tray even more versatile.

[lite1979]

especially on modern printers.

I have to disagree. GS v 0 is deprecated according to the epson ESC/POS guide:

https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/gs_lv_0.html

GS v 0 also does not work with the TM-U*** series, while ESC * does

Further, the "GL ( L" commands that have replaced "GS v 0" command in more recent ESC/POS programming guides clearly state that these raster graphics are stored in the printer's NV memory, which can lead to problems down the road.

From the TM-T88VII Technical Reference Guide (page 24) :

NV memory can be rewritten about 100,000 times. As a guide, NV memory rewriting should be 10
times or less a day when you program applications.

If you want to rewrite our image logic and submit a PR with this command, we can review and test the functionality, but I don't see this as a worthwhile investment of our time for the reasons stated above.

[tresf]

especially on modern printers.

I have to disagree. GS v 0 is deprecated according to the epson ESC/POS guide:

https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/gs_lv_0.html

GS v 0 also does not work with the TM-U*** series, while ESC * does

Further, the "GL ( L" commands that have replaced "GS v 0" command in more recent ESC/POS programming guides clearly state that these raster graphics are stored in the printer's NV memory, which can lead to problems down the road.

From the TM-T88VII Technical Reference Guide (page 24) :

NV memory can be rewritten about 100,000 times. As a guide, NV memory rewriting should be 10
times or less a day when you program applications.

If you want to rewrite our image logic and submit a PR with this command, we can review and test the functionality, but I don't see this as a worthwhile investment of our time for the reasons stated above.

Fantastic research @lite1979! @wahyubaskara as Lite's stated, this feature could lead to diminishing lifespan of hardware by utilizing non-volatile memory, which on other hardware is normally reserved for reusable items (such as a company logo that would be written once and fetched many times).

Since our product is open source, as Lite's suggested, we'd accept a PR which uses this technique. The code is here:

tray/src/qz/printer/action/raw/ImageWrapper.java

Line 580 in d068761

/**

[wahyubaskara]

Thanks for your detailed response and for referencing the official ESC/POS documentation. I really appreciate your time.

You're absolutely right that:

• GS v 0 is deprecated in newer Epson documentation.
• It does not work on TM-U* series impact printers.
• And that NV memory has write limitations when used for persistent image storage.

However, I’d like to clarify a potential misunderstanding regarding GS ( L and NV memory usage:

GS ( L Function 112 Does Not Use NV Memory

Function 112 (0x70) of GS ( L) is designed to print raster bit images directly from the data stream, without storing them in NV memory. The image is:

• Sent in full via RAM at print time (print buffer).
• Printed immediately.
• Not retained or stored by the printer.

Official Epson Reference:
https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/gs_lparen_cl.html
https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/gs_lparen_cl_fn112.html

This is functionally equivalent to GS v 0 (and a modern replacement), but not tied to the NV memory limitations you rightly cautioned against.

Why It Matters

It's about giving developers access to higher-performance raster printing in supported printers without:

• Storing images in NV memory,
• Resorting to ESC *, which is slow and limited,
• And without breaking compatibility with older printers, as the default behavior could still remain ESC *.

Proposed Approach

If you'd consider allowing an optional imageCommand: 'gs_l_112' configuration (or similar naming), QZ Tray could:

• Default to ESC * for compatibility.
• Allow advanced users to opt-in to GS ( L 112 for speed and quality.
• Avoid touching NV memory at all.

CMIIW. Thank you!

[tresf]

@wahyubaskara thanks for the clarification and detailed explanation. We'd be fine with either/both additions. Offering compatibility is important to the project. I'm not sure how soon @lite1979 or I will spearhead this initiative so if you're comfortable with modifying the project code (we use IntelliJ Community Edition), we'd welcome a PR or even a diff. We can help with incorporating it into our permanent API.

If you're a premium customer and you need this right away, feel free to email us support@qz.io and we can look at fast-tracking this feature.

[wahyubaskara]

Hi @tresf, i have created PR #1364 for this feature request.
Kindly review it. Thank you!