Printer Feature Detection #11
Description
Unlike ZPL the ESC/POS API does not support a generic 'printer metadata' command. Thus, there is no good way to query a printer for things like:
- Characters per line
- Supported codepages
- Supported barcode symbologies
- Supported ESC/POS commands
Some printers have implemented some commands that expose some of this information in a very ad-hoc spotty way. Knowledge of those commands, themselves, depends on the model of printer. This chicken-and-egg problem doesn't have a generic solution in ESC/POS.
There are two approaches:
Ask the user
Provide a way, similar to the custom command system, to have the user provide a model map value. Given a model string they provide us with information the library can't gather dynamically.
Upside: ultimate compatibility. With the sheer breadth of ESC/POS compatible devices on the market and spanning the last three decades there will always be yet another weird printer.
Downside: User has to know. The market for clone devices with poorly documented ESC/POS support is huge, and asking a user "hey please provide a list of codepages your printer supports" is a high bar for someone staring at a sub-$100 "receipt printer" from a drop shipper.
There may be space in here for a "test all the things" demo page, where a user who isn't sure can print off a test page testing all sorts of features and tick checkboxes according to what works and what gets ignored.
Query a database
This website and this github repo exist. Use it as a starting point for model features as a lookup (preferably with some way to make it as small as reasonably possible in the output library) and fall back to raising an event to ask for details from the consuming app.
The lib is CC-BY-4.0, so long as attribute is appropriately given in the usual locations it should be kosher to pull it in. It wouldn't hurt to send them a thank-you heads-up, of course.
But we should probably do both
A fall-through search:
- Look through the list of user-provided models and match on that.
- No match, look through the embedded database.
- No match, either fail or guess.
Initial implementation should probably fail-safe by not talking to something. Once proper research can be done into a 'safe minimum subset' config we can fail-to-safe-subset while raising a warning instead of an error.