rs232 rastertoescpx style printer support about lprint

[michaelrsweet]

@jameshilliard LPrint could absolutely support them, although currently it only supports printers that use the ZPL or DYMO command sets. If you can provide more information about these printers (links, etc.) I can investigate adding support.

Also, are these actually RS-232 peripherals or are they USB or TTL serial devices?

[jameshilliard]

Some I have are mostly being used with native rs232 like this one which uses rastertomasung. Some I have like this using rastertoescpx are also native rs232 capable(although those seem to be more often wired with USB). There's a few others I'm working with as well that are similar I think.

[michaelrsweet]

@jameshilliard So these aren't standalone printers so I'm not going to be adding support for them in LPrint. But PAPPL provides everything you need to develop a printer application for these printers.

[jameshilliard]

So these aren't standalone printers so I'm not going to be adding support for them in LPrint.

Oh, they are available as standalone models as well. For example this would be the standalone version of this and this should be a standalone version of this I think.

But PAPPL provides everything you need to develop a printer application for these printers.

Why would one want to have separate applications for all these different printer protocols rather than having them all in one place like lprint? Isn't that just going to cause a lot of development/packaging fragmentation?

[michaelrsweet]

Oh, they are available as standalone models as well. For example this would be the standalone version of this and this should be a standalone version of this I think.

Still very much "industrial" and not something I'd expect in an office or home, which is the focus of LPrint.

Why would one want to have separate applications for all these different printer protocols rather than having them all in one place like lprint? Isn't that just going to cause a lot of development/packaging fragmentation?

@jameshilliard First, 99% of the code is shared (in PAPPL) - you really just have the equivalent of the rastertoxxx filter linked to PAPPL.

Second, these are not common printers with some unique features (like the cash drawer interfaces) that don't map to printing. Conceptually you could have a single "posprint" printer application for a bunch of point-of-sale printers like these and provide access to drawers and other POS features that don't necessary map to printers or jobs.

[jameshilliard]

Still very much "industrial" and not something I'd expect in an office or home, which is the focus of LPrint.

They are what you'd expect to see in retail environments for generating receipts/invoices. I know the rastertoescpx driver is used by multiple vendors for a decent amount or products. Why would usage location would be the distinction for where the low level hardware handling(ie raster drivers) goes? That seems a bit unusual to me as hardware handling(for example Linux kernel drivers) are not usage specific but chipset/protocol specific in general.

@jameshilliard First, 99% of the code is shared (in PAPPL) - you really just have the equivalent of the rastertoxxx filter linked to PAPPL.

I mean, the hardware handling code is something I would expect to be shared in general. Having it be application specific seems problematic when it comes to fragmentation(having to track down vendor drivers with a bunch of random upstreams).

Are downstream distros/integrators expected to package up dozens of different hardware specific printer applications/services?

Second, these are not common printers with some unique features (like the cash drawer interfaces) that don't map to printing. Conceptually you could have a single "posprint" printer application for a bunch of point-of-sale printers like these and provide access to drawers and other POS features that don't necessary map to printers or jobs.

Yeah, vendor extensions are common for these sort of devices but there seems to be a significant amount of re-used/common functionality/features. Maybe it would make sense to have a hardware handling library or something that the lprint and a posprint application could use rather than sticking hardware specific code in the application?

In general applications that talk to printers would want a standardized higher level interface that abstracts out the vendor specific hardware handling somewhat, even for POS features like cash drawers I would think.

[michaelrsweet]

@jameshilliard

They are what you'd expect to see in retail environments for generating receipts/invoices. I know the rastertoescpx driver is used by multiple vendors for a decent amount or products. Why would usage location would be the distinction for where the low level hardware handling(ie raster drivers) goes?

It isn't directly, but it doesn't make sense to shoe-horn a desktop printing application into a tightly integrated embedded environment.

Are downstream distros/integrators expected to package up dozens of different hardware specific printer applications/services?

First, distros already do this for CUPS drivers and integrators only package what they need.

Second, doing it as printer applications is actually easier since they all offer "portable" packages/containers (Snapcraft, Flatpack, etc.) that can be maintained and distributed separate from a particular distribution. One of the biggest problems with current CUPS printer drivers is that they are tightly coupled to a particular build/version of an OS.

