Artykuł ten miał opisywać konfigurowanie drukarki z pominięciem wysokopoziomowych nakładek typu lpd-ng czy cups, ale wymknął mi się spod kontroli. Tematyka rozlazła się na boki, ale może komuś się przyda.
Obsługa drukarek jest w Linuksie odmienna od tego, co zna się z systemów typowo domowych - przyczyną są, jak zwykle, naleciałości z systemów uniksowych. Część nieporozumień wynika też z zestawiania Linuksa na jednej płaszczyźnie z Windows Microsoftu, co siłą rzeczy nie może kończyć się dobrze, gdyż Windows ma wiele rzeczy rozwiązanych diametralnie inaczej ze względu na całkowicie inny charakter tego systemu, np. obecne w Windows rachityczne wsparcie (lub jego całkowity brak) dla pracy wieloużytkownikowej spowodował powstanie rozwiązań dedykowanych pojedynczemu użytkownikowi, a nie np. całej sieci stacji roboczych. Stąd silne "zsieciowanie" standardowego procesu drukowania pod Linuksem może wydawać się często przesadzone gdy Linux działa na pojedynczej, niezsieciowanej maszynie - ale wynika to po prostu z korzeni systemu.
Bestyja "standardem" zwana:
Pierwszym, najbardziej podstawowym problemem jest zgodność drukarki z systemem Linux. Dominacja systemu Windows na rynku biurkowych systemów operacyjnych pomogła rozprzestrzenić się architekturze pecetów i idei "klonowania". Niestety, doszło do wypaczenia. Zaczęły pojawiać się urządzenia używające, zamiast istniejących od lat standardów branżowych, swoich własnych, niekompatybilnych z niczym innym rozwiązań. Najbardziej popularne felerne "produkty uboczne" to tzw. winmodemy oraz drukarki GDI. Są to typowe dla branży PC efekty zaniżania kosztów produkcji, najchętniej poprzez ograniczanie elektroniki wykorzystywanej w urządzeniu i spychaniu jak największej części pracy na główny procesor maszyny i w sferę dedykowanego oprogramowania - sterowników.
I właśnie sterowniki stają się problemem. Producent zwykle nie jest zainteresowany wspieraniem innych platform poza kilkoma wybranymi wersjami Windows, produkuje po prostu tani, domowy złom który pewnie i tak nie będzie działał z następną wersją Windows. Dla części winmodemów można znaleźć linuksowe sterowniki, ale zwykle nie zasługują one nawet na określenie ich mianem "działają znośnie". Niestety.
Z drukarkami GDI (zwanymi też czasem, analogicznie do winmodemów, "windrukarkami") jest jeszcze gorzej - one nie polegają tylko na sterownikach realizujących interfejs do urządzenia, o nie... one polegają na pewnych cechach samego systemu Windows (głównie podsystemie GDI), niemożliwym do zreplikowania. Taka drukarka będzie absolutnie bezużyteczna pod Linuksem...
Wybór drukarki:
To wszystko sprawia, że przy wyborze drukarki trzeba uwzględniać zawsze jej zgodność ze standardami. Właśnie - nie chodzi o zgodność z samym linuksem, ale o standardy. Kiedyś wszystko było dużo prostsze - drukarki przyjmowały strumień danych ASCII i go drukowały. Potem pojawiały się kolejne rozszerzenia, ale dobrze udokumentowane (aby autorzy aplikacji mogli dostosować swoje programy) - jak np. ESC/P2 Epsona. Nadejście Windows 95/98 i taniego, chłamowatego sprzętu wywróciło wszystko do góry nogami.
Użytkownik linuksa może znaleźć się (generalizując) w dwóch sytuacjach: albo ma już drukarkę, albo chce dopiero jakąś kupić. Jeśli ma drukarkę, to już tego nie zmieni (no, chyba że kupi nową). Jeśli jednak dopiero ma zamiar kupić drukarkę, to jest w tej dobrej sytuacji że może świadomie wybrać porządny model. Na szczęście istnieje serwis LinuxPrinting.org zbierający informacje o drukarkach i oceniający ich współpracę z Linuksem. Można tam łatwo sprawdzić w jakim stopniu drukarka jest kompatybilna z tym systemem - a więc czy da się ją uruchomić lub czy jest sens ją kupować. Na pewno nie ma sensu kupować niczego, co otrzymało tam ocenę niższą od "works perfectly".
Naprawdę polecam LinuxPrinting.org, bo zawiera on dużo informacji o zgodności drukarki z Linuksem, ale także o kosztach eksploatacji czy innych technikaliach powiązanych z drukarką. Często nawet nie będzie tak, że droższa drukarka będzie "lepsza" - np. drukarki laserowe Panasonica, mimo ceny porównywalnej z analogicznymi modelami innych producentów, będą często zdolne tylko do pracy w Windows. Podobnie może zdarzyć się, że nawet jakaś najtańsza atramentówka (tzw. "model z marketu") będzie działać znakomicie pod Linuksem. Na szczęście można to sprawdzić w tamtej bazie drukarek - obejmuje ponad tysiąc różnych modeli, więc znajdzie się tam większość modeli dostępnych u nas na rynku.
Idealnym zakupem jest drukarka posiadająca wbudowany, sprzętowy interpreter PostScriptu - ale takie ustrojstwo znacznie podbija cenę. Nie posiadają go drukarki "domowe", a nawet wśród tych "średniej klasy" jest to rzadkość, więc zwykle trzeba z tego zrezygnować. Znaczenie postscriptu wytłumaczę za chwilę.
Przebieg procesu drukowania:
Linux powoli staje się coraz przyjaźniejszy "domowym instalacjom", ale sam proces drukowania wygląda tam zwykle identycznie jak w złożonych sieciach. Wyróżnia się kilka faz procesu drukowania, zgodnie z uniksową tradycją - w systemach uniksowych dla każdej bardziej skomplikowanej czynności zwykle buduje się kolejkę złożoną z mniejszych programów - każdy wykonuje swoją część pracy i przekazuje półprodukt następnemu programowi w kolejce. Na tym polega część uniksowości Linuksa - małe programy, koncentrujące się na swoich zadaniach - napisane tak, by można je było łatwo łączyć w łańcuchy do realizacji bardziej kompleksowych zadań.
Widać to wyraźnie przy drukowaniu. Weźmy sobie klasyczny, "domowy" przykład - użytkownik zestawił jakiś arkusz kalkulacyjny w OpenOffice.org i chce go wydrukować. W momencie kliknięcia ikonki "Drukuj" i potwierdzenia do akcji wkracza cała machina drukująca...
Najpierw aplikacja przekształca swoje dane na coś bardziej uniwersalnego. W linuksie jest to format PostScript opracowany dawno temu przez Adobe.
Następnie dane postscriptowe są przekazywane tzw. spoolerowi wydruku. Spooler to specjalny program którego zadaniem jest zbieranie zleceń wydruku od różnych użytkowników i zarządzanie nimi. Spooler dba o to, by kolejne zlecenia odczekiwały sobie aż drukarka będzie mogła je przyjąć. Dodatkowo, co przydatne w dużych sieciach, spooler zajmuje się wyznaczaniem priorytetów (np. zlecenia pochodzące z działu rachunkowości mają zawsze absolutne pierwszeństwo wydruku), wybiera drukarkę na którą ma iść wydruk (drukarki nie muszą być wcale przy komputerze który wysyła zlecenie wydruku), przesyła informacje o problemach z drukowaniem na komputery ludzi od obsługi technicznej, może też odwalać tzw. "accounting", czyli obliczać zużycie papieru i inne takie rzeczy. Spooler dba też o to, by w razie restartu (awarii?) systemu nie zagubiły się nigdzie zakolejkowane zlecenia wydruku. Spooler jest często zintegrowany z tzw. "magicznym filtrem" który pozwala przyjmować do wydruku dane inne od postscriptu - rozpoznaje typ danych (np. zwykły tekst lub obraz jpeg) i automatycznie konwertuje do postscriptu używając odpowiednich narzędzi wsadowych.
Gdy nadejdzie właściwa pora, spooler może przystąpić do drukowania.
W przypadku drukarek postscriptowych sprawa jest dosyć prosta - na drukarkę
"wrzuca" się bezpośrednio strumień poleceń postscriptu i dalej to już
zmartwienie elektroniki drukarki jak to wydrukować. Ale drukarki
postscriptowe są pewnym luksusem na który nie wszyscy możemy sobie pozwolić.
Dlatego tutaj często wchodzi do gry kolejny program - sterownik
drukarki. Większość drukarek przyjmuje dwa typy danych (czasem więcej,
niż dwa). Pierwszy, wywodzący się z przeszłości drukarek komputerowych to
dane ASCII - drukarka po wykryciu strumienia ASCII zaczyna go po prostu
drukować. Ten tryb pracy włącza się po wykonaniu czegoś w stylu
cat plik.txt > /dev/lp0
...choć niektóre "nowoczesne" (czytaj: zupełnie beznadziejne) drukarki nie
potrafią już tego. Drukarka w tym trybie używa jakiegoś wbudowanego fontu
i kodowania, czasem można go przestawić za pomocą jakichś switchy
umieszczonych na samej drukarce - ale to akurat zanika w nowych drukarkach.
Drugi typ przyjmowanych danych to jakiś format "graficzny", tzn.
pozwalający na drukowanie nie tylko znaków alfabetu lecz i obiektów
geometrycznych czy, w uproszczeniu, dostęp do pojedynczych punktów na
papierze. Podczas gdy ASCII jest standardem, ten drugi już niekoniecznie. Drukarka
będzie obsługiwała jakiś format danych wymyślony przez producenta. Tutaj
konieczny staje się sterownik który przetworzy przenośne i zgodne ze
standardami dane na strumień binarny "jadalny" przez konkretny model
drukarki (ale też zwykle nieprzenośny na inne modele drukarek).
Niektórzy producenci drukarek udostępniają w tym celu sterowniki dla
Linuksa, ale to dosyć nowa praktyka.
Najczęściej spotykanym sterownikiem będzie GhostScript, często
nazywany też po prostu gs od nazwy jego głównego pliku wykonywalnego.
GhostScript to nie pojedynczy sterownik, ale cały zbiór różnych sterowników
(choć może lepiej nazywać go "konwerterem").
GhostScript przyjmuje dane w formacie Adobe PS/Adobe PDF i przekształca je
na coś innego - czysty tekst, różne formaty graficzne (w tym i te dla
faksów), strumienie binarne dla wielu drukarek, inne odmiany postscriptu...
jednym słowem jest to bardzo przydatne narzędzie. Zwykle będzie tak, że
spooler przekaże dane postscriptowe ghostscriptowi, a ten z kolei przetworzy
je na odpowiedni strumień binarny i spróbuje wepchnąć w odpowiedni plik
urządzenia drukarki w /dev.
A wtedy do akcji wchodzi sterownik portu drukarki który ten strumień danych przesyła drukarce. I na tym się kończy zadanie Linuksa.
PostScript:
PostScript to złożony język opisu strony. Jest pełnoprawnym językiem programowania, z tym że specjalizuje się właśnie w opisywaniu wyglądu strony. Istnieje kilka "odmian" postscriptu, zwanych poziomami ("levels"). Każdy wyższy "level" to trochę nowych możliwości oraz nowe wbudowane fonty. A, właśnie - fonty. Jednym z założeń postscriptu jest to, że drukarka postscriptowa zawiera w swoim romie kilka/kilkanaście postscriptowych (skalowalnych) fontów. Wtedy plik postscriptowy nie musi już zawierać opisu takiego fontu, on tylko odwołuje się do konkretnych znaków z fontu - to zmniejsza znacznie ilość danych jakie trzeba przepchnąć przez port drukarki przy wydruku (część fontów już jest w drukarce). Możliwe jest oczywiście również korzystanie z zewnętrznych fontów. PostScript używa w wielu miejscach definicji wektorowych do opisu obiektów na stronie, co pozwala zmniejszyć rozmiar wynikowego pliku oraz skalować "wydruk" bez strat jakości. PostScript jest również przenośny - nie jest przywiązany do konkretnego modelu drukarki. Dzięki temu pliki PostScriptu można składować, przenosić między komputerami itp. W zasadzie jest trochę podobny do dokumentów PDF. Jest formatem tekstowym, można go zmieniać zwykłym edytorem, choć ze względu na złożoną składnię nie jest to zadanie dla zwykłych śmiertelników.
Ale znajomość tych detali nie jest aż tak ważna... ważniejsze jest to, że
poleganie na postscripcie jako "medium drukarkowym" wykształciło
w Linuksie kilka interesujących cech, które mogą okazać się bardzo pomocne
w pracy z drukarką. Po pierwsze, każdy program który ma funkcje drukowania
będzie produkował postscript. Czasem będzie też w stanie utworzyć inne formy, ale
postscript zawsze będzie podstawą. Plik postscriptowy można odłożyć "na
później", można go też przesłać znajomemu aby wydrukował na swojej drukarce
- znajomy nie musi posiadać konkretnej aplikacji w której edytowano
dokument.
PostScript można obejrzeć przed wydrukiem, najczęściej jakąś
wygodną nakładką na ghostscript, jak gv czy ggv. To tworzy w systemie coś
w rodzaju uniwersalnego "podglądu wydruku". PostScript jest dokładnie
opisany, więc powstało dużo narzędzi mogących go modyfikować. Plik
postscriptowy można zmieniać na wiele sposobów - dużo narzędzi znajduje się
w pakiecie psutils - pozwalają one wyciąć z "wydruku" konkretne
strony, zmieniać ich orientację, kolejność, a nawet przeskalowywać ściskając
np. po 4 strony wydruku na jednej stronie fizycznej (druk w pomniejszeniu)
- przydaje się to często gdy aplikacja w której tworzymy dokument takich
opcji nie posiada.
To uzależnienie od postscriptu powoduje, że najlepszą drukarką będzie taka ze sprzętowym interpreterem tego języka. Pozwala to pominąć proces konwersji (ghostscript) co podwyższa jakość wydruku i go przy okazji skraca czas drukowania. Ale jak większość ideałów jest to rzadko spotykany przypadek, barierą jest zawsze cena - wbudowanie sprzętowego interpretera PS znacznie podnosi cenę urządzenia.
Spooler?
Warto sobie postawić tu to pytanie. Rezygnacja ze spoolera wydruku często jest możliwa. Traci się wtedy od razu "magiczny filtr" i kolejkowanie wydruków, ale wielu użytkowników być może wcale tych cech nie potrzebuje na swoich domowych maszynkach. A wyrzucenie spoolera powoduje skrócenie procesu drukowania, zmniejszenie zużycia zasobów maszyny oraz eliminuje etapy pośredni który trzeba konfigurować - w rezultacie może uprościć "ustawianie" drukarki w środowisku typowo domowym.
Skoro odpada spooler, to dane pochodzące z aplikacji powinny być albo kierowane bezpośrednio na drukarkę (w przypadku drukarki postscriptowej), albo (bardziej prawdopodobne) do ghostscriptu celem obróbki, i dopiero z niego na drukarkę. Jest to drastyczne uproszczenie całego uniksowego procesu drukowania... ale jeśli to komuś wystarcza, to może warto się skusić.
Ja się skusiłem. Kluczem do sukcesu jest wypracowanie takiego wywołania ghostscriptu, które weźmie dane postscriptowe i zwróci strumień w formacie zrozumiałym dla naszej drukarki. Nie jest to specjalnie trudne, a z pomocą LinuxPrinting.org robi się już całkiem łatwe. Krok pierwszy to znalezienie opisu konkretnej drukarki. Ja mam akurat HPLaserJet 5L, znalezienie nie jest problemem. Ze strony opisującej drukarkę można dowiedzieć się, jakie sterowniki są dostępne - zwykle będzie to któryś z modułów ghostscriptu, czasem też i inne możliwości (np. kolorowe plujki Epsona zwykle znakomicie działają na sterownikach gimp-print). Dla mojej drukarki strona wymienia kilka różnych możliwości, to dobrze (alternatywy znacznie zwiększają szanse na powodzenie, poza tym są dowodem, że dodanie wsparcia dla tej drukarki nie wymagało jakiegoś strasznego czarowania, więc powinna bardzo ładnie chodzić). Któryś ze sterowników będzie zawsze szczególnie zalecany ("recommended") - w przypadku mojej drukarki jest to sterownik ljet4, typu ghostscript. LinuxPrinting ma bardzo dobrze zaprojektowane strony informacyjne, zawierają oprócz listy każdego ze sterowników także jego opis oraz inne linki/informacje.
Dobrze, więc ja się skuszę na ten sterownik. Klikam na jego nazwę i zostaję przeniesiony na stronę zawierającą informacje o nim (już nie o konkretnej drukarce, ale o konkretnym sterowniku - jeden sterownik może być w stanie obsłużyć dziesiątki różnych drukarek, więc każdy ma na LinuxPrinting swoją dedykowaną stronę).
Na tej stronie mam możliwość wygenerowania i pobrania plików PPD dla praktycznie wszystkich popularnych spoolerów wydruku (wystarczy wybrać konkretny model z rozwijanej listy), można też przeczytać ogólne informacje dotyczące konfiguracji każdego spoolera. Fajno, ale ja nie chcę spoola. Na szczęście jest tam osobna pozycja, "Execution details" która dostarcza danych niezależnych od konkretnego systemu drukowania - czyli to, czego szukam. Z rozwijanej listy wybieram swój model (HP LaserJet 5L), klikam na "Show execution details" i dostaję na tacy to, czego szukam: praktycznie gotowe wywołanie ghostscriptu. Łatwiej już nie można. Wywołanie jest strasznie długie, ale większość opcji nie jest potrzebna. W wywołaniu są używane zmienne brane w nawiasy ostre - pod wywołaniem jest lista tych zmiennych, razem z opisem oraz dozwolonymi dla tej zmiennej wartościami. Należy po prostu wybrane wartości popodstawiać za zmienne w wywołaniu i powinno być dobrze.
Można też inaczej - próbować dojść samemu jak co ma działać, tak jest chyba najlepiej. Podstawą jest tutaj zrozumienie opcji ghostscriptu. Np. wywołanie proponowane przez LinuxPrinting dla mojej drukarki jest koszmarne. Naprawdę. Używa nawet perla! Ale to dlatego, że umożliwia zmianę każdego dostępnego parametru pracy. Podczas gdy ja nic zmieniać nie chcę, ja chcę drukować w stałej rozdzielczości (drukarka laserowa, więc nie bawię się w wydruki typu "draft") na papierze A4. Naprawdę ważna jest tutaj tylko informacja o użytym sterowniku, resztę mogę sobie doczytać z manuala ghostscriptu.
Po paru eksperymentach dochodzę do wniosku, że gotowy plik PS mogę wydrukować za pomocą dosyć prostego polecenia gs -sDEVICE=ljet4 -sOutputFile=/dev/lp0 -dBATCH -q -dNOPAUSE -sPAPERSIZE=a4 plik.ps czytając od lewej - włączam format wyjściowy "ljet4", plik wyjściowy to "/dev/lp0" (czyli drukarka). Opcje "-dBATCH -q -dNOPAUSE" powodują, że ghostscript nie drukuje nic na ekranie, nie każe potwierdzać po wydrukowaniu każdej strony itp. - jednym słowem przystosowują go do pracy nieinteraktywnej. A pod koniec ustawiam rozmiar papieru na A4 i każę drukować plik "plik.ps"
Nie ustawiam nigdzie rozdzielczości, bo ten sterownik domyślnie pracuje w takiej, która mi odpowiada. Zmieniam rozmiar papieru, bo dla ljet4 domyślnie byłby to "letter". Takie wywołanie jest na moje potrzeby wystarczające i nie powinno się już zbytnio zmieniać. Wywołanie to jednak zakłada istnienie pliku "plik.ps" zawierającego dane do wydrukowania - ale to rzadka sytuacja. Zwykle jest tak, że aplikacja drukuje bez użycia pliku tymczasowego, przesyłając dane rurką (na STDIN programu drukującego). Jak to obejść? Proste, nazwę pliku w wywołaniu gs wystarczy zamienić na - (minus). To zresztą standardowe oznaczenie w światku uniksowych. Wywołanie gs -sDEVICE=ljet4 -sOutputFile=/dev/lp0 -dBATCH -q -dNOPAUSE -sPAPERSIZE=a4 - mogę ustawić jako "polecenie wydruku" np. w OpenOffice i powinno działać, tzn. wydruk powinien lądować na drukarce. Jest to jednak dosyć kłopotliwe rozwiązanie, zwłaszcza gdy chcę tak skonfigurować parę innych aplikacji. Wygodniej jest wepchnąć sobie taką linijkę do jakiegoś skryptu shellowego - wtedy, w razie potrzeby, można łatwo globalnie zmienić opcje drukowania (modyfikując skrypt), no i uzyskuje się przy tym wygodne "ręczne" drukowanie plików postscriptowych za pomocą tego skryptu. Trzeba tylko jakoś rozwiązać jeden konflikt - czasem zajdzie potrzeba wydrukowania pliku na dysku (zwykle przy ręcznym wywołaniu), a czasem pliku przyjmowanego z STDIN (zwykle gdy skrypt jest wywoływany przez jakąś aplikację). Ja rozwiązałem to "na szybko" w prosty sposób - w skrypcie nie ma zapisanej nazwy pliku, jest ona przekazywana dopiero w momencie wywołania skryptu. Ja swój skrypt nazwałem "printps" (odradzam samo "print", bo jest już takie polecenie :) Mój printps wygląda tak: #!/bin/sh gs -sDEVICE=ljet4 -sOutputFile=/dev/lp0 -dBATCH -q -dNOPAUSE -sPAPERSIZE=a4 $@ Jak widać zastąpiłem nazwę pliku super-zmienną $@ która w obrębie skryptów zawiera wszystkie argumenty przekazane skryptowi w linii poleceń. Dzięki temu mogę wydrukować pojedynczy plik .ps za pomocą printps plik.ps ale mogę też przyjąć dane z STDIN, np. tak: cat plik.ps|printps - Można by to oczywiście zautomatyzować, ale to by jedynie komplikowało skrypt który z założenia miał być "minimalny". Dodatkowo dzięki $@ mogę podać, w razie potrzeby, dodatkowe opcje do wywołania gs (choć przyznam, że "potrzeba" jeszcze się nie pojawiła ani razu). Integracja z aplikacjami jest prosta - jako "polecenie wydruku" podaję "printps". To zakłada, że aplikacja tworzy gdzieś plik tymczasowy i dodaje jego nazwę do wywołania printps. Część programów tak robi. Ale jeśli to nie zadziała (nic się nie będzie drukowało), to zapewne aplikacja próbuje wrzucić dane rurką - wtedy wystarczy zmienić dla tej aplikacji "printps" na "printps -" i już powinno być dobrze.
To podejście ma, mimo amputacji zaawansowanych możliwości (kolejkowanie itp.) swoje dobre strony - zaczyna się od najniższego możliwego poziomu, co znacząco zmniejsza szanse na niepowodzenie (bo co można zepsuć w czymś tak prostym, jak jednolinijkowe wywołanie ghostscriptu?) i każdy błąd od razu jest kwitowany stosownym komunikatem w shellu, więc szybko wypracowuje się działające rozwiązanie. Jeśli ma się kilka "konfiguracji" drukarki których się regularnie używa (np. różne rozdzielczości wydruku), to można po prostu stworzyć sobie drugi skrypt drukujący, w OpenOffice można go sobie wtedy skonfigurować jako kolejną drukarkę...
Magic Filter:
Funkcjonalność "magicznych filtrów" daje się łatwo imitować, jeśli ktoś potrzebuje np. łatwego drukowania plików graficznych może skonstruować sobie skrypt który najpierw weźmie zadany plik, zamieni go na postscript używając np. programu "convert" z pakietu ImageMagick i dopiero potem wydrukuje. Interesujące w "magic filters" jest to, że nie są chyba w ogóle na tyle często potrzebne by je tworzyć ;)
Uderzę tu w jeden punkt konwersji danych na postscript - myślę o konwersji zwykłego tekstu. Sporo programów operuje na czystym tekście, np. mutt, slrn i inne. PostScript oferuje wiele możliwości "upiększenia" tekstu, więc czemu by z tego nie skorzystać? Najlepszy w tej dziedzinie jest IMO program a2ps, który nie dość, że konwertuje ascii do .ps, to jeszcze potrafi kolorować specyficzną składnię (np. zaznaczy nagłówki w wydruku emaila), używać wzorców kolorystycznych, różnych fontów, obsługuje iso8859-2, potrafi wstawiać po kilka stron wydruku na jedną stronę fizyczną, jednym słowem - kombajn. Podpina się go jako polecenie wydruku (zamiast standardowego lpr) w konkretnej aplikacji (np. w slrn) i to wszystko. W konfiguracji a2ps można, jako jego polecenie wydruku, ustawić sobie nasz wystrugany ręcznie printps i koło się zamyka.
Czy istnieje alternatywa dla PostScriptu?
Nie, nie ma tu raczej alternatywy, a w każdym razie takiej, która by była godnym zastępcą. Jest jednak coś... inne języki opisu strony. Niektóre drukarki posługują się językami które również są branżowymi standardami. Jednym z nich jest PCL, wspierany w różnych odmianach przez wiele, wiele drukarek. Niektóre programy potrafią, obok postscriptu, produkować także alternatywne formy - jak np. PCL. Potrafi to robić np. (La)TeX (zaawansowany skład tekstu), groff (wydruki dokumentacji) czy gnuplot (wydruki wykresów). Jeśli nie masz szans na drukarkę wspierającą PostScript, to może chociaż staraj się dostać taką obsługującą PCL. Wsparcie bezpośrednio dla PCL nie jest tak częste wśród programów, ale czasem pozwala skrócić proces drukowania. Aplikacja tworzy plik PCL który wrzuca się bezpośrednio na urządzenie drukarki. Wydruk idzie szybciej (oszczędza się czas konwersji), jakość może być ciut lepsza itp. Jeśli ktoś będzie musiał wybierać pomiędzy dwoma drukarkami non-postscript, to wsparcie dla PCL należy sobie wysoko cenić (poza tym PCL jest znanym powszechnie standardem co ułatwia programistom tworzenie porządnych sterowników)