filter: add a raster to ESC/POS filter

[sergio-gdr]

Hello.
This PR adds a new filter to cups-filters. From the commit message:

ESC/POS is a de facto standard for POS (Point Of Sale) terminal printers (eg, thermal receipt printers).

This patch adds a very bare-bones implementation to print raster data on printers that implement this command set. It also includes support for cutting paper either at the end of a page or at the end of a job.

I'm not sure how to handle the fact that different vendors have different ppd option names for things like cutting, paper feed, etc. What is the recommended way to handle these differences? should I just hardcode the ppd names for options that are known from the different vendors? (eg, Star uses "CutType" or "DocCutType", while Epson uses "TmxPaperCut, for the paper cut ppd option).
Thank you.

[andrewshadura]

Some comments:

1. This code hardcodes commands used by ZiJiang printers, which is just one of the ESC/POS dialects. With commands like cutting and even bitmaps, there’s a lot of differences between printers, and then there’s a separate Bixolon dialect, where a lot of commands are completely different. Probably you should have some constant arrays of different command dialects and switch between them depending on the printer model.
2. This code does not address text encodings. ESC/POS operates in Latin-1 by default, but many printers support other encodings, including also two-byte Chinese encodings. Since each printer has its own set of encodings, this needs to be handled in a way separate to the above. The python-escpos project implemented a "magic encoder" which switches codepages as needed when printing text; I’ve implemented something similar in my escpos-android project.

P.S. The encoding issue maybe isn’t too important as you’re filtering rasterised text already? Still the variety of dialects needs to be addressed somehow.

[sergio-gdr]

Thanks for looking at this.

1. This code hardcodes commands used by ZiJiang printers, which is just one of the ESC/POS dialects. With commands like cutting and even bitmaps, there’s a lot of differences between printers, and then there’s a separate Bixolon dialect, where a lot of commands are completely different. Probably you should have some constant arrays of different command dialects and switch between them depending on the printer model.

P.S. The encoding issue maybe isn’t too important as you’re filtering rasterised text already? Still the variety of dialects needs to be addressed somehow.

what commands in the code are specific to the ZiJiang dialect? the idea is to begin with a very bare-bones implementation, with just very basic commands that can be safely assumed to be the same for all vendors.

[tillkamppeter]

Thanks for the PR, contributing an ESC/POS printer driver is a good idea.

But are you aware of the New Architecture of printing? From CUPS 3.x on support for PPD files and driver filters will get removed. We will get all-IPP, only supporting driverless IPP printers, and for legacy/specialty printers which still need a driver, we will use a new format, the Printer Applications, emulations of driverless IPP printers which on their other end talk with the actual printer device (and do all needed conversion for that).

See this little introduction which I have written to introduce code contributors for OpenPrinting. Contains some videos and podcasts where Michael Sweet and me got interviewed and some short text about whet we are doing, especially the New Architecture ...

And for names of options and choices, Printer Applications talk IPP with the outside world and IPP has standardized names for nearly everything ...

You should have a look at the LPrint Printer Application from @michaelrsweet . It is for label printers which are very similar to POS printers (small format, low resolution, roll paper ...) and either use it as a base for your POS Printer Application or add POS printer support to LPrint ...

[jameshilliard]

You should have a look at the LPrint Printer Application from @michaelrsweet . It is for label printers which are very similar to POS printers (small format, low resolution, roll paper ...) and either use it as a base for your POS Printer Application or add POS printer support to LPrint ...

I had previously been informed that lprint is the wrong place to add support for these sort of receipt printer devices, has that changed or is there a new project where one should work on adding support for these sort of devices?

[michaelrsweet]

@jameshilliard I am actually tracking the eventual addition of ESC/POS printers to LPrint now. I’m not sure how much functionality will be supported yet, but certainly the basics (printing, cutting) will be.