Die Notwendigkeit eines Druckertreibers ist eine etwas exotische Anforderung an einen Webserver. Ein physischer Drucker ist natürlich nicht vorhanden, und viele PaaS-Anbieter haben Druckertreiber und die Druckerwarteschlange entweder aus Leistungs- oder aus Sicherheitsgründen entfernt (siehe z.B. den berüchtigten PrintNightmare CVE). Daher hatten Sie vor Version 27 keinerlei Möglichkeiten, List & Label ohne mühsame Workarounds (wenn diese überhaupt verfügbar waren) in solchen Umgebungen zu verwenden.
Für Version 27 haben wir endlich eine Lösung gefunden. Diese großartige neue Funktion – Sie merken, ich werde etwas euphorisch – fügt sich sehr gut in die anderen Web/Cloud-Funktionen der kommenden Version 27 ein. Aber sie bietet auch ein verstecktes Juwel für Desktop-Entwickler. Also lesen Sie weiter, es lohnt sich in jedem Fall für Sie.
Azure App Service und Docker
Azure App Service ist die mit Abstand beliebteste Hosting-Plattform bei unseren Kunden. Allerdings mussten Sie bisher eine vollwertige virtuelle Maschine inklusive RDP-Zugang buchen, um die Druckerwarteschlange zu starten und einen Druckertreiber zu installieren. Eine Schritt-für-Schritt-Anleitung finden Sie hier. Diese Lösung bedeutet nicht nur mehr Arbeit, sie ist auch wesentlich teurer. Außerdem sind nicht alle Funktionen der Deployment-Pipeline in Visual Studio nutzbar.
Aus Sicherheitsgründen können Sie zwar immer noch keine Anwendungen direkt im App Service bereitstellen, (GDI ist dort leider gesperrt, Details siehe hier), aber Microsoft ermöglicht es, diese Einschränkung zu umgehen. Dafür müssen Sie Ihre Anwendung lediglich in einem Windows-Docker-Container hosten. Sie benötigen nur eine Pv3 Azure-Instanz, um mit Windows-Containern zu arbeiten.
In diesen Umgebungen schaltet List & Label von nun an automatisch auf den neuen Printerless-Modus um. Sie werden keinen Unterschied bemerken. Alles funktioniert weiter wie bisher. Es kann vorkommen, dass sich das Layout im Vergleich zu einem Ausdruck geringfügig ändert. Möglicherweise müssen Sie auch Ihre Schriftarten in den Container übertragen, wenn Sie ein Windows Core-Basis-Image verwenden, da Microsoft mit diesem Image keine Schriftarten ausliefert.
Desktop
Sie können auch die Desktop-Version auf den Printerless-Modus umstellen. Dafür müssen Sie nur die neue globale Option LL_OPTION_PRINTERLESS auf 1 setzen (d.h. Sie setzen die Option vor dem Öffnen des ersten Jobs und verwenden -1 als Jobhandle). Falls Sie eine Komponente verwenden, setzen Sie einfach LL.Printerless auf true. Dies führt zu einer Reihe von Änderungen in der Benutzeroberfläche.
Im Dialogfeld Layout-Bereiche wird ein neuer Drucker mit der Bezeichnung „Virtuelles Gerät“ angezeigt:
Dieses Gerät verfügt im Grunde genommen über alle Funktionen, die ein „normaler“ Drucker hat. Das ist wichtig, wenn Sie eine Vorschaudatei erstellen, die später auf einem physischen Drucker ausgedruckt werden soll. Auf diese Weise können Sie bequem die Standardeinstellungen für den folgenden Ausdruck festlegen. Außerdem bietet es eine weitere tolle Funktion: Sie können das Druckerformat jederzeit auf benutzerdefiniert setzen und einfach die gewünschten Abmessungen für Ihr Layout eingeben:
Damit sind beliebige Projektgrößen realisierbar, ohne dass ein Druckertreiber diese Größen unterstützen muss. Keine überraschenden Workarounds mehr. Einfach eine saubere Lösung. Genial, oder? Ich bin tatsächlich immer noch begeistert und freue mich, dass eine der größten Einschränkungen endlich beseitigt ist.
Prima Lösung – werden wir für den verdecken Export von PDF’s nutzen. Dort haben uns die Kunden mit irgendwelchen schrottigen Druckertreiben z.B. für Etikettendrucker regelmässig Probleme verursacht.
Ja, gerade bei reinem Export war auch die Motivation für „warum brauche ich denn einen Druckertreiber“ nicht immer leicht vermittelbar :).
Wir haben inzwischen übrigens noch eine Option implementiert, mit der die Ausgabequalität im druckertreiberlosen Modus beeinflusst werden kann:
LL_OPTION_PRINTERLESSDEVICE_SCALINGOPTIONS (379)
0: Das Projekt wird 1:1 in der gewählten Größe mit dem Bildschirm-Gerätekontext als Referenz gerendert mit der Auflösung/Größe des Bildschirm-Kontexts – kann zu Ungenauigkeiten in der Plazierung von Ausgaben führen, wenn diese über die Device-Koordinaten berechnet werden (Voreinstellung)
1: Die Auflösung für die Ausgabe wird so umgerechnet, dass sie optimal auf die Größe des Bildschirm-Gerätekontexts eingepasst ist
2: Die Auflösung für die Ausgabe wird so umgerechnet, dass sie genau auf die Größe des Bildschirm-Gerätekontexts passt, sofern die Auflösung hierfür nicht verkleinert werden muss
3: Die Auflösung für die Ausgabe beträgt 600 DPI, wird also entsprechend „hochgerechnet“
Diese Option ist wichtig, falls der Gerätetreiber (oder Windows) Objekte ignoriert, die außerhalb des „zur Verfügung stehenden“ Device-Bereichs sind. Eine zu kleine Vergrößerung kann zu „schlechter“ Plazierungsgenauigkeit von Ausgaben führen, eine zu große (Optionswert 3) zu nicht ausgegebenen Objekten oder Teilen davon. Sie sollten die Ergebnisse auf jeden Fall in der Zielumgebung prüfen.