Replies: 8 comments 6 replies
-
Yes - that is the most common usage. I have a "old" Raspberry Pi Zero W setup in my lab with a USB hub HAT that is connected to a bunch of USB and network label printers that runs LPrint to make them available on the network as AirPrint/Mopria/IPP Everywhere printers.
Unfortunately that doesn't usually work out unless you use a containerized solution like snapcraft or flatpak. Years ago the different distros tried to make this work with the Linux Standards Base (LSB) specifications, but in practice it is hard to nail down all of the dependencies. Snapcraft and flatpak essentially bundle the executable with all of the dependent libraries so that (as long as the architecture matches) you can just run it on any "host" OS. |
Beta Was this translation helpful? Give feedback.
-
|
Dear Michael, Thank you for your swift response. Following your advice, I understand that creating our printer application as a Snap package, akin to lprint, appears to be the optimal strategy to achieve compatibility across various Linux distributions . I intend to follow this path. I must admit, I omitted an important detail in my prior message: our focus is on POS receipt printers, not label printers. I am under the impression that developing a PAPPL-based application for receipt printers is also viable. If this is not the case, please do let me know. Your input has been invaluable. Warm regards, |
Beta Was this translation helpful? Give feedback.
-
|
Just small correction - AFAIK flatpak is designed for leaf applications and it does not take kindly operation with USB device (that's why f.e. sane-airscan is flatpak, because it works with network scanners/USB scanners presented as network devices via ipp-usb HTTP proxy). So IMO the other option to SNAPs are OCI containers - they can be available in container registry via podman (I'm not sure about docker compatibility - I recall there is compatibility between docker and podman images, but I'm not sure whether you can see the registry from docker and podman). |
Beta Was this translation helpful? Give feedback.
-
|
Sahaya,
Yes, a printer application for a receipt printer is just as viable as any other type.
… On Jan 31, 2024, at 8:46 PM, sahayap ***@***.***> wrote:
Dear Michael,
Thank you for your swift response.
Following your advice, I understand that creating our printer application as a Snap package, akin to lprint, appears to be the optimal strategy to achieve compatibility across various Linux distributions . I intend to follow this path.
I must admit, I omitted an important detail in my prior correspondence: our focus is on POS receipt printers, not label printers. I am under the impression that developing a PAPPL-based application for receipt printers is also viable. If this is not the case, please do let me know.
Your input has been invaluable.
Warm regards,
Sahaya P
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
________________________
Michael Sweet
|
Beta Was this translation helpful? Give feedback.
-
|
Dear Michael, I hope this message finds you well. I am currently in the process of developing a printer application using PAPPL for our company's printers. Our printers come with some custom functionalities( we have more than 5), one of which includes the 'Printing Logo' feature. This feature provides users with four distinct options for logo placement and size:
I am seeking guidance on how to incorporate these specific options into our PAPPL-based application. Is it necessary for me to make modifications to the PAPPL source code to achieve this? could you please direct me to any references or sample code that could assist in this process? Thank you in advance for your support and guidance.
|
Beta Was this translation helpful? Give feedback.
-
|
This sort of feature really has no place in IPP or in a printer application. No client will know how to specify the option (or the logo), and the client is almost certainly more capable of generating a properly positioned and scaled logo for a receipt. That said, you can list vendor option names in the As a PDL option (i.e. a printer-specific command in the printer's native language) I can see why you might want to use/offer it, but since IPP clients usually send PDF or Apple/PWG raster data which already contains everything that is to be printed and those clients don't support printer-specific options, it is not something I recommend adding. |
Beta Was this translation helpful? Give feedback.
-
|
Dear Michael, I hope this message finds you well. First and foremost, I want to express my gratitude for your valuable suggestions. I've decided to incorporate vendor-specific attributes into my project at a later stage and for now, I'm moving forward with the default options. I've successfully developed a label printer application for our printer, which works well with JPEG and PNG images. However, I've encountered an issue when attempting to print PDF files. The application fails with the following error message: "Unable to process job with format 'application/pdf'." I've attached the log file for your reference to provide more details. Below is a list of libraries currently integrated into my project:
The build system is based on Ubuntu 22.04. (Linux 5.19.0-45-generic; x86_64) I'm unsure if PDF support is enabled by default in this setup or if I need to include additional libraries such as Ghostscript, Poppler, QPDF, or MuPDF to resolve this issue. Could you please guide me on how to fix this PDF printing problem? Your expertise and advice would be greatly appreciated. Thank you for your time and assistance. Best regards, |
Beta Was this translation helpful? Give feedback.
-
|
PAPPL-based printer applications don't automatically get PDF support. You need to provide a MIME filter for it, which is something the libcupsfilters project provides. In the future, PAPPL 2.x and libcups 3.x will provide this functionality automatically. That said, the Printer Applications doesn't need to support PDF directly since most people will print through CUPS or whatever native print spooler is in use, that those will convert as needed to a format the printer application does support. |
Beta Was this translation helpful? Give feedback.
-
|
Dear Michael, Thank you for your advice on integrating PDF support into our PAPPL-based printer applications. I understand now that we need a MIME filter for PDFs and appreciate your suggestion to use the libcupsfilters project for now. We'll start with the pappl-retrofit approach and plan to switch to PAPPL 2.x once it's available for the automatic PDF support. Thank you Best regards, |
Beta Was this translation helpful? Give feedback.
-
|
Dear Michael, Thank you for your guidance on incorporating PDF support into our PAPPL-based printer applications. I have successfully implemented a pappl-retrofit approach with our existing CUPS filters and packaged it as a snap. It's functioning well. I have a question regarding future developments. As we have developed this Printer App and it is currently working well, I'm wondering about the implications of future releases like PAPPL 2.x and libcups 3.x. When these versions are released, will we need to develop our printer application anew, or can we continue using the current app for our printers? Thank you for your time and assistance. Best regards, Sahaya P |
Beta Was this translation helpful? Give feedback.
-
|
I can't speak to the future of the pappl-retrofit project - that is @tillkamppeter 's baby. WRT PAPPL 2.0, I will likely be adding support for CUPS 2.5.x since the newer CUPS 2.5 libraries have the libcups v3 APIs it depends on. There are API changes in PAPPL 2.0 (thus the bump of the major version number) which will require some small changes to your printer application, but you shouldn't have trouble adapting to them. In the long term, however, you should definitely look at adopting the PAPPL native driver interface rather than wrapping the old CUPS filters. You will find the new API reduces the amount of code you need to maintain, reduces the number of "moving parts" to make printing happen, reduces the resources used, and allows you to better support things like status reporting, auto-configuration, and so forth. Depending on the printer, you may also find that the native API avoids common "translation" errors moving between PPD and IPP options and values. |
Beta Was this translation helpful? Give feedback.
-
|
@sahayap pappl-retrofit will not go away with PAPPL 2.x and libcups3. We will do the needed adaptations that it continues to work (it keeps ~10000 legacy printer models working under Linux and even under Windows). The libcups3 support in pappl-retrofit, libcupsfilters, and libppd is already done. And note that pappl-retrofit is not recommended as long-term solution for those who are maintaining the source code of their current printer drivers and have access to the supported printers for testing. As @michaelrsweet already told you should aim for a native Printer Application, directly integrating the driver code without call of external CUPS filters and without use of PPD files, as especially the PPD files are very restrictive on what kind of options you can use. pappl-retrofit is ideally used for
|
Beta Was this translation helpful? Give feedback.
-
|
@sahayap POS printers are very similar to label printers (small paper formats, low resolution, roll paper support), so you can generally use LPrint as a good example for your native Printer Application. Also such small printers do not accept PDF or PostScript by themselves, perhaps they do plain text, like dot matrix printers. But for sure they all allow raster printing and so the easiest is to make a Raster-only Printer Applications, which accepts PWG and Apple Raster as input and clients (CUPS in case of Linux) turn the PDF from apps into Raster. and send off this to the Printer Application which does the conversion into the printer's native language. If any conversion of the incoming Raster data is needed, you can use the Note also that typical receipts are on roll paper with arbitrary length, so you have to use a custom page size or print several pages/labels containing parts of the receipt without cutting the paper between them. |
Beta Was this translation helpful? Give feedback.
-
|
@sahayap for containerization we are starting to introduce OCI containers (Docker, ROCKs, podman) as alternative to Snap, to be able to cover a wide range of operating system distributions. Especially there are many immutable distros out there (all except Ubuntu Core and Ubuntu Core Desktop) which do not support Snap out of the box and usually take Flatpaks to add desktop apps. As Flatpak is not suitable for system Applications/daemons like our Printer Applications, OCI containers are usually the only secure solution here. Therefore we are working on official OCI container images of CUPS and our Printer Applications. This is done by a Google Summer of Code project this year and should result in a method to containerize any Printer Application. |
Beta Was this translation helpful? Give feedback.
-
Dear Michael,
I hope this message finds you well.
I am currently planning to create a PAPPL-based Linux Printer Application for our Non-OS POS printers and I have a couple of questions about the development process:
Is it feasible to develop a PAPPL-based POS printer application for Linux OS, and integrate our non-OS printers through network or USB connections?
Will a Printer Application developed on one Linux distribution, such as Ubuntu, be compatible with other distributions like SuSE or RedHat without needing to recompile the software?
Your guidance on these matters would be greatly appreciated as I proceed with the project.
Thank you,
Sahaya P
Beta Was this translation helpful? Give feedback.
All reactions