Yeah, vendor extensions are common for these sort of devices but there seems to be a significant amount of re-used/common functionality/features. Maybe it would make sense to have a hardware handling library or something that the lprint and a posprint application could use rather than sticking hardware specific code in the application?

That is what PAPPL offers, and LPrint has gone from 12,148 lines of code in 1.0 to 3,636 lines of code in the coming 1.1 release, with significant improvements in both LPrint itself and the PAPPL code it uses. The only code that remains is the printer-specific stuff.

In general applications that talk to printers would want a standardized higher level interface that abstracts out the vendor specific hardware handling somewhat, even for POS features like cash drawers I would think.

... thus my PAPPL project, which is being used in shipping printers and printer applications.

[jameshilliard]

It isn't directly, but it doesn't make sense to shoe-horn a desktop printing application into a tightly integrated embedded environment.

I'm not really seeing what's desktop specific with lprint I guess. I'm trying to support a wide variety of different receipt printers/protocols from embedded Linux in a standardized way but it's unclear how one should actually do that.

First, distros already do this for CUPS drivers and integrators only package what they need.

I've been trying to clean up the CUPS packaging situation with buildroot but it's a confusing mess as packaging potentially dozens of hardware specific applications and services(this seems especially problematic) for buildroot seems like a maintainability nightmare to me since they would all have to be updated separately and there are usually upstream inconsistencies if they are not all from the same upstream. I'm not really sure what I should be doing here when it comes to packaging all of this up into something consistent.

Second, doing it as printer applications is actually easier since they all offer "portable" packages/containers (Snapcraft, Flatpack, etc.) that can be maintained and distributed separate from a particular distribution. One of the biggest problems with current CUPS printer drivers is that they are tightly coupled to a particular build/version of an OS.

I mean, the printer applications makes sense, but the layering seems inverted to me when it comes to hardware handling. If the hardware handling is pulled into a unified library then multiple printer applications(ie lprint/posprint snaps/flatpacks) could just pull in and bundle the dependency right? That would still accomplish the goal of decoupling from the build/version of the OS I think but without the hardware handling fragmentation.

The only code that remains is the printer-specific stuff.

Why not just pull the printer-specific hardware handling stuff into PAPPL? I mean this seems to be the most important part to have unified(so that applications built on PAPPL would not have to have hardware specific code in them).

[michaelrsweet]

@jameshilliard I think you are missing my point. PAPPL does have the low-level/hardware-specific stuff (USB, networking, etc.) but necessarily does not have the printer-specific stuff since that varies widely between printers. PAPPL is shared amongst all of the printer applications which know the specific printer commands to use.

LPrint currently implements the DYMO and ZPL languages, and soon the rest of the old CUPS rastertolabel languages (CPCL, EPL, Intellitech). That covers most of the popular thermal printers you'd buy for office/warehouse use.

The hp-printer-app printer application supports all PCL laser printers. Again, it uses PAPPL for all of the common low-level stuff but implements the PCL language stuff needed for those printers.

The ps-printer-app printer applications supports all PostScript printers. It likewise uses PAPPL for all of the common low-level stuff but implements PostScript and PPD handling.

(I could go on about the printer applications, but hopefully you see the pattern: all of them use PAPPL and PAPPL provides the common low-level/hardware interfaces they all need...)

[zdohnal]

@michaelrsweet aha, so I've misundertood as well - I thought lprint will be a haven for all label printers, which need to be covered by printer applications.
I thought Dymo and Zebra printers are supported because you have them at hand and other printers support will come from manufacturers/community.

Did I understand it wrong? Maybe I was too much mislead by my internal association lprint == label printers ...

[michaelrsweet]

@zdohnal My goal for LPrint is to cover the common label printers (which also support printing on continuous thermal paper aka receipt paper) and not for every random bit of kit hardware that somebody throws inside their embedded Linux project/solution. PAPPL provides all of the supporting code needed for those printers, and quite frankly I can't (and don't want to) "do it all".

[jameshilliard]

PAPPL does have the low-level/hardware-specific stuff (USB, networking, etc.) but necessarily does not have the printer-specific stuff since that varies widely between printers.

