RWAP / PrinterToPDF

Project for converting captured printer data files to PDF format
GNU General Public License v3.0
83 stars 19 forks source link

ESC/POS Support #34

Open DQuomsieh opened 2 years ago

DQuomsieh commented 2 years ago

Does the current implementation not handle ESC/POS at all or does it output a slightly messed up version of the receipt?

Also, what is needed for full ESC/POS support?

RWAP commented 2 years ago

The PrinterToPDF code is solely for Epson ESC/P and ESC/P2 emulation. ESC/POS is a competely different printer control language and I have not come across anyone who has implemented a printer emulator which can interpret ESC/POS (and most definitely not free code).

ESC/POS is designed for POS (Point of Sale) terminals in the main - and generating a receipt. Those POS terminals are closed code and mainly run under a version of Windows, or even their own operating system.

We have not implemented ESC/POS because most ESC/POS printers connect via USB.

We have had very mixed results when connecting a single board computer via USB and pretending to be the original connected printer. In some cases it works, but in a lot of cases, the equipment reports no printer found - we have had more success with an Odroid C1 or a Banana Pi than the Raspberry Pi 4, but it is still very experimental and seems to depend on the printer drivers installed on the POS terminal

Even if we can connect via USB, a single board computer tends to be too slow to handle the interpretation of the ESC/POS code - remember that people will not hang around waiting for a receipt.

I guess this is why there are plenty of people who talk about capturing ESC/POS data but very few have succeeded and charge large amounts of money for custom hardware

DQuomsieh commented 2 years ago

If we are able to capture and store the ESC/POS data file (SPL file) asynchronously, can we not then interpret the byte code by following the command set for that particular printer model?

RWAP commented 2 years ago

Yes you can interpret the byte code for the ESC/POS printer if you manage to capture the data - the main issue is capturing it in the first place!

The ESC/POS code is fairly well structured, but does contain a lot of codes for barcodes, handling of cash drawers, print status messages etc. but is outside the scope of PrinterToPDF.

Software to convert ESC/POS to PDF would need to be a commercial product as it is very complex.

DQuomsieh commented 2 years ago

I have written a simple script that is able to capture the SPL/SHD files for each print job on a windows machine, just whenever I try to fully interpret the captured files, I am only able to get a few of the main commands in until it starts becoming gibberish. Without ever really being able to find the printed data, even if it is something simple like a small string of "A"s.

Do you know why this could be? Also, thank you very much for indulging me, when you didn't have to! Maybe once I have a working implementation, I might tackle converting ESC/POS to PDF.

RWAP commented 2 years ago

Without seeing your code it is impossible to know what is happening - it should just be a string of characters and ESC/POS control codes. There are several online books on the ESC/POS control codes - although it depends on whether it is a HP POS printer, or an Epson one I think!

DQuomsieh commented 2 years ago

I am simply decoding the binary data file and trying to translate the file to be able to extract the printed text. As I said, I was able to retrieve some of the major commands like initializing the printer and setting the printing speed, but the data itself has been cryptic and not understandable. It seems there is something essential I am missing, haven't figured out what it is though.

RWAP commented 2 years ago

You have to decipher the individual commands - see https://pos-x.com/download/escpos-programming-manual/ for one fo the lists.

You may well find that the text is being output as graphics data rather than plain characters!

DQuomsieh commented 2 years ago

This is exactly what I did, I was able to decipher the initialize printer command: 1B 40, generate pulse: 1B 70, and several others that show up in a different command set I found. Yet haven't found a pattern for retrieving the actually data.

It seems it is as you say, graphics data. How can I decipher it? I am not well adversed in computer graphics, but will learn anything needed to understand it.

For reference, here are two spooled files which I turned into hex from the printer I am currently testing on:

Content File
A A A A A A A A A A a_with_space.txt
B B B B B B B B B B b_with_space.txt

Also the command set for the printer I am using: https://www.snbc.com.cn/upload/portal/download/1531982353940.pdf

RWAP commented 2 years ago

The hex dumps are not great - as deciphering commands is easier when you can see the original ASCII.

If it is graphics data, you have to print it as a graphic unfortunately and then use a system to OCR the text. You can see how we use graphics printing in the PrinterToPDF code.

I did say ESC/POS was not easy !!

DQuomsieh commented 2 years ago

I always assumed deciphering the commands in hexadecimal would be easier, if that's the case I will stick with ASCII.

I will try tackling this this and implementing a way to print the graphics, just need to make sure that this is the structure of the ASCII data file I should be looking into: spool_data.txt

This output was made using cat -vt file.SPL. Is this the correct way to get the data to output as ASCII properly?

RWAP commented 2 years ago

This is where you find the documentation does not match the output - I have no idea if cat -vt file.SPL would work (it should) assuming the output is not 7 bit data for example.

Looking at the start of the captured data, there are multiple $5E @ commands (reset printer), then $5E [c; $5E A $5E [@

I can't find these commands documented so the first thing to do is work out what they are doing - are they correct - probably not as I would expect the printer to use ESC ($1B) commands not $5E

This does not match the hexadecimal dumps you provided, so I assume this raw file is wrong.

The reason raw files are easier is that the manuals show commands by character - rather than trying to find a series of hex codes in the manuals (eg ESC @)

DQuomsieh commented 2 years ago

Viewing the file in vim or gedit does not give me the same results you are talking about, I had to pass the file through the showkey -a command to get 0x5e to appear, which I am assuming is the caret ^ value.

It seems linux is misinterpreting the encoding for the file. I have tried changing the encoding to any version of windows-1250 to windows-1258 which hasn't displayed the ASCII characters that I am currently seeing on the window's machine. In windows, the encoding is ANSI which after investigation turned out to be windows-1256 in this case.

How are you viewing the files?

After I read your above comment, I began researching a lot about encoding and control characters, thank you for being so helpful and informative. I will continue going down this path as I see it having fruitful results!

BrixSat commented 1 year ago

Humm capture the escpos is the easy part.

Just use for example https://github.com/mike42/escpos-php and output the content to stdout. Or if you want in c there is also png2escpos.

Hope i could help

RWAP commented 1 year ago

Humm capture the escpos is the easy part.

Just use for example https://github.com/mike42/escpos-php and output the content to stdout. Or if you want in c there is also png2escpos.

Hope i could help

No sure what you mean - both of those are for generating ESC/POS output - what we need is a filter to do the reverse, take the ESC/POS code and convert it to a PNG on screen.