Closed globalcitizen closed 6 years ago
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".
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:
8
the value MIK
is supported by some versions of iconv
only.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. 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.21
described as "Latvian" in vendor documentation so have labelled it as UNKNOWN-LATVIAN-ENCODING
.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
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...
/* 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
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?
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();
Did not work apparently, resulted in lots of garbage being printed.
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.
All three QR codes printed successfully, though all three were at micro size.
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.
It looks like reverse-feed is not supported by this printer.
In summary to properly support this printer:
ESC i
) should be implementedESC V n
) support should be implemented (where ESC V 1
= enable and ESC V 0
= disable) and a new capability defined.Other issues uncovered:
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 #206
OK cool, I will go hassle the python-escpos people.
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...... 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
Formatting commands
General commands
Graphic settings command
Initialization command
Status commands
Barcode setup commands
Two-dimensional code commands
Auxiliary function commands
Additional commands
Special commands (sourced from a different document)