-
-
Notifications
You must be signed in to change notification settings - Fork 42
What tools are using lprint? #166
I looked around a bit for tools that build on top of lprint, but I could not find anything quickly. Is there a list somewhere? Can people share what they know about?
In particular, I was looking for a small commandline tool to print labels with my Brother PT-E550W, with support for various styles of labels (one-off, equally spaced, cable wraps, cable flags, etc.) but could not find anything yet (only some tools that did just a little but only implemented a few specific printers). I'm pondering writing such a tool myself and tried using the ptouch cups driver (to automatically get support for a lot of printers), but I understand that cups will be removing custom driver support, and a separate print server like lprint is the way to go (also, cups has so many stacked filters that I could not manage to print bitmaps on my label printer because of some page size issue somewhere, so using something more lean and specific like lprint seems nicer). So I'm considering to do some hacking on lprint to get my PT-E550W working with it, but I am also wondering if there are existing commandline (or GUI) tools available to interface with lprint (so I do not need to reinvent the wheel, or at least have some existing tool for testing with).
All reactions
Replies: 2 comments 6 replies
One of the main purposes of printer applications like lprint or even the main purpose for them is to provide support of enhanced functionality or older non-driverless printers once CUPS drops driver support for CUPS to be able to pick them up by driverless means, so IMHO you should use CUPS tools and API unless you would like to reinvent a wheel.
Like lprint shares the queue via mDNS, so any tool can pick the record up and do the same thing as CUPS does, but that's exactly reinventing the wheel :) .
All reactions
I'm not sure I understand this entirely. You're saying CUPS still works, so use that until it no longer works? That seems fair, but I was running into some issues with the stack on CUPS (in particular bitmap printing did not work well and debugging is hard because of all the layers and legacy), so it seemed reasonably to switch to lprint now (since I would have to at some point), especially since I suspect lprint handles bitmaps better (since it handles nothing else).
I'm not sure what you mean by reinventing the wheel there - AFAIU lprint should be a reasonable drop-in replacement for CUPS in that it also exposes IPP, so what wheel would I be reinventing by using lprint?
All reactions
Matthijs, I think Zdenek was focused on the "printer driver replacement" aspect of printer applications - this is something we have been working towards for 15 years in order to support "legacy" printers with IPP. But fundamentally printer applications are concerned with "simple printing" (images, bitmaps, and sometimes PDF) while CUPS adds additional functionality on top of that.
All reactions
I'm not sure I understand this entirely. You're saying CUPS still works, so use that until it no longer works?
No - I mean using CUPS (where you can use IPP Everywhere for IPP service shared by lprint) + lprint (where you install the printer itself). This combination will work regardless whether CUPS supports classic printer driver or not in the future.
I'm not sure what you mean by reinventing the wheel there - AFAIU lprint should be a reasonable drop-in replacement for CUPS in that it also exposes IPP, so what wheel would I be reinventing by using lprint?
Ok, now I see the discrepancy - AFAIK (based on our PWG/Openprinting meetings and it made sense to me) lprint is not designed to be 1-to-1 drop-in for CUPS. I don't know who shared such information, because I saw a person asking about similar thing about PAPPL, but IMO it is not the aim.
Printer application technology - as far as I understand and how I prepare its packaging for Fedora Linux - provides an additional layer between CUPS and legacy or use case specific printer, which makes the printer available for CUPS even when CUPS does not support classic drivers anymore, or if the printer has non-standard options which is not covered in IPP standards to make them available as IPP attribute aka enhancing generic printer capabilities defined by IPP Everywhere. So I see the printer application as something which CUPS will communicate with, not as drop-in for all dropped label printer related functionality.
As Mike mentions, deep down it goes to "simple printing" with printer applications - you can send specific file formats for printing and it will work, but it aims to support only these simple use cases, not re-implement CUPS completely - use CUPS for more complex functionality. If you wanted to bypass CUPS in your application and use lprint directly, it would be possible and you would have to look for mDNS services and then do the IPP communication, which would be IMO "reinventing CUPS API" instead of using libcups, which can do the same for you :) .
All reactions
Right, thanks for clarifying. I had not fully realized this is is how it works, but it makes sense indeed.
I can also see how this makes my question a bit moot - applications should usually talk to CUPS and not lprint directly. I'm still curious about applications that are intended for (continuous) label tape printers, so applications that talk to CUPS but are intended to be used with (or optimized for) lprint as the backend can still be interesting (but as I also said in the other thread, I was looking for some continuous ribbon tape printers, but AFAICS most if not all of the currently supported printers are primarily discrete label printers). Edit: Just read michael's answer, apparently there are some printers that can also do this
Thanks for clarifying, in any case :-)
All reactions
As @zdohnal notes, most users will probably get the most out of a CUPS + printer application combination since it offers full printing functionality.
LPrint itself (like most printer applications) can print images directly but not more complex files. In particular for LPrint, I intended the image printing and "raw" support for shipping applications since most commercial shippers can provide PNG or raw files for labels, and if you are automating that side of your business it is definitely lighter-weight than setting up a full CUPS install and managing that. Moreover, there are mobile applications for the various e-commerce solutions that support printing via AirPrint/IPP Everywhere/Mopria which LPrint also supports without adding a full CUPS install.
All reactions
Understood (I think), but are you aware of any shipping applications or other label writing applications that are using lprint? I understand that any application that can print to IPP could be used with lprint, but I can imagine that there are also applications written that are specifically intended to be used (and tested with) lprint and have features that are suited to label printing?
Actually, I guess my real question is about existing applications that can be used for continuous label printing (i.e. narrow width variable length labels such as the Brother PT printers print). However, looking more closely at the supported printer list, I think all of the currently (non-experimentally) supported printer models are intended for bigger, fixed size labels (e.g. address labels), so applications intended for those printers are probably not what I am looking for anyway :-)
All reactions
Matthijs, I'm not aware of any applications explicitly using lprint for label printing.
WRT the Brother printers (and DYMO as well), there is support for "ribbon" labels, you just need to specify the corresponding media size and provide the corresponding content to be printed.