I understand the current situation here where PAPPL is a library that provides useful generic low level functionality(but not any vendor specific low level protocol functionality) to build printer apps with.

PAPPL is shared amongst all of the printer applications which know the specific printer commands to use.

I don't understand why it makes sense to push the vendor specific hardware handling stuff into the printer applications rather than have them all in the same place(like in PAPPL) where they can be abstracted out. Having to re-implement all the vendor specific stuff in each printer application seems to be difficult and likely to result in significant implementation fragmentation.

The different printer apps you mentioned have an IMO very confusing division of responsibility:

LPrint currently implements the DYMO and ZPL languages, and soon the rest of the old CUPS rastertolabel languages (CPCL, EPL, Intellitech). That covers most of the popular thermal printers you'd buy for office/warehouse use.

1. So this application is developed as something designed to be both somewhat vendor protocol specific and use case specific.

The hp-printer-app printer application supports all PCL laser printers. Again, it uses PAPPL for all of the common low-level stuff but implements the PCL language stuff needed for those printers.

2. This appears to be an app that is only vendor protocol specific and not use case specific.

The ps-printer-app printer applications supports all PostScript printers. It likewise uses PAPPL for all of the common low-level stuff but implements PostScript and PPD handling.

3. This also appears to be an app that is only vendor protocol specific and not use case specific.

(I could go on about the printer applications, but hopefully you see the pattern: all of them use PAPPL and PAPPL provides the common low-level/hardware interfaces they all need...)

Well the missing thing seems to be the vendor specific hardware handling still, you've got a rather confusing mix of applications some of which seem to be fully protocol specific while others that are a weird mix of protocol specific and use case specific.

If the goal is to make it easy for anyone to be able to develop a vendor neutral use case specific application with PAPPL I would think it would make sense to pull the vendor specific hardware handling into a unified library that tries to abstract out the vendor specific hardware handling details. That way there would also be a clear upstream location for all the vendor specific hardware handling stuff to go(PAPPL library) and a clear place for the vendor neutral use case specific stuff to go(printer applications like lprint/posprint).

My goal for LPrint is to cover the common label printers (which also support printing on continuous thermal paper aka receipt paper) and not for every random bit of kit hardware that somebody throws inside their embedded Linux project/solution.

I mean, the embedded stuff I'm trying to do really isn't that different from trying to support the standalone versions of these receipt printers, at least when it comes to the hardware specific protocol handling side of things, vendors like to re-use protocols/hardware handling functionality across a lot of different target markets so it would be quite helpful if there was a clear place for all that hardware specific handling code to go, rather than the current model which seems to be copy paste a PAPPL printer app template and make your own downstream app fork for each different vendor protocol.

PAPPL provides all of the supporting code needed for those printers, and quite frankly I can't (and don't want to) "do it all".

So if I'm a printer vendor and want to write and upstream my hardware specific device handling code somewhere that it can be easily used by application developers wanting to use my product where would that actually go?

For most other(non-printer) types of hardware there is a clear place for this stuff to go such as an upstream Linux kernel driver(for stuff that makes sense to go there) or on the graphics side of things you have mesa32 as a somewhat universal library that abstracts out the hardware specific user-space implementations for graphics drivers. I don't see why we don't have something like this for printers as well.

I think this lack of a clear upstream for printer driver vendor-specific code is causing a lot of unnecessary fragmentation.

From what I can tell from your explanation of PAPPL it's just expected that vendors indefinitely maintain this sort of stuff(which they would be unlikely to do properly and keep up to date long term) in their own downstream forks of PAPPL app templates for their printers. This approach just seems to be a nightmare for anyone trying to maintain distro printer support and also makes code sharing/reuse among similar vendor protocols very difficult due to the extreme driver fragmentation.

@zdohnal

@michaelrsweet aha, so I've misundertood as well - I thought lprint will be a haven for all label printers, which need to be covered by printer applications.

Yeah, it's confusing for me as well, I guess lprint is designed for handling a subset of use cases in addition to a subset of vendor protocols for label and receipt printing situations that fit into the category of home/office use.

I thought Dymo and Zebra printers are supported because you have them at hand and other printers support will come from manufacturers/community.

