Re: Existing practice for embeddable IPP servers in printers

On 2/9/26 20:04, John Scott wrote:
> Hi,
> 
> It is my understanding that, for newly-developed devices, it is standard for a printer to have an embedded microprocessor which runs an IPP daemon of some sort, and then the printer is operated using IPP (over a network or USB). It is also my understanding that the majority of those printers use proprietary software internally, and in the absence of evidence otherwise, this probably includes the HTTP servers and/or IPP daemons they run on as well. The primary focus of OpenPrinting, CUPS, and friends seems to be running on a server or workstation to interface *with* a printer as a peripheral. Information about crafting and maintaining the software *inside* of a printer seems much more scarce.
> 

OpenPrinting's code can also be used inside printers. Especially PAPPL is 
designed for also being used on printers, for example PAPPL has a USB "Gadget" 
mode in which the system on which it is running turns to be a USB device and not 
a USB host any more. So if you are running PAPPL in this mode on a Raspberry Pi 
you can connect the charging USB port of the Pi with a USB port on your PC and 
the PC sees the Pi as USB printer.

There is also the OpenPrinter project, a group designing an open hardware 
concept for a printer, using OpenPrinting's software on the printer:

https://www.opentools.studio/

The told that they want to run CUPS on the printer, but I had already some 
meeting with them and have recommended to use PAPPL.

> What's the current state of the art for a printer's internal software stack? Most OpenPrinting software doesn't appear to have been made with small microcontrollers (which may not have virtual memory) or real-time operating systems in mind, and I'm not sure it caters to this need anyway.
> Many embedded operating systems that would make good candidates (Linux Foundation's Zephyr, Eclipse's ThreadX [1], or Apache's Mynewt or NuttX) are capable of running HTTP servers without fuss. It's conceivable that an IPP service could work by hooking into it with CGI or something like it. Is that something that's usually done with custom code, or do lightweight libraries exist that help with processing jobs, parsing options, and the like? Is there any toolkit or library that helps in making small device-side IPP daemons, or is it something that isn't done with free software very often and there isn't much precedent for it?
>

In last year's Google Summer of Code we had a project of porting CUPS to Zephyr. 
and we have been successful with it:

https://openprinting.github.io/OpenPrinting-News-Google-Summer-of-Code-2025-Our-most-successful-one/#porting-printing-to-zephyr-by-hubert-guan
https://hubertyguan.github.io/GSoC-2025

Last week we have demoed the work on the OpenPrinting booth on the FOSDEM in 
Brussels:

https://www.linkedin.com/posts/the-zephyr-project_fosdem-activity-7425544723467071488-oZSn

    Till