Neon

Hmm, after some googling a [BlockingCollection](https://stackoverflow.com/a/5014271/12014574) should be the better solution as it works without arbitrary delays. I'm not very experienced in C#, so sorry this fix isn't ideal.

I counted how many individual `Write` calls the shortest possible receipt takes (including commands for alignment etc.) and got 45. So the old synchronous code can be tested with these...

@lukevp have you looked into a proper solution? I'd also suggest a note about this performance issue in the README in the meantime.

Don't trust this legacy code I posted too much. It was never used in production and I just inherited the project, so no guarantees for correctness. Now that you say...

Hi, I finally had the chance to test a bit on a TM-T88IV printer. Using values `49`, `0x49` and `0x50` resulted all in model 1 QR codes. Only `50` created...

I found the reason: https://github.com/lukevp/ESC-POS-.NET/blob/a5e3fb8f2ad027dd80d90ea4b7886ecd9c79f3f4/ESCPOS_NET/Printers/BasePrinter.cs#L100 Since our data is sent line by line, this delay slows printing down dramatically.

Yes and the 50 ms delay got introduced with 32fae5e8 but never got published with any version it seems. v1.6.0 and 1.4.0 (the two most recent versions before 2.0) use...

I'd expect to get the current hash of the data, which depends on the order in which the callbacks are run when executed in the same command. In my use...

Thank you very much for the insight. I just skimmed over the git fast-export documentation as well as your code and if I understand correctly, the original hash is always...

You're mixing things up, this was all about `blob_id` in the commit callback