When working with List & Label, especially in modern server environments, many of us encounter the familiar issue of requiring a printer driver to edit layouts or generate export formats like PDFs. This stems from List & Label’s tight integration with the Windows GDI, which relies on a printer driver as its device context.
While this dependency is rarely an issue in traditional desktop or Windows-based applications, it becomes increasingly challenging in modern architectures, such as cloud environments, web applications, or containerized solutions.
Current Challenges in Modern Environments
Docker and Containerization:
In containerized environments like Docker, installing a printer driver is often impractical because containers typically use minimal operating system images that lack GDI or printer drivers. Moreover, Docker containers almost exclusively run on Linux hosts.
List & Label relies on the Windows GDI for all its functionalities, even for layout design or PDF export, restricting its use to Windows containers, which are less common in mixed or Linux-dominant environments.
Platform independence and resource efficiency are key principles of containerized architectures. Dependence on Windows and printer drivers runs counter to these principles.
Web Applications:
In web applications running on IIS, issues can arise if the application pool (e.g., ApplicationPoolIdentity) lacks access to an installed printer driver. This often requires manual configuration of permissions or switching the application pool to a user account, which can be cumbersome.
Cross-Platform Approaches:
Many modern applications rely on Linux servers for scalability, cost efficiency, and flexibility. List & Label’s strong dependency on the Windows GDI significantly limits its use in such environments.
Proposal: Cross-Platform Support and Decoupling from Windows GDI
To address the demands of modern architectures, future versions of List & Label could benefit from enhanced platform independence. Specifically, I propose the following:
Move Away from Windows GDI as the Sole Rendering Technology:
Integrate modern graphics libraries like Skia or Cairo to handle rendering tasks without requiring printer drivers.
Docker Compatibility:
Provide an official Docker image with pre-configured dependencies (e.g., a base image including all necessary rendering components).
Offer documentation and examples for integrating List & Label into containerized applications.
Linux Support:
Develop a native Linux version of List & Label or middleware that operates on Linux servers and communicates seamlessly with existing applications.
Optimization for Web Applications:
Introduce a “headless” mode designed specifically for server-side rendering and export tasks in web applications, eliminating the need for printer drivers entirely.
Benefits of These Approaches
Flexibility: Applications can be developed and deployed independently of the operating system.
Cost Efficiency: Easier use of cloud-native tools like Kubernetes and Docker.
Future-Proofing: List & Label remains relevant for developers adopting modern technologies and architectures.
Reduced Configuration Effort: Eliminates the need for specific user accounts or printer driver workarounds.
I believe that such advancements would not only alleviate the burden on current users but also attract new audiences seeking cross-platform solutions.
@tsafadi Thank you very much for your balanced and well-crafted post. It is highly appreciated. If you take a look at our LinkedIn stream, you will notice that this matter is under serious consideration. More information will be available very soon.
BTW - at least the printer driver dependency is no longer an issue since we’ve introduced the Printerless mode. However, as of now you still need a Windows machine to run on.
I was really excited about the news you shared during the live stream and appreciate all the detailed insights on the new releases. I’m confident that this is the right direction for LL, and it’s great to see Combit actively engaging with customer feedback!
That said, I’d like to mention one small point. In the live stream, it was stated multiple times that printing is not that relevant in web environments. While this might hold true for non-business applications, many of our clients rely heavily on printing—especially in production-focused companies where efficiency is critical. In such environments, requiring users to download a file before printing is not always feasible. The need for direct label printing is even more crucial, as it must integrate seamlessly into workflows.
I understand that implementing native printing in web applications is a challenging task, especially given that most print drivers are Windows-only. However, perhaps a workaround could be developing an LL print microservice that runs on a Windows server and allows LL NG to communicate with it for printing purposes. Just a rough idea, but it could be an interesting approach!
Regardless, thanks again for the great work! I really appreciate Combit’s commitment to customer feedback and look forward to seeing LL evolve further.
Thank you for your response! I understand that printing is still feasible, and my comment was more about clarifying our priorities.
Are we discussing printing capabilities on the client side or the server side in your scenario? Would you like your users to have the ability to print a file directly locally (eliminating the need to download, reopen in a PDF viewer, and print from there)? Alternatively, should there be an option for users to click a button that initiates a server-side print job to a network printer accessible from the server?
Thanks again, any feedback from the “real world” is appreciated very much!
This is specifically about server-side printing. Most of our applications run on a React frontend with a .NET backend, both fully containerized. We’ve been using LL for 15 years, and as demand for web-based applications has grown, we’ve migrated our solutions accordingly.
Currently, we’ve taken a “hybrid” approach by developing a Windows-based LL client application that the frontend communicates with via a Windows Custom Protocol registered in the registry. However, this comes with challenges—primarily the need to distribute and maintain the application across all users, which often leads to version conflicts. A more centralized solution would be highly beneficial.
Our key requirement is direct printing to a local printer, bypassing the download-and-print workflow. For example, in our packaging department, shipping labels need to be printed every few seconds, making manual downloads impractical.
In an ideal scenario, we would integrate LL NG into our backend for report generation, which would already satisfy 90% of our users, as direct printing is not always required. However, for the remaining 10%, where time is critical, it would be fantastic to have a microservice that communicates with the backend to handle printing jobs efficiently.
I hope this makes sense. I’d be happy to provide further feedback if needed—I’d even be open to hopping on a quick call to discuss this in more detail.
P.S.: I’m German, just writing in English to ensure accessibility for everyone.
If we’re aiming to handle server-side printing, it looks like using CUPS is our best bet. It’s on our (long ) list of stuff to look into.
From what I gather, you can shoot a PDF directly to a printer with the lp command. Another option could be converting the PDF to PostScript (maybe using GhostScript) and then sending it over to a PostScript compatible driver.
We’ll have to check out both methods, but right now, these seem like our top choices.
Yeah, we even tried some CUPS implementation but our printer couldn’t handle the PDF. It was always messed up, probably because the printer didn’t understand the PDF.
At least with LL NG we can already migrate most of our reports. We will probably keep the client printing service until we come up with a better solution.
Anyway, thanks for helping out/listening to the fedback!
