Background
Currently, legacy printer support is split across multiple printer applications (e.g., ghostscript-printer-app, ps-printer-app, etc.) that handle different printing stacks. While this separation might make sense from a development perspective, it could create unnecessary complexity for end users who have to figure out which printing backend their legacy device uses (an implementation detail) as opposed to picking a make and a model from the printer setup menu (current CUPS 2.x experience).
Proposed Solution
Create a unified legacy-printer-app that consolidates existing printer applications into a single solution. Key features:
- Single entry point for bridging legacy printer support, the "xwayland" or "pipewire-pulse" analog for printing.
- Internal handling of different printing stacks, where users select legacy printers by brand and model.
Benefits
-
For users: Reduce confusion during CUPS 3.x transition, simplified printer setup process.
-
For development: Consolidated codebase, reducing duplication/maintenance overhead.
-
For packaging: Less packages to track/release/maintain.
While the unified Snap/Docker container may be slightly larger in size, most dependencies already overlap between current apps, resulting in a minimal size increase if any.
Background
Currently, legacy printer support is split across multiple printer applications (e.g., ghostscript-printer-app, ps-printer-app, etc.) that handle different printing stacks. While this separation might make sense from a development perspective, it could create unnecessary complexity for end users who have to figure out which printing backend their legacy device uses (an implementation detail) as opposed to picking a make and a model from the printer setup menu (current CUPS 2.x experience).
Proposed Solution
Create a unified
legacy-printer-appthat consolidates existing printer applications into a single solution. Key features:Benefits
For users: Reduce confusion during CUPS 3.x transition, simplified printer setup process.
For development: Consolidated codebase, reducing duplication/maintenance overhead.
For packaging: Less packages to track/release/maintain.
While the unified Snap/Docker container may be slightly larger in size, most dependencies already overlap between current apps, resulting in a minimal size increase if any.