लेबल प्रिंटर DPI के बारे में झूठ बोलता है
एक ओपन-सोर्स Web Bluetooth ड्राइवर से पता चलता है कि Niimbot का N1 लेबल प्रिंटर, जिसे 300 dpi डिवाइस के रूप में विज्ञापित किया गया है, वास्तव में लगभग 203 dpi पर प्रिंट करता है।
डेवलपर ने Niimbot के मोबाइल ऐप का उपयोग करने के बजाय सीधे वेब पेज से प्रिंट करने के लिए यह ड्राइवर बनाया। उसने प्रोप्रायटरी प्रोटोकॉल को रिवर्स-इंजीनियर किया और Web Bluetooth API के माध्यम से इसे ब्राउज़रों के लिए उपलब्ध कराया। ऐसा करते समय, उसने न केवल एक गायब फीचर बल्कि एक मौलिक गलत विनिर्देश (mis-specification) की भी खोज की, जो छोटे बैच की पैकेजिंग, इन्वेंट्री टैग, या उन हॉबी प्रोजेक्ट्स को खराब कर सकता है जहाँ सटीकता मायने रखती है।
गलत विनिर्देश (mis-specification) कैसे सामने आया
Niimbot N1 को 300 dpi प्रिंटर के रूप में मार्केट करता है, जिसका अर्थ है प्रति इंच 300 डॉट्स। डेवलपर ने एक रूलर-स्केल इमेज और एक नंबर वाला टेस्ट पैटर्न प्रिंट किया, फिर एक भौतिक रूलर से निशानों को मापा। गणना लगातार लगभग 203 dpi की ओर इशारा कर रही थी, न कि दावे के अनुसार 300 की।
हार्डवेयर ड्राइवर लिखने से मिले चार कठिन सबक
एक "सफल" जॉब कुछ भी परिणाम नहीं दे सकती। प्रिंटर डेटा को बर्स्ट (bursts) में स्ट्रीम करता है। कुछ प्लेटफॉर्म्स पर ब्लूटूथ स्टैक बिना किसी एरर की रिपोर्ट किए 'राइट' (write) ऑपरेशन को ड्रॉप कर देता है। ड्राइवर मान लेता है कि काम पूरा हो गया है, फिर भी लेबल खाली या कटा हुआ निकलता है। लेखक अब प्रत्येक जॉब के बाद यह सत्यापित करने के लिए प्रिंटर के फिजिकल पेज काउंटर को पढ़ता है कि शीट वास्तव में फीड हुई थी या नहीं।
डॉक्यूमेंटेशन वास्तविकता नहीं है। 300 dpi का दावा इसका एक स्पष्ट उदाहरण है। स्पेसिफिकेशन आशावादी, पुराने या बस गलत हो सकते हैं। जब विजुअल फिडेलिटी (visual fidelity) मायने रखती है, तो डेवलपर्स को महत्वपूर्ण मापदंडों को स्वयं मापना चाहिए।
"फिट" टेस्ट से बेहतर फिजिकल मार्क्स होते हैं। यह देखने के लिए कि क्या इमेज लेबल एरिया में फिट बैठती है, इमेज प्रिंट करना रेजोल्यूशन, प्रिंटहेड की चौड़ाई या ऑफसेट एरर को छिपा देता है। एक ज्ञात ज्यामितीय (geometric) मार्क प्रिंट करना और उसके सटीक स्थान को मापना डिवाइस के वास्तविक व्यवहार को प्रकट करता है।
एक प्रोटोकॉल व्याकरण (grammar) बताता है, हार्डवेयर का स्वभाव नहीं। दो प्रिंटर एक ही कमांड सेट साझा कर सकते हैं फिर भी अलग तरह से व्यवहार कर सकते हैं—एक तेजी से पेज रिपीट को संभाल सकता है, जबकि दूसरा रुक सकता है। ड्राइवर केवल प्रोटोकॉल डॉक्यूमेंटेशन के आधार पर समान प्रदर्शन का अनुमान नहीं लगा सकता; प्रत्येक मॉडल को रियल-वर्ल्ड टेस्टिंग की आवश्यकता होती है।
यह ड्राइवर क्यों महत्वपूर्ण है
ड्राइवर कभी भी सब कुछ जानने का ढोंग नहीं करता। जब भी यह प्रिंटर से पढ़ने के बजाय किसी वैल्यू का अनुमान लगाता है, तो यह उस फील्ड को एक 'अनुमान' (guess) के रूप में फ्लैग कर देता है। यह पारदर्शिता उन साइलेंट एरर्स (silent errors) को रोकती है जिनमें अन्यथा घंटों की डीबगिंग लग सकती थी।
ड्राइवर प्राप्त करना
ड्राइवर Chrome या Edge में चलता है और इसके लिए केवल एक ब्लूटूथ-सक्षम डिवाइस और एक समर्थित Niimbot प्रिंटर की आवश्यकता होती है। लाइव डेमो यहाँ आज़माएँ:
https://iscarelli.github.io/niimbot-web-bluetooth/demo/
सोर्स कोड GitHub पर उपलब्ध है, जहाँ समुदाय मॉडल डेटा में योगदान दे सकता है, बग्स को ठीक कर सकता है, या अन्य ब्राउज़रों के लिए ड्राइवर को अनुकूलित कर सकता है:
https://github.com/iscarelli/niimbot-web-bluetooth
Niimbot के मालिक मॉडल डेटाबेस को भरने में मदद कर सकते हैं; इस प्रक्रिया में लगभग दस मिनट और दो लेबल लगते हैं।
प्रतिवाद (Counterpoint)
जब तक कंपनी इस विसंगति को स्पष्ट नहीं करती, डेवलपर्स को मापे गए मान (measured value) के साथ ही काम करना होगा।
निष्कर्ष सरल है: वेब पेज से जिसे आप कॉल करते हैं, वह हार्डवेयर वैसा नहीं कर सकता जैसा उसका स्पेसिफिकेशन शीट वादा करती है। महत्वपूर्ण मापदंडों को सत्यापित करें, साइलेंट फेलियर की अपेक्षा रखें, और ऐसे ड्राइवर चुनें जो अनिश्चितता को छिपाने के बजाय उसे उजागर करें।