New device Dapper-Geyi Q583P

[globalcitizen]

Device is a Dapper-Geyi Q583P embedded 58mm thermal printer, newly obtained direct from the manufacturer in kit form.

I am accessing it over Linux's USB line printer driver, which recognizes the device ID (0fe6:811e) automatically.

Demo displays nothing, but scrolls and partially cuts paper many times.

However, if I execute...

# echo "message" >>/dev/usb/lp1

... then printing occurs fine.

The manufacturer verified that the model in question supports both partial and full cut.

I strongly suspect the firmware on this printer requires initialization that was not executed. Perhaps character set or DPI selection? Unfortunately the only documentation for the device is in Chinese.

I have tried to translate roughly, results as follows:

Commands

Print movements

No.	Code	Meaning
01	LF	New line
02	CR	Carriage return
03	HT	Next tab position
04	ESC D n	Configure level position
05	ESC J n	Print and feed paper
06	ESC d n	Print buffer and feed 'n' lines
07	ESC = n	Configure peripherals

Formatting commands

No.	Code	Meaning
08	ESC 2	Set default linespacing (32pt)
09	ESC 3 n	Set linespacing to 'n' dot rows
10	ESC a n	Set justification (left/center/right)
11	ESC SO n	Set width mode
12	ESC DC4 n	Cancel override mode
13	GS L nL nH	Set left-side indentation (points)
14	ESC $ nL nH	Set absolute print position
15	ESC B n	Set left margin

General commands

