Windows Print Queue

Use this when the thing you want to test is what a driver emits, or when your application prints through the Windows spooler rather than opening a socket itself. If your code builds ESC/POS bytes and writes them to a socket, skip this page - a queue would only get in the way.

Adding the printer

  1. Settings -> Bluetooth & devices -> Printers & scanners -> Add device, then Add manually when the search finds nothing.
  2. Choose Add a printer using an IP address or hostname.
  3. Device type: TCP/IP Device. Hostname: virtual-printer.online. Port: your printer's port. Clear Query the printer and select the driver to use automatically - there is no SNMP here to answer.
  4. When Windows asks for the port type, choose Custom -> Settings and confirm the protocol is Raw with the port number you entered. This is the step that matters: Raw is what sends the byte stream unaltered.
  5. Pick a driver:
    • Generic / Text Only passes text through with almost no additions - the closest thing to printing the bytes yourself.
    • Your printer vendor's driver is the right choice when you want to see exactly what it emits, which is usually the reason to set up a queue at all.

What you will see

Windows drivers are chatty. Expect initialisation sequences, code-page selection and status polls around your content on every job, and expect some of it to be ignored by the emulator - that is normal and documented in Supported ESC/POS commands.

If the queue reports an error, the connection was probably reset by the IP whitelist rather than refused; the Access Log tells you which.

Checking the port without a queue

Test-NetConnection virtual-printer.online -Port 9411

A failure here means the queue was never going to work, and the problem is the address or the network.

Next pageCUPS on Linux and macOS →