Disclaimer: the legality of the question proposed, and therefore this and any other answer, are subject to the terms of licensing which have not been disclosed in the question. Use at your own risk and liability. Don't blame me.
I am answering with regard to the bounty text:
The question is widely applicable to a large audience. A detailed canonical answer is required to address all the concerns.
As I am not sure how large the audience is for intercepting a specific printer protocol, I interpret this to mean the bounty seeks an answer for reverse-engineering a master-slave protocol based only on an (as yet unspecified) bus via hardware tap.
Hardware: First, identify the bus. My best guess here is you are dealing with either usb or parallel, but could be 9-pin serial or something proprietary. In any case, get your hands on the docs for the hardware level communication protocol, and build a simple hardware device that reads the data and mirrors it elsewhere. This could be either a tap-and-record setup, which simply records the data silently as an observer (a function available in many oscilloscopes), or a MITM packet-level receive-record-send loop, which emulates the slave on one end and the master on the other. I prefer the latter as you have a greater guarantee regarding the completeness of the intercepted data, plus the ability to transmit test jobs to the slave device in order to test your understanding of the protocol; at the cost of a more complicated/expensive interceptor design.
As the original question seems to be directed at the higher-level protocol, I will glaze over this portion. Comment if you want more suggestions.
Software: Assuming you now have a hardware level tap, you can now perform a print job and inspect the recorded communication. I do not expect much effort to have been put into obfuscating the data format. At this state, you should be able to judge for yourself what format the data/communication is in, and what specific commands therein are being used. If the data you're seeing does not line up with the expected format, you have more research to do.
Layer protocol:
Now I am unsure how to go about it without knowing the data format.
I often use the terms "format" and "protocol" interchangeably. Regardless, the protocol/format the POS software uses to boss around the printer is almost certainly built upon a simpler protocol that knows nothing of the purpose of the data being transferred. In cases such as this, I adopt the "layer" terminology inherint in networking. Layer 1 refers to the most basic meaning of wire voltages. This includes ethernet, usb, serial etc. This is the protocol your interceptor needs to have at first. Layer 2 is the more purpose-specific protocol, such as IP, block storage, printer protocol etc. There can be more layers, but for this question's scope I will stick to 2. Once you examine the contents of the L1 payload, you can start reverse-engineering the L2 format and commands of interest.
In another example, consider USB as L1. Now, you can plug a thumb driver, a printer, or any number of other devices into the same USB port. These devices all use L1=USB protocol, but may all have very different L2 protocols. An interceptor built for L1=USB can record and/or mirror the payload equally well regardless. A more sophisticated interceptor might attempt to analyze the L2 payload with software, or you could do so with software tools (like wireshark in the case of ehternet or usb) after a capture has been completed.
Printer specific: I would expect the receipt printer to support the majority of whatever protocol is designated (ESC/POS or otherwise), but also the POS software designer to pick only a handful of commands.
I have done some reading and it seems that most of receipt printers accept ESC/POS command set. Does that mean POS actually sends ESC/POS commands such as 'PrintNormal xyz'?
No. The fact that most printers accept that protocol would be a good reason for the POS authors to choose it, but that does not mean that they did. The best ways to know for sure are to examine either the source code or the intercepted data. You could of course examine the compiled code, if you prefer.
Rasterization: This is purely speculation. I can see a case for using the raster subset exclusively, as it limits the effort the software author must put into understanding the protocol, while allowing greater control over the end product, in terms of font, indenting, text size etc. Also, consider that the author may be porting printing code to many different such protocols in order to support a wide range of printers. If every proposed printer protocol supports raster, then they can make the transaction-to-raster code once, and find a simple way to send that raster to the printer for each proposed protocol.
Conclusion: No, I cannot confirm what specific protocol your system is using. But, if you are in a position to intercept the hardware communication as your question implies, you should be close to doing so for yourself.