No.	Code	Meaning
16	ESC ! n	Select print mode
17	GS ! n	Set font size
18	GS B n	Set/cancel anti-white print mode
19	ESC V n	Set/cancel 90° rotated print mode
20	ESC v n	Status report
21	ESC G n	Cancel/set overlap mode
22	ESC E n	Set/cancel bold font
23	ESC SP n	Set the right character spacing
24	ESC { n	Set/cancel upside down characters
25	ESC - n	Set underline position
26	ESC % n	Set/cancel user-defined character set
27	FS &	Set Chinese mode
28	FS .	Cancel Chinese mode
29	FS ！n	Set Chinese character print mode
30	ESC &	Set user-defined characters
31	ESC ? n	Cancel user-defined characters
32	ESC R n	Select international character set
33	ESC t n	Select character code table

Graphic settings command

No.	Code	Meaning
34	ESC *	Graphic vertical mode data is filled
35	GS *	Down bit pattern
36	GS / m	Print down bitmap
37	GS v	Picture Horizontal Mode Data Print
38	FS p n m	Print the NV bitmap
39	FS q n	Define the NV bitmap

Initialization command

No.	Code	Meaning
40	ESC @	Initialize

Status commands

No.	Code	Meaning
41	GS r n	Transmission status
42	GS a n	Allow/disable status auto-reporting

Barcode setup commands

No.	Code	Meaning
43	GS H n	Set print position for HRI character
44	GS h n	Set barcode height
45	GS w n	Set barcode width
46	GS k	Print barcode
47	GS x n	Set barcode left margin

Two-dimensional code commands

No.	Code	Meaning
48	GS ( k pL pH cn fn n1 n2 (fn=65)	The pattern of the QR code is specified by n1
49	GS ( k pL pH cn fn n (fn=67)	Set QR code type
50	GS ( k pL pH cn fn n (fn=69)	Set QR code error correction level
51	GS ( k pL pH cn fn m d1…dk (fn=80)	Store QR code data in 2D bar code area
52	GS ( k pL pH cn fn m (fn=82)	Store QR code data in 2D bar code area

Auxiliary function commands

No.	Code	Meaning
53	ESC 7 n1 n2 n3	Set print density (dpi or resolution)
54	ESC 9 n	Choose Chinese codepage
55	DC2 T	Print self test page
56	ESC c 5 n	Cancel / Activate panel button (button only)

Additional commands

No.	Code	Meaning
57	DLE EOT n	Real-time delivery status

Special commands (sourced from a different document)

No.	Code	Meaning
01	GS ( k pL pH cn fn m (fn=81)	Print QR code
02	GS k m v r nL nH d1…dk	Print 2D Code
03	GS v m / GS v m n	Select the cut mode and cut the paper
04	ESC i	Full paper cut
05	ESC m	Half paper cut
06	ESC B n	Set black mark to detect maximum length
07	GS FF	Enter black paper and print start position
08	ESC 8 n1 n2	Set sleep parameters
09	ESC p m t1 t2	Produce money box (till) pulse
10	DLE ENQ n	(new) Printer sale-time request
11	GS a n	(new) Allow/disable auto state reply (ASB)
12	GS ‘ n x1sL x1eH x1eL x1eH ...	Horizontal Line Segment (Curve Print Order)

[globalcitizen]

I have just verified that a full cut works with:

# cat >>/dev/usb/lp1
^[i

Where ^[ is the result of pressing the escape key, and i was pressed immediately thereafter (no space), followed by the enter key.

This is despite the fact that no full cut was observed during the demo output's execution.

Apparently in Printer.php you currently have the following code for full cut support:

    /**
     * Cut the paper.
     *
     * @param int $mode Cut mode, either Printer::CUT_FULL or Printer::CUT_PARTIAL. If not specified, `Printer::CUT_FULL` will be used.
     * @param int $lines Number of lines to feed
     */
    public function cut($mode = Printer::CUT_FULL, $lines = 3)
    {
        // TODO validation on cut() inputs
        $this -> connector -> write(self::GS . "V" . chr($mode) . chr($lines));
    }

This certainly looks like quite a different command because it has the second argument for lines.

Referring to the apparently official Epson ESC POS documentation it seems like this manufacturer's firmware is for some reason using an obsolete command that means "cut leaving one typographic point worth of paper connected" to mean "totally cut".

[globalcitizen]

Codepages documented in vendor documentation for this device, converted by me to your JSON format and using iconv identifiers except where noted...

                "0":"CP437",
                "1": "CP932",
                "2": "CP850",
                "3": "CP860",
                "4": "CP863",
                "5": "CP865",
                "6": "CP1251",
                "7": "CP866",
                "8": "MIK",
                "9": "CP755",
                "10": "IRAN-SYSTEM-ENCODING",
                "15": "CP862",
                "16": "CP1252",
                "17": "WINDOWS-1253",
                "18": "CP852",
                "19": "CP858",
                "20": "IRAN-SYSTEM-ENCODING",
                "21": "UNKNOWN-LATVIAN-ENCODING",
                "22": "CP864",
                "23": "ISO-8859-1",
                "24": "CP737",
                "25": "WINDOWS-1257",
                "26": "TIS620",
                "27": "CP720",
                "28": "CP855",
                "29": "CP857",
                "30": "WINDOWS-1250",
                "31": "CP775",
                "32": "WINDOWS-1254",
                "33": "WINDOWS-1255",
                "34": "WINDOWS-1256",
                "35": "WINDOWS-1258",
                "36": "ISO-8859-2",
                "37": "ISO-8859-3",
                "38": "ISO-8859-4",
                "39": "ISO-8859-5",
                "40": "ISO-8859-6",
                "41": "ISO-8859-7",
                "42": "ISO-8859-8",
                "43": "ISO-8859-9",
                "44": "ISO-8859-15",
                "45": "TIS620",
                "46": "CP856",
                "47": "CP874"

Notes:

• For 8 the value MIK is supported by some versions of iconv only.
• For 9 the value CP755 is correct according to vendor documentation, but your default was 766. Perhaps there is a vendor typo. Hard to tell from online sources. The codepage presented in vendor documentation is as follows.
• I cannot find a correct iconv name, if any does indeed exist, for what appears to be Iran System Encoding that is referred to by codepages 10 ("IRAN" in vendor documentation) and 20 ("IRAN II" in vendor documentation). I have therefore set both to "IRAN-SYSTEM-ENCODING" as a placeholder, though they will probably cause errors if used.
• I cannot identify the codepage 21 described as "Latvian" in vendor documentation so have labelled it as UNKNOWN-LATVIAN-ENCODING.
• For 21, the documentation simply says "Thai", and for 45 "Thai2". Both are presented without codepoint references in a style suggesting a highly obtuse origin. Based upon the iconv character set identifiers listed below I believe perhaps one is THAI8 instead of TIS620, however the latter is far more common so I have associated both with that codepage with the hope that at least one should therefore work 'out of the box'.

HP-THAI8
HPTHAI8
THAI8
TIS-620
TIS620-0
TIS620.2529-1
TIS620.2533-0
TIS620

[globalcitizen]

Egad. Printing was broken because the paper was upside down 👍 Classic. Being an industrial (embedded) model it does not have a spool mount connected, so the relationship between printer and paper in terms of vertical is unclear.

Anyway, it works now, I have run a full test output.

Results as follows...

Hello world

/* Text */
$printer -> text("Hello world\n");
$printer -> cut();

/* Line feeds */
$printer -> text("ABC");
$printer -> feed(7);
$printer -> text("DEF");
$printer -> feedReverse(3);
$printer -> text("GHI");
$printer -> feed();
$printer -> cut();

Resulted in paper that looked like:

Hello world

BC




------------- partial cut here ------------
DEFHI

Font modes

The font mode tests began immediately a couple of lines down from the DEFHI at the end of the hello world tests. No cut was present at all within these tests. After the tests, the phrase artial cut was printed ... suggesting the cut command being sent to the printer is stalling for an additional character as an argument on this firmware, and therefore perhaps eating the first character of the next input?

Cuts

All cuts where present were partial. Cuts frequently overlapped just printed content (eg. cut the bottom of the barcode off), ie. this code did not feed far enough:

/* Barcodes - see barcode.php for more detail */
$printer -> setBarcodeHeight(80);
$printer->setBarcodeTextPosition(Printer::BARCODE_TEXT_BELOW);
$printer -> barcode("9876");
$printer -> feed();
$printer -> cut();

Graphic

Did not work apparently, resulted in lots of garbage being printed.

Bit image

Worked but partly out of bounds on the paper (58mm).

First image was too wide - only the following was visible:

+---------
| escpos-
+--------- 

Second image was fully visible and about 75% width.

Third image was exactly as per the first image but about double height, though its bottom was cut off apparently due to the same insufficient feed before cut problem.

QR codes

All three QR codes printed successfully, though all three were at micro size.

[globalcitizen]

After running the separate qr-code.php example, all of the examples work including larger-sized QR codes via pixel size specification, QR codes using different encodings, and centering. The only thing that doesn't print as apparently expected is the same test as the normal demo, ie. type 1, type 2 and micro all print at the same tiny size.

[globalcitizen]

It looks like reverse-feed is not supported by this printer.

[globalcitizen]

In summary to properly support this printer:

• Alternate full cut command (ESC i) should be implemented
• A "how much extra feed to execute before a cut" setting should be possible to associate with a device
• A "reverse feed supported" capability should be defined
• Rotated printing (ESC V n) support should be implemented (where ESC V 1 = enable and ESC V 0 = disable) and a new capability defined.

Other issues uncovered:

• Character width largely unpredictable (Chinese = fat, other = thin, relationship != 2:1), such that columns property will presumably not function accurately (see capabilities.json 'column' design oversimplistic #299)
• Expected default input charset is GB2312, though vendor also supplies alternate firmware with UTF-8 input support, firmware version detection may be possible/useful for determining input mode. I have the new firmware but cannot test it yet as loading the firmware requires an RS232/DB9 connection for which I have no cabling or physical port, plus a windows machine to run the firmware update utility.
• Sending an image larger than a certain size results in no image being output, and garbage text being printed, which is probably due to the printer firmware not rejecting images larger than its drawing buffer. Figuring out precisely what that buffer size is and adding it as a capability may be useful. I wonder if other printers have other issues, or how they fail when presented with too-large-an-image?

[mike42]

Thanks for sharing, lots of good information here.

A few things come to mind-

• capabilities.json is produced at receipt-print-hq/escpos-printer-db, and is shared with projects like python-escpos. We're always looking to have this database improved, so please direct any feature requests or improvements to that project

• This driver is not currently aware of buffer sizes, and will exceed them if you send a large image. This is a known bug, see Large images may exceed the size of the print buffer #206

[globalcitizen]

OK cool, I will go hassle the python-escpos people.