Inżynier oprogramowania Michael Sweet przez trzynaście lat znajdował zatrudnienie w Apple. Odkąd firma z Cupertino nabyła od jego firmy prawa do kodu źródłowego, a jego samego zaangażowała do dalszej pracy nad CUPS-em. Stanowi to jeden z powodów powszechnego wdrożenia CUPS pośród systemów operacyjnych zgodnych z POSIX.
Konwencjonalnie deweloper aplikacji Apple nie ma do czynienia z podsystem drukowania na co dzień. Nie jest to funkcja z głównych stron portali IT. Zwyczajowo obsługę druku realizuje się na macOSie przy użyciu frameworka Application Kit. Dostarcza ono klas definiujących funkcje drukowania, dla programów GUI, pisanych z użyciem API Cocoa. Warstwa drukowania jest częścią Core OS, tj. niskopoziomowej warstwy usług operujących sprzętem i siecią. Application Kit zapytuje program o "narysowanie" zawartości pliku jako danych PDF, po czym przekazuje je do podsystemu drukowania. Tenże je buforuje w pamięci, a także przechwyca żądanie wydruku (Print job), po czym zarządza danymi definiującymi wydruk i ich metadanymi, za pomocą metody FIFO (First In, First Out - Pierwsze weszło, pierwsze wyszło).
CUPS
Wstępnie CUPS bazowało na protokole Line Printer Daemon (LPD), jednakże w toku rozwoju wynikły jego ograniczenia:
- Brak obsługi poświadczenia tożsamości.
- Niemożność kontroli dostępu.
- Niedostatek w obsłudze komend drukarek.
- Niekompatybilności ze sprzętem.
Zastąpiono go bardziej złożonym w funkcjach Internet Printing Protocol (IPP).
Można wyszczególnić cztery etapy pracy CUPS:
- Żądanie druku trafia do kolejki drukowania (print spooling).
- Planista (scheduler) przetwarza komunikaty i rozdziela zadania pomiędzy modułami.
- Przetworzone dane trafiają do systemu filtrów, w celu konwersji na format zrozumiały dla drukarki.
- Na końcu łańcucha pokarmowego znajduje się backend, tamże po ostatnich sekwencjach przetwarzania następuje wydruk.
CUPS, jak widać powyżej, osiągnął powszechność wdrożeń właśnie za sprawą prostej implementacji. Bardziej szczegółowo to CUPS wewnętrznie korzysta z PostScriptu, jako języka opisu strony. Za przepływ komunikatów pomiędzy modułami CUPS i w połączeniach na jego wejściu i wyjściu (np. między urządzeniami a aplikacją kliencką w sieci), odpowiada protokół IPP/2.1. Jest on realizowany na barkach HTTP/1.1, w efekcie powiela jego funkcje, takie jak - kontrola dostępu, potwierdzenie tożsamości i szyfrowanie.
Następnie dane zawarte w żądaniu wydruku, po opuszczeniu kolejki drukowania, znajdują się w kompetencjach planisty. Tamże informacje, za pomocą Wspólnego Interfejsu Bramkowego (CGI - Common Gateway Interface), ulegają przetworzeniu w specjalizowanych modułach, m.in. nadają komunikatom Ujednolicony Identyfikator Zasobów (URI - Uniform Resource Identifier). W konsekwencji aplikacja kliencka (Inicjująca żądanie wydruku), nie jest w stanie uniknąć weryfikacji po stronie serwera.
W tym momencie jest możliwe obsłużenie całej grupy drukarek (classes of printers), widzianych przez program jako pojedyncze urządzenie. Planista wysyła żądanie drukowania do pierwszego wolnego urządzenia. W międzyczasie uaktywnia się moduł jobs (żądania), kierujący żądaniami drukowania. Tenże przesyła dane do filtra (lub ich całego zestawu), jaki przetwarza żądanie na język opisu strony rozumiany przez drukarkę. System filtrów do identyfikacji formatów wykorzystuje typy MIME. Finalnie dane trafiają na backend, gdzie ulegają rasteryzacji, po czym są konwertowane na końcowy format drukarki i następuje wydruk. Całość procesu drukowania, jest od inicjalizacji aż po finalizację, monitorowana i opisywana w logach.
Geneza PAPPL
Michael Sweet po trzynastu latach pracy dla Apple Inc, jako programista, pożegnał swojego pracodawcę. Ogłosił na swoim blogu we wpisie z 20 grudnia 2019 roku. Jest on najbardziej znany z implementacji CUPS (Common UNIX Printing System), które obok HTMLDOC (Wczytuje strony HTML i źródła Markdown, aby przetworzyć je do formatów EPUB, indexed HTML, PostScript lub PDF, wraz ze spisem treści.) stanowiło główne oprogramowanie w ofercie jego firmy - Easy Software Products.
Przedsiębiorstwo Sweeta powstało w 1993 roku, a pierwsze linie kodu źródłowego CUPS, napisano tamże w 1997 roku. Dwa lata później ukazałą się wersja beta. CUPS szybko zyskało na popularności i zostało wdrożone w wielu dystrybucjach Linuksa, a w 2002 roku Apple zaadaptowało CUPS w Mac OS X 10.2, jako warstwę przeznaczoną do bycia niskopoziomową usługą, służącą do zarządzania kolejką drukowania i stanowiącą interfejs względem sterowników wymaganych do komunikacji z drukarkami. W 2007 roku Apple zatrudniło Michaela Sweeta i kupiło prawa do kodu źródłowego CUPS. Ważną datę wyznacza rok 2017, kiedy to wraz z wersją CUPS 2.3 zmieniono licencję z GPLv2 na Apache 2.0.
Miesiąc po opuszczeniu Apple, Michael Sweet ogłosił prace nad LPrint - aplikacja zoptymalizowana pod kątem drukowania etykiet, dla macOSa i Linuksa. LPrint obsługuje na wejściu "surowe" dane wydruku (raw print data), jak i pliki PNG. Posiada on sterowniki do obsługi drukarek etykiet poprzez sieć lub USB. Ponadto zawiera prosty serwer sieciowy. Jest on widziany w sieci użytkownika jako urządzenie zgodne z protokołami IPP Everywhere lub AirPrint. LPrint wspiera także monitorowanie procesu drukowania z poziomu linii komend lub serwera WWW.
Natomiast PAPPL stanowi efekt uboczny prac Michaela Sweeta nad LPrint i Gutenprint. Motywacją inicjującą PAPPL jest pragnienie przyśpieszenia adopcji standardu IPP Everywhere przez rynek. Umożliwia ono bezsterownikowe drukowanie po stronie klienckiej.
PAPPL obsługuje większość formatów pliku obrazu i komunikuje się z urządzeniami poprzez USB lub sieć, czyni też użytek z technologii AppSocket (JetDirect). Dzieje się tak za sprawą wielowątkowego serwera IPP. Zapewniono też wywołania zwrotne (callbacks) dla różnych zdarzeń zachodzących wskroś procesu drukowania. Toteż PAPPL pozwala programom GUI i tym obsługiwanym z poziomu linii komend, na interakcję użytkownika operującego programem drukującym z klientami działającymi w sieci, jacy wysyłają żądania wydruku. Oprócz tego PAPP monitoruje też stan drukarki i proces wydruku.
PAPPL do działania wymaga, aby system operacyjny hosta był zgodny z POSIX. PAPPL zaprogramowano na macOSie, niemniej testuje się je na różnych dystrybucjach Linuksa i sprawdza na Raspberry Pi Zero W, aby upewnić się, że wymagania względem pamięci i procesora pozostają niskie. PAPPL jest dystrybuowane na licencji Apache 2.0.
