\r should be recognized properly

[0815fips]

Try scanning the following generated 2d code:
https://barcode.tec-it.com/en/QRCode?data=Some%20line%5Cr%20breaks%5Cnin%20here.

It will result in two events:

{value: ']Q1Some line'}
{value: ' breaks\nin here.'}

Scanning with an app like Cognex Barcode Scanner will show the correct result – a text containing a carriage return and a new line character.

1. option: Never have line breaks in symbols – but who can guarantee that?
2. option: Let you bufferSize be at least 4KiB (max size of a Datamatrix code) and ditch the logic that flushes the buffer on a \r character.
   To be honest, you then would also have to tinker around, because the buffer doesn't get flushed at the right time for whatever reason. I tried setting the flowControl to 'hardware', but that doesn't seem to work either. Rarely you could get partial reads where you would first receive a small chunk, then the rest in another read.
   But relying on \r should just be a workaround.

[NielsLeenheer]

Hmm, yeah.

Unfortunately lots of barcode scanners use the \r character to signal the end of the barcode by default, even in serial mode. I'll take a look at it and see if I can come up with a solution that works for both.

[0815fips]

One other way would be getting the flow control right on the scanner and the OS. A driver for the scanner or serial to USB adapter might help.

When dealing with that in the software only, wrapping the message with STX and ETX characters is best practice.
These should not occur in symbol contents and are therefore safe to use as delimiter.