Tisk v přesném měřítku (PDF, PPD, CUPS)

Možná jste taky někdy zápasili s tiskem formulářů nebo šablon, které pořád ne a ne vyjít ve správné velikosti. Článek Tisk v přesném měřítku (PDF, PPD, CUPS) popisuje příběh hledání jedné takové chyby v GNU/Linuxu.

1.7.2020 22:11 | xkucf03 | Zajímavý článek

Komentáře

[Martin Mareš]

To je nečekaně častý problém. Už dávno jsem si vyrobil jednoduchou postscriptovou testovací stránku pro kalibraci tiskáren. Hledání chyb typicky začínám tím, že vytisknu tento soubor pomocí lp. Tím se snadno odliší chyby aplikací od chyb print serveru / tiskárny.

[xkucf03]

Už dávno jsem si vyrobil jednoduchou postscriptovou testovací stránku pro kalibraci tiskáren.

Vyrobil jsem podobnou stránku (je v příloze blogu), ale ne tak pěknou, díky.

To je nečekaně častý problém.

To mne na tom právě trápí asi víc než to, že jsem zrovna nemohl vytisknout dokument v měřítku. Proto jsem vlastně kolem toho psal ten článek, byť to řešení samotného problému je celkem triviální. Tohle se opakuje často a na různých místech, nejde jen o tisk, je to obecný problém s kvalitou – něco se rozbije a nikdo¹ si toho nevšimne, opraví se to až po letech a pak klidně rok nebo déle trvá, než se ta oprava dostane do distribucí, které používají běžní uživatelé.

_{[1] resp. oni si toho všimnou ti uživatelé, kteří pak dotyčný software třeba přestanou používat, ale nikde to nenahlásí jako chybu, takže z pohledu vývojářů žádný problém neexistuje}

[vencour]

Nebylo by lepší dát to do článku nebo do blogu? Neztratí se to tady?
Jo, kalibrace je základ.
A dííík za kvalitní čtení.

[debian++]

pokud byste hledali ve své distribuci PPD soubory pro nenainstalované tiskárny, tak je pravděpodobně nenajdete. Místo nich tam máte /usr/lib/cups/driver/openprinting-ppds, což je skript v Pythonu, který v sobě má textovou proměnnou s velmi dlouhým řetězcem (celý ten skript má přes 5 MB) ve formátu Base64, uvnitř kterého jsou zkomprimované všechny PPD soubory. Tohle raději nebudu komentovat. PPD soubory si můžeme vypsat pomocí openprinting list a jeden konkrétní získat pomocí openprinting-ppds cat URI (kde URI začíná openprinting-ppds: a jde o první sloupec z výpisu). Získání jednoho PPD souboru na mém ne úplně pomalém počítači s SSD diskem trvá dva a půl vteřiny. Tím se vysvětluje, proč přidávání nové tiskány přes CUPS není zrovna dvakrát rychlé.

masakr

[kralyk z abclinuxu]

A není to nějaká Debianovina? V Archu máme balíčky s normálními PPD soubory ...

[xkucf03]

Ano, týká se to Debianu a Ubuntu. Docela by mne zajímalo, co je k tomu vedlo.

Ono těch 5 000+ souborů může někoho vyplašit, ale pro souborový ani balíčkovací systém by neměl být reálný problém a výkon by měl být lepší než v Pythonu prohledávat komprimovanou proměnnou zabalenou v Base64.

[R]

To musel robit nejaky dement. Ked uz, tak preco nepouzil jednoducho napr. ZIP?

Inak normalne tlacove drivery pouzivaju .drv subor, z ktoreho si CUPS potrebne PPD vygeneruje pomocou ppdc... Napr. /usr/share/cups/drv/carps.drv

[koroptev]

tak co, v gnome nedavno vyresili volbu fontu, proc ted nefixnout tisk, rok linuxoveho desktopu na pochodu

[xkucf03]

Ono je to rozbité i přímo v té tiskárně:

dávám PDF soubory na USB flashku a nesu je k tiskárně – ta má USB port a nabízí tzv. přímý tisk. Ovládání přes ten malý displej a pár tlačítek je docela použitelné. Tiskárna tiskne… a další makulatura je na světě. Výsledek je o nějaký ten milimetr lepší, ale stále je to celé špatně. Až tak „přímý“ tisk to tedy nebude.

a to je proprietární firmware, se kterým uživatel nic nenadělá. Oproti tomu v GNU/Linuxu je všechno softwarové a protože je to svobodný software, tak to lze opravit. (ano, trvalo to hodně dlouho)

[R]

OMFG, to fakt Okular vola priamo lpr?

Jednym z dovodov, preco som sa z KDE 4 velmi rychlo vratil na 3 bola nefunkcna tlac. To boli zaciatky KDE 4. Zda sa, ze to dodnes nevyriesili. To akoze KDE 4 nema print subsystem? V KDE 3 sa centralne pre vsetky aplikacie zvoli, co sa ma pouzivat (CUPS, external program, LPD, LPR/LPRng, RLPR)...

[xkucf03]

Na druhou stranu, když jsou programy skládané tímhle způsobem a volají se jako podproces, tak se to dá snáze ohackovat, aniž bych musel jít do zdrojáků a něco kompilovat. Můžu si udělat např. skript s názvem lpr, přidat si ho do $PATH a pomocí něj to odladit – jednak se můžu dívat, co jde dovnitř (parametry příkazu, proměnné prostředí, STDIN…), co jde ven (STDOUT, STDERR…), vedlejší efekty monitorovat přes strace… a když se mi něco nelíbí, tak v tom svém skriptu upravím ty parametry a s nimi pak zavolám ten skutečný lpr.

Pokud by to bylo řešené např. přes D-Bus, můžu komunikaci sledovat přes dbus-monitor, ale už nevím, jak do toho vstoupit a přepisovat hodnoty (asi bych musel tu původní službu přesunout a na její místo nasadit nějakou svoji proxy, kterou bych si napsal). Podobné je to s komunikací přes TCP/IP nebo UDP/IP – monitorovat to jde snadno přes Wireshark. Ale vstoupit do té komunikace a upravovat ji, to je trochu víc práce než u těch podprocesů.

Jakou technologií je ten subsystém řešený v KDE 3? Ono by to vlastně šlo řešit přes podprocesy i v případě, že tam bude nějaká abstraktní vrstva, která to bude přesměrovávat dál (CUPS, external program, LPD, LPR/LPRng, RLPR).

[R]

Nikdy som to blizsie neskumal, lebo to vzdy fungovalo. VIdim tam kniznice: /opt/trinity/lib/libtdeprint.so.14 /opt/trinity/lib/libtdeprint_management.so.14 /opt/trinity/lib/trinity/tdeprint_cups.so /opt/trinity/lib/trinity/tdeprint_ext.so /opt/trinity/lib/trinity/tdeprint_lpdunix.so /opt/trinity/lib/trinity/tdeprint_lpr.so /opt/trinity/lib/trinity/tdeprint_rlpr.so /opt/trinity/lib/trinity/tdeprint_tool_escputil.so (je to teda TDE, nie stare KDE 3)

Asi to nebude nic zlozite. Aplikacie vraj generuju postscript - takze ten sa pravdepodobne podhodi nejakej funkcii z kniznice tdeprint a ziadne detaily uz aplikaciu nezaujimaju.