page header photo

september 2017 Archieven

Nabedrukt briefpapier revisited: je kunt de boom in!


Geplaatst door gait op 2017-09-25 12:52:24 | Permanente link | Categorie: Systeembeheer, Tips and Tricks | Reacties: 0

Een paar blogs geleden beschreef ik hoe nabedrukt briefpapier geĆÆmplementeerd is. Door deze voorziening is voorbedrukt briefpapier niet meer nodig is: alles wat je afdrukt kun je van een 'stempel' kunt voorzien: een logo, een briefhoofd, een grafische achtergrond.

De belangrijkste applicatie daarbij was OpenOffice. dat zich evenals vele andere applicaties niet bewust is van het fenomeen 'printer instance'. Dit geldt helaas ook voor LibreOffice.

Printer instance

Zo'n printer instance is een combinatie van een bepaalde generieke printer met bepaalde voorgekookte zelf te kiezen opties. In plaats van

lp -d printer -o sides=two-sided

zeg je, om dubbelzijdig af te drukken:

lp -d printer/duplex

zonder dat je hoeft te weten hoe die optie er voor die printer uit ziet.

Dat is voor de gebruiker wel zo simpel. Dat heeft de systeembeheerder al voor je uitgezocht en globaal vastgelegd in het bestand /etc/cups/lpoptions:

Dest printer/duplex ... sides=two-sided ...

In dit geval geldt voor alle printers dezelfde optie omdat dubbelzijdig/enkelzijdig met een generieke optie bij lp ingesteld wordt en CUPS weet door het Postscript-Printer-Description-bestand dat voor de printer gebruikt wordt (PPD) hoe dat voor een bepaalde printer geregeld moet worden.

Printerclass

En stel, een nieuwe printer wordt in gebruik genomen: Als de gebruikers niet een printer maar een printerclass gebruikten dan verandert er voor hen niets (nou ja, die gebruiker moet het papier uit die nieuwe printer halen) want je vervangt in die printerclass de printers. Je moet dat wel voor die printerclass de opties aanpassen voor de nieuwe printer.

Printerspecifieke opties

Voor zoiets als de keuze van de invoer (een bepaalde papierbak of handinvoer) bestaan geen generieke opties. Daarvoor kun je dus een 'generieke' instance maken die voor elke printer geldt doch per printer specifieke opties oplevert.

Die specifieke opties zie je samen met de mogelijke waarden zo:

lpoptions -dprinter -l

(zonder die -l krijg je de niet-specifieke generieke opties).

OpenOffice presenteert in de Afdrukken-GUI weliswaar printer instances maar daar blijft het bij: welke instance je kiest maakt geen verschil hetgeen wijst op een halfslachtige implementatie als CUPS-client. Sommige PDF-viewers hebben daar ook een handje van: ze maken je blij met een dode mus. Soms laten ze voor elke instance alleen de naam van de printer zien, zelfs de / en de rest blijft weg. Lastig kiezen dus ... Behalve de PDF-viewer Okular: die doet het wel goed!

Gelukkig kun je in OpenOffice je eigen printers definiƫren (psprint.conf) en daar (lp-)commando's aan koppelen: heel flexibel, en door er meteen een goede omschrijving aan te koppelen help je de gebruikers aardig op weg Immers: die omschrijvingen worden getoond bij de Afdrukken-interactie. Het commando lp is natuurlijk wel een voorbeeldige CUPS-client.

'Je kunt de boom in'

Er blijven ook applicaties over waarbij je niets aan instances hebt. Een weg die ik bepaald niet op wilde gaan is het omzetten van alle printer instances in even zovele generieke printers. Dat zouden collega systeembeheerders mij niet in dank afnemen, immers: omdat printers en printer instances altijd allemaal opduiken bij lpstat stuiten die al op genoeg weerstand. Het zou nogal wat werk zijn: je moet dan per printer een aparte PPD maken met bepaalde standaard instellingen en dan nog kun je daarmee niet alle opties afdekken. Verder heb je langs die weg ook te weinig invloed op de CUPS filterketen. Niet leuk dus.

Toen kreeg ik een brainwave: die printer instances, als je die nu eens op een directory boom afbeeld? Applicaties kunnen immers bestanden opslaan (zelfs als ze niet kunnen afdrukken!). Dan laat ik de gebruiker een bestand opslaan in die printer instances directory. Het assortiment ligt vast en ze zien bij de opslaan-interactie waar ze uit kunnen kiezen. In de directory printer1 staan dan als subdirectories: algemeen/ algemeenenkelz/ certificaat-en/ certificaat-nl/ enkelzijdig/ factuur-bedrijf-x/ factuur-bedrijf-y/ lade1/ lade2/ lade1enkelz/ lade2enkelz/ logo/ Onder water zorg ik ervoor dat zo'n opgeslagen bestand opgevat wordt als printjob. Daarvoor is inotifywait(1) uit het pakket inotify-tools nodig. Daarmee wacht je recursief tot een bepaald evenement in die boom voorbij komt, je drukt het bijbehorende bestand af naar de printer instance die overeenkomt met de plek in de boom, en je haalt het daarna meteen weg. Etcetera! Dat evenement dat inotify rapporteert moet je wel zorgvuldig selecteren: het gaat om het sluiten van een bestand (geen directory) dat voor schrijven geopend was.

De gebruiker mist zodoende bij het opslaan de normale instelmogelijkheden voor het afdrukken maar die zijn als het goed is afgedekt door het hele assortiment instances. Mocht een gebruiker heel vaak een document 23 maal moet afdrukken dan maak je daar een aparte instance voor:

Dest    kleurenprinter/23exemplarenuitbak1    ... copies=23 ... InputSlot=Tray1 ...

Werk je vanaf een Linux-systeem met RDP in een Windows-omgeving dan hoef je --hoewel dat met Samba niet zo moeilijk is-- de lokale printers niet aan 'de andere kant' beschikbaar te stellen: als de remote applicatie naar een lokaal PDF-bestand kan opslaan of afdrukken moet je daarvoor dus een plek in die lokale boom met printer instances kiezen (die lokale boom moet dan natuurlijk wel remote beschikbaar zijn).

Speciaal voor die collega systeembeheerders: net als in iedere andere boom werkt tab-completion hier ook. Waarover meer in een volgende blog.

En als je zegt 'waarom vandaag de dag nog zoveel moeite voor een papieren afdruk': er zijn ook PDF- en e-mailprinters waarmee je kunt nabedrukken.