Yeah, that seems to not be the case since there doesn't seem to be a clear location for manufacturer/community contributions for vendor specific hardware handling to go as for lprint it seems it is only supposed to be for supporting hardware designed for home/office and not retail/industrial use cases(this distinction seems rather arbitrary to me), this is especially confusing for vendor protocols that get re-used for many printer models which have different use cases and thus don't fall unambiguously into one specific use case category.

[michaelrsweet]

@jameshilliard

I don't understand why it makes sense to push the vendor specific hardware handling stuff into the printer applications rather than have them all in the same place(like in PAPPL) where they can be abstracted out. Having to re-implement all the vendor specific stuff in each printer application seems to be difficult and likely to result in significant implementation fragmentation.

Sigh... WHAT VENDOR SPECIFIC STUFF ARE YOU REFERRING TO?

Generic I/O stuff is provided by PAPPL. IPP/HTTP stuff is handled by PAPPL. Resources and localization is handled by PAPPL. Printer-specific stuff (THAT IS NOT COMMON BETWEEN VENDORS/PRINTERS) has to be handled by the printer application, because it is vendor/printer-specific and NOT COMMON.

Page Description Languages are sometimes common enough to do a generic language driver (like I did for rastertopclx and rastertoescpx many years ago), but many times (especially for printers like the ones you linked to) the languages are one-of-a-kind, not documented at all, and/or cheap knock-offs of well-known PDLs that don't work the same way. And since that code is only useful for that kind of printer, there is no point in burdening a core library like PAPPL with all of that bullshit.

I understand your desire to have everything in one place, but that just isn't something I am willing to sign up for - I did the "support every printer under the planet" game back when I first wrote CUPS, and it burned me out. Too many printers, too little support from vendors, and too many customers/users with slightly different configurations/hardware to support!

[jameshilliard]

Sigh... WHAT VENDOR SPECIFIC STUFF ARE YOU REFERRING TO?

Raster drivers and protocol logic needed for handling/abstracting/generalizing vendor specific command requests.

Printer-specific stuff (THAT IS NOT COMMON BETWEEN VENDORS/PRINTERS) has to be handled by the printer application, because it is vendor/printer-specific and NOT COMMON.

I'm not seeing why printer specific protocol/format handling stuff can't be abstracted out into a more generalized driver library that can then be used in a usage specific(rather than a vendor/printer-specific) printer application. It looks like this has already been done for the most part with PAPPL.

Sure the low level side is vendor/printer-specific but the high level interface over the vendor/printer-specific commands I would think is somewhat common.

Page Description Languages are sometimes common enough to do a generic language driver (like I did for rastertopclx and rastertoescpx many years ago), but many times (especially for printers like the ones you linked to) the languages are one-of-a-kind, not documented at all, and/or cheap knock-offs of well-known PDLs that don't work the same way.

I'm aware vendors regularly don't follow standards, in the kernel vendor weirdness is usually handled via vendor quirk tables. I think handling vendor quirks is often too difficult to do in a defined standard(like PDL) rather than just adding conditional code handling in a driver.

I understand your desire to have everything in one place, but that just isn't something I am willing to sign up for - I did the "support every printer under the planet" game back when I first wrote CUPS, and it burned me out.

I mean, if there's an clear place for vendors/contributors to submit their feature handling extensions to I would think that would make the situation less bad. This looks to be a bit easier to do with PAPPL than the original architecture as it seems to be better abstracting out the driver interface already, it just needs to go a little bit further I think to fully decouple from the applications.

And since that code is only useful for that kind of printer, there is no point in burdening a core library like PAPPL with all of that bullshit.

I'm not saying hardware specific drivers should necessarily go in PAPPL so much as they should be separated from the applications. For example you could collect drivers like lprint-zpl in a "cups-drivers" project that LPrint would depend on(along with PAPPL probably).

Looking at PAPPL and lprint in more details this doesn't even look that difficult since there already seems to be a higher level driver interface that could be adapted to work like this fairly easily, you'd maybe want to define a clearer driver loading scheme like this maybe for each different driver(modeled roughly on the Linux kernel module loader style):

static pappl_pr_driver_t	zpl_drivers[] =
{
  { "zpl_2inch-203dpi-dt",        "Zebra ZPL 2-inch/203dpi/Direct-Thermal",   "", NULL },
  { "zpl_2inch-203dpi-tt",        "Zebra ZPL 2-inch/203dpi/Thermal-Transfer", "", NULL },
  { "zpl_2inch-300dpi-dt",        "Zebra ZPL 2-inch/300dpi/Direct-Thermal",   "", NULL },
  { "zpl_2inch-300dpi-tt",        "Zebra ZPL 2-inch/300dpi/Thermal-Transfer", "", NULL },
  { "zpl_2inch-600dpi-tt",        "Zebra ZPL 2-inch/600dpi/Thermal-Transfer", "", NULL },
  { "zpl_4inch-203dpi-dt",        "Zebra ZPL 4-inch/203dpi/Direct-Thermal",
        "COMMAND SET:ZPL;", NULL },
  { "zpl_4inch-203dpi-dt-gx420d", "Zebra GX420d",
        "MANUFACTURER:Zebra Technologies;COMMAND SET:ZPL;MODEL:ZTC GX420d;", NULL },
  { "zpl_4inch-203dpi-tt",        "Zebra ZPL 4-inch/203dpi/Thermal-Transfer", "", NULL },
  { "zpl_4inch-300dpi-dt",        "Zebra ZPL 4-inch/300dpi/Direct-Thermal",   "", NULL },
  { "zpl_4inch-300dpi-tt",        "Zebra ZPL 4-inch/300dpi/Thermal-Transfer", "", NULL },
  { "zpl_4inch-600dpi-tt",        "Zebra ZPL 4-inch/600dpi/Thermal-Transfer", "", NULL },
{

static struct pappl_pr_driver zpl_driver = {
	.name =		"zpl",
	.init =	        lprintZPL,
	.driver_table =	zpl_drivers,
	.printfile =	zpl_printfile,
	.rendjob =	zpl_rendjob,
	.rstartjob =	zpl_rstartjob,
	.rstartpage =	zpl_rstartpage,
	.rwriteline =	zpl_rwriteline,
	.status =	zpl_status,
};

pappl_pr_driver_register(zpl_driver);

Then all these driver modules could be collected up into a "cups-drivers" library or something which the usage specific application(like lprint) could then depend on and use by calling helper/loader functions from the drivers project(or PAPPL maybe) that iterate over the registered/available drivers looking for a suitable match based on what the application wants and initialize/use them based on their higher level driver/module interface(pappl_pr_driver in the above example).

In the above example we have a pappl_pr_driver structure(similar to pappl_pr_driver_data_s but with an initialization interface and drivers table added) with the higher level operations that call their appropriate driver specific functions.

This is very similar to what lprint already does for the drivers it supports but it would allow one to further generalizes the driver initialization(currently lprint uses driver specific initialization here) so that additional drivers can be added without modifying the higher level application code that depends on them at all as long as the driver implements the existing high level interfaces appropriately. Using a technique like this the drivers can be implemented/developed completely independent of the applications that depend on them as long as one doesn't need to add anything to the higher level generic driver interface.

[michaelrsweet]

@jameshilliard What you want has been tried (unsuccessfully) many times over the years - UPDF in the PWG and Microsoft's GPD printer drivers are two very public failures that tried to abstract everything away into configuration files. They work for very simple things for common PDLs, but they fall apart as soon as you need to do something outside the norm. My own rastertopclx and rastertoescpx work reasonably well for the PDLs they support but have their own set of limitations.

Doing a dynamically-loaded driver approach breaks in hard to fix ways on systems that utilize kernel-level security features (SELinux, AppArmor, Seatbeat, etc.), PLUS you end up with more dependencies and random crashes from code you've never tested with.

I'm sorry, but you will not convince me to take on responsibility for all printers and printer drivers (which is what you are asking me to do). I provide PAPPL for people to develop modern printer applications to support printing going forward (as the replacement for CUPS printer drivers) and LPrint for people who use common desktop/warehouse label printers. I'll consider adding other popular desktop/warehouse label printers on a case-by-case basis. If someone wants to support a receipt or lottery ticket printer for a commercial solution they can write their own software (with or without PAPPL), provide it under whatever terms they like, and support it themselves.