BUG: Support \t, \r on raw usage, they are printable

[erikn69]

It seems that this package was forgotten by @mike42

CRLF: In raw usage the plugin removes the \r(carriage returns) assuming that they are all from windows
but in windows they should only be deleted when they are followed by a \n(line feed)

\t: raw usage removes printable horizontal tabs

[mike42]

Hey, this issue was posted to another PR I'm working on. It's not clear to me why a code change is required here. Could you please explain some of the basics of the issue, eg:

• what you are trying to do
• what printer you have (to confirm it is ESC/POS - available documentation is always a plus)
• what code you are running
• what the output is, and why it should be different.

That code is for sending ASCII to a printer as a fallback if we have not figured out character encoding, and is not really intended to funnel control characters through, since they will behave differently between printers.

This library has very wide compatibility considerations, so passing through new control characters on this code path could cause surprising results if somebody else was relying on them being filtered out.

[erikn69]

First, this is for raw mode(writeTextRaw(string $text));
it handles the \r characters as CRLF(windows),
If there is only a \r(CR), it yields a false positive for an LF.
Now it check \r\n(CRLF)

[erikn69]

so passing through new control characters on this code path could cause surprising results if somebody else was relying on them being filtered out.

Only on raw usage, but it could be for a major release

[erikn69]

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

\t (HT) is only meaningful if horizontal tab stops have been configured (typically with the ESC D command). Otherwise, its behavior is implementation-dependent and many printers simply ignore it.

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

\r (CR) is not equivalent to \n (LF). On Epson ESC/POS printers, the behavior of CR depends on the printer configuration (e.g. whether Auto Line Feed is enabled). On many thermal printers with a serial interface, CR is ignored, while LF is the recommended way to advance to the next line.

[erikn69]

It’s been a long time; I no longer have access to that printer or the code, but this worked well in production.

[erikn69]

and is not really intended to funnel control characters through,

In my opinion, it validates printable characters.

escpos-php/src/Mike42/Escpos/PrintBuffers/EscposPrintBuffer.php

Lines 296 to 301 in f414320

	if ($num == 10) { // New-line (printer will take these)
	return true;
	}
	if ($extended && $num > 127) {
	return true;
	}

Maybe using $extended also?

[erikn69]

$extended is true only on writeTextRaw(string $text), that would reduce potential problems
HT is ignored if the columns are not configured.
CR is ignored if AUTO LINE FEED is not configured.

escpos-php/src/Mike42/Escpos/PrintBuffers/EscposPrintBuffer.php

Lines 139 to 141 in f414320

	} elseif (self::asciiCheck($c, true)) {
	$outp[$j] = $c;
	}