Neden Gerçek Bir XPSDrv v4 Windows Sürücüsü İnşa Ettik — Yine Bir Sanal Port Değil

Microsoft Word'den bir etiket yazdırmaya çalıştıysanız bu deneyimi bilirsiniz. Windows yazdırma diyaloğu açılır. Yazıcılar listesinde ilerlersiniz. "Microsoft Print to PDF", "Microsoft XPS Document Writer" ve "BT ekibinin 2017'de çalıştırdığı" eski Zebra GK420d vardır. Zebra'yı seçersiniz. Yazdır'a basarsınız. Diyalog kilitlenir. On iki saniye sonra istediğinizin yarısı kadar büyüklükte ve 90 derece ters dönmüş bir etiket çıkar.

Bu deneyim Word'ün suçu değildir. Son yirmi yılda hemen her termal etiket yazdırma uygulamasının kolay yolu seçmesinin sonucudur: sanal port. Sanal port, gerçek bir yazıcıymış gibi davranan bir yazılım katmanıdır; o porta gelen veri, gerçek etiket yazdırma uygulamasına aktarılır ve uygulamanın bununla ne yapacağını çözmesi beklenir. Word, gerçek bir yazıcı olmadığını bilmez. Word standart letter boyutunda XPS sayfaları gönderir. Etiket yazdırma uygulaması ölçeklemeye, döndürmeye ve kırpmaya çalışır — ve ortaya çıkanı çıkarır.

LabelInn daha zor yolu seçti. Gerçek bir Microsoft XPSDrv v4 yazıcı sürücüsü inşa ettik. v3 Unidrv değil, v4 sürücüsü olarak kayıt olur. Windows baskı boru hattının doğru noktasında XPS spool akışına müdahale eden bir render filtresi uygular. Kullanıcının gerçek etiket boyutları Windows yazdırma diyaloğunda görünsün diye dinamik bir medya kütüphanesi yayımlar. Baskı tercihleri arayüzünün uygulamamızdan çıkan bir pop-up değil, gerçek bir yerel Windows diyaloğu olması için printer extension'lar destekler. Ve tek bir sürücü kurulumundan birden fazla fiziksel yazıcıya yönlendirme yapar.

Bu yazı, bu kararların neden önemli olduğunun, neyi mümkün kıldığının ve maliyetinin geliştirici odaklı açıklamasıdır.

Windows'a etiket yazıcısı enjekte etmenin iki yolu

Seçenek A — sanal port (herkesin tercihi)

Sanal port, Windows'a yazıcı olarak kayıt olan ama aslında etiket yazdırma uygulamasına yönlendirilmiş bir adlandırılmış pipe veya TCP dinleyici olan bir yazılım katmanıdır. Uygulama, Windows'un gönderdiği her şeyi — tipik olarak XPS sayfa akışını veya bir GDI rasterizasyonunu — almak ve ortaya hangi etiketi çıkaracağını çözmek zorundadır. Uygulamanın kullanıcının gerçekten ne istediğine dair sıfır meta verisi vardır: hangi şablon, hangi yazıcı, hangi malzeme rolü.

Kullanıcıya yansıyan başarısızlık modu: bu şekilde üretilen her etiket bir tahmindir.

Seçenek B — gerçek bir v4 sürücüsü (LabelInn'in tercihi)

v4 sürücüsü, Windows baskı yığınının birinci sınıf bir bileşenidir. Yapısal meta veri, baskı tercihleri arayüzü, dinamik medya desteği, render filtreleri, port monitörleri ve printer-extension uygulamaları vardır. Windows'un yazdırmayı bildiği her uygulamayla doğru çalışır çünkü baskı sisteminin tasarlandığı protokolü konuşur.

Kullanıcıya yansıyan davranış: Word'de LabelInn sürücüsü bir yazıcı olarak görünür. Yazdırma diyaloğu kullanıcının yapılandırdığı gerçek etiket boyutlarını listeler. Kullanıcı bir etiket boyutu seçer. Yazdır'a tıklar. Sürücü XPS spool akışını yakalar, termal yazıcı komutlarına dönüştürür ve bu komutları kullanıcının yapılandırdığı fiziksel yazıcıya yönlendirir. Tahmin yok, kırpma yok, dönüş sürprizi yok.

Dört hareketli parça

1. Render filtresi

Render filtresi, Windows baskı boru hattında spooler ile port monitörü arasında oturan yerel (C++) bir bileşendir. XPS sayfalarını alır ve bir sonraki aşama için çıktı üretir. Bizimkisi, sayfa içeriğini, kullanıcının baskı tercihlerini ve hedef yazıcı kimliğini kodlayan yapısal bir yük üretir ve bu yükü kullanıcı oturumunda çalışan LabelInn uygulamasına adlandırılmış bir pipe üzerinden iletir.

Render filtresi yük taşıyan parçadır. Windows'un XPS'i doğru anlamsal düzeyde yakalamanıza izin verdiği tek yerdir — çok erken yakalarsanız ham uygulama tarafı render'ını görürsünüz; çok geç yakalarsanız dizilmiş içeriği kaybetmişsiniz olur. Filtre performanslı olmak zorundadır, bozuk XPS'e dayanıklı olmak zorundadır ve LabelInn uygulaması çalışmıyorsa zarif bir şekilde geri çekilmek zorundadır.

2. Dinamik medya kütüphanesi

v4 sürücüleri dinamik bir medya listesi yayımlayabilir — yazdırma diyaloğunun "kağıt boyutu" açılır menüsü bu listeden doldurulur. Biz onu kullanıcının yapılandırdığı etiket boyutlarından doldururuz. Kullanıcı LabelInn uygulamasında yeni bir etiket boyutu eklediğinde, Word'ün yazdırma diyaloğunda bir sonraki Word açılışında görünür. Sürücü yeniden kurulumu yok, INF düzenlemesi yok, yönetici müdahalesi yok.

Bu, sanal port tasarımlarına göre en büyük kullanıcı deneyimi iyileştirmesidir. Kullanıcının zihinsel modeli — "Bir 4×6 inç kargo etiketim ve bir 2×1 inç ürün etiketim var" — her Windows uygulamasının yazdırma diyaloğunda yansıtılır. İstedikleri boyutu seçerler; etiket o boyutta çıkar.

3. Printer-extension uygulaması

Kullanıcı Windows Ayarlar'da LabelInn yazıcısı için "Yazdırma Tercihleri"ne tıkladığında, Windows printer-extension uygulamamızı başlatır. Bu, yaklaşık bir saniyede açılan ayrı bir Flutter penceresidir; kullanıcının hedef fiziksel yazıcıyı, baskı kalitesini, yönlendirmeyi, yoğunluğu ve yazıcıya özgü seçenekleri seçmesine olanak tanır ve tercihleri sürücünün PrintTicket deposuna geri kaydeder.

Bu iki nedenden ötürü önemlidir. Birincisi, tercih arayüzü Windows'a yerel hissettirir; uygulamamızdan çıkan tuhaf bir pop-up değildir. İkincisi, LabelInn ana uygulamasının kullanıcının tercihleri yapılandırması için açık olması gerekmez. Tercihler işletim sisteminin bir parçası olan sürücüde yaşar.

4. Çoklu yazıcı yönlendirme

Tek bir LabelInn sürücü kurulumu, birçok fiziksel yazıcıya baskı yönlendirebilir. Sürücünün kendisi bir kez kayıt olur. PrintTicket hedef yazıcı kimliğini taşır. Bir baskı geldiğinde, render filtresi PrintTicket'a bakar, doğru fiziksel hedefi seçer ve ortaya çıkan termal komutları buna göre yönlendirir.

Beş farklı operatörde beş Zebra'ya sahip bir ofis için bu, tek sürücü kurulumu, beş printer-extension yapılandırması ve hangi ikonun hangi fiziksel cihazı temsil ettiği konusunda sıfır karışıklık anlamına gelir.

Çevrimdışı spool yedeği — uygulama çalışmadığında

Render filtresi yapısal yükü adlandırılmış bir pipe'a yazar. LabelInn uygulaması çalışıyorsa yükü okur ve yazdırır. Uygulama çalışmıyorsa — kapatılmış, çökmüş, güncelleme ortasında — yük bunun yerine yapısal bir dosya adı ve zaman damgasıyla %ProgramData%\LabelInn\spool\ altında kalıcılaştırılır. Uygulama bir sonraki başlatıldığında spool'u boşaltır ve kuyruktaki işleri sırayla yazdırır.

Bu, gerçek bir başarısızlık modunu çözer: kullanıcı Word'den 16:55'te yazdırır, uygulamanın 16:50'de çöktüğünü fark etmez, kapıdan çıkar ve ertesi sabah etiketin zaten yazdırılmış olduğunu görür çünkü uygulama gece boyunca bir kurtarma işleyicisinden başlamıştır. XPS yükü uygulama yeniden başlatmaları arasında dayanıklıdır.

Bunu doğru yapmanın maliyeti

v4 sürücüsü inşa etmek bir hafta sonu projesi değildir. Windows Driver Kit'in kendi araç zinciri, kendi hata ayıklama hikâyesi ve kendi dağıtım hikâyesi vardır. Sürücü imzalanmak zorundadır; üretim sürümü için bu, kendi başına çok haftalık bir tedarik egzersizi olan bir Extended Validation kod imzalama sertifikası demektir. Windows Update dağıtımı için sürücünün ayrı bir Microsoft Hardware Dev Center gönderimi olan WHQL onayına ihtiyacı vardır.

Mühendislik ekibi için bu aylar süren bir iş ve araçlar ile sertifikalar için on binlerce dolardır. LabelInn müşterileri için maliyet sıfırdır — LabelInn uygulamasını kurarlar, sürücü kendini kayıt eder, entegrasyon biter.

Bunu yapmamızın nedeni, ürün ekibi bütçe verseydi her yerel Windows mühendisinin yapacağı sebeple aynıdır: kullanıcı tarafındaki deneyim — Word'de, Excel'de, SAP'de, QuickBooks'ta, herhangi bir Windows uygulamasında — gerçek bir yazıcının deneyimidir. Her etiket doğru boyuttadır. Her baskı doğru cihaza gider. Kullanıcının "sanal port"un ne anlama geldiğini öğrenmesi gerekmez.

Eski etiket yazılımı kullanan müşteriler için bunun anlamı

Sanal port etiket yazıcısıyla yaşıyorsanız — "yazılımımızı kurun, sonra sanal yazıcı ekleyeceğiz" deneyimlerinden biri — LabelInn sürücüsü göç hedefidir. Eskiden yarım boy çıkan Word belgeleri doğru boyutta çıkar. Ayrı bir etiket tasarım içe aktarımı gerektiren Excel mail-merge'leri doğrudan çalışır. SAP tek seferlik baskıları, betik olmadan doğru yazıcıya yönlendirilir.

Etiket baskı platformlarını değerlendiren bir BT yöneticisiyseniz, demoda sorulacak soru basittir: "Microsoft Word'den 4×6 etiketi doğrudan yazıcınıza yazdırmayı gösterin — doğru boyutta, kırpma yok, dönüş sürprizi yok." Demo Word'ü atlayıp doğrudan satıcının kendi tasarımcısına geçerse, ne inşa ettiklerini bilirsiniz.

Durum

v4 sürücüsü Windows için mevcut LabelInn yapılarında gönderilmektedir. Şu anda staging ortamları için dev-imzalıdır ve genel kullanıma sunum için EV-sertifika imzalama + WHQL gönderimine hazırlanmaktadır. Erken erişim programındaki müşteriler bugün üretim ortamında çalıştırmaktadır.