لیبل پرنٹر DPI کے بارے میں جھوٹ بولتا ہے
ایک اوپن سورس Web Bluetooth ڈرائیور سے معلوم ہوا ہے کہ Niimbot کا N1 لیبل پرنٹر، جسے 300 dpi کا آلہ قرار دیا گیا ہے، حقیقت میں تقریباً 203 dpi پر پرنٹ کرتا ہے۔
ڈویلپر نے Niimbot کی موبائل ایپ استعمال کرنے کے بجائے براہ راست ویب پیج سے پرنٹ کرنے کے لیے یہ ڈرائیور بنایا۔ اس نے پراپرائٹری پروٹوکول کو ریورس انجینئر کیا اور Web Bluetooth API کے ذریعے اسے براؤزرز کے لیے دستیاب کیا۔ ایسا کرتے ہوئے، اسے نہ صرف ایک غائب فیچر کا پتہ چلا بلکہ ایک بنیادی غلط وضاحت (mis-specification) کا بھی سامنا کرنا پڑا جو چھوٹے پیمانے کی پیکجنگ، انوینٹری ٹیگز، یا ایسے شوقیہ پروجیکٹس کو تباہ کر سکتی ہے جہاں درستگی (precision) اہمیت رکھتی ہے۔
غلط وضاحت کیسے سامنے آئی
Niimbot N1 کو 300 dpi پرنٹر کے طور پر مارکیٹ کرتا ہے، جس کا مطلب ہے 300 ڈاٹس فی انچ۔ ڈویلپر نے ایک رولر اسکیل والی تصویر اور نمبروں والا ٹیسٹ پیٹرن پرنٹ کیا، اور پھر ایک جسمانی رولر سے نشانات کی پیمائش کی۔ حساب کتاب مسلسل تقریباً 203 dpi کی طرف اشارہ کر رہا تھا، نہ کہ دعویٰ کردہ 300 کی طرف۔
ہارڈ ویئر ڈرائیور لکھنے سے حاصل ہونے والے چار مشکل سبق
ایک "کامیاب" کام کا نتیجہ کچھ بھی نہ نکلنا۔ پرنٹر ڈیٹا کو وقفوں (bursts) میں بھیجتا ہے۔ کچھ پلیٹ فارمز پر Bluetooth stack بغیر کسی غلطی کی اطلاع دیے ڈیٹا لکھنا (write) چھوڑ دیتا ہے۔ ڈرائیور فرض کر لیتا ہے کہ کام مکمل ہو گیا ہے، لیکن لیبل خالی یا ادھورا نکلتا ہے۔ مصنف اب ہر کام کے بعد پرنٹر کے جسمانی پیج کاؤنٹر کو پڑھتا ہے تاکہ تصدیق کر سکے کہ کاغذ واقعی اندر گیا تھا۔
دستاویزات (Documentation) حقیقت نہیں ہوتیں۔ 300 dpi کا دعویٰ اس کی ایک واضح مثال ہے۔ تفصیلات (Specs) پرامیدانہ، پرانی، یا محض غلط ہو سکتی ہیں۔ جب بصری درستگی (visual fidelity) اہم ہو تو ڈویلپرز کو خود اہم پیرامیٹرز کی پیمائش کرنی چاہیے۔
جسمانی نشانات "فٹ" ٹیسٹ سے بہتر ہیں۔ یہ دیکھنے کے لیے کہ آیا کوئی تصویر لیبل کے حصے میں فٹ آتی ہے یا نہیں، اسے پرنٹ کرنا ریزولوشن، پرنٹ ہیڈ کی چوڑائی، یا آفسیٹ کی غلطیوں کو چھپا دیتا ہے۔ ایک معلوم جیومیٹرک نشان پرنٹ کرنا اور اس کے عین مقام کی پیمائش کرنا ڈیوائس کے اصل طرزِ عمل کو ظاہر کرتا ہے۔
ایک پروٹوکول گرامر بیان کرتا ہے، ہارڈ ویئر کا مزاج نہیں۔ دو پرنٹرز ایک ہی کمانڈ سیٹ استعمال کر سکتے ہیں لیکن ان کا رویہ مختلف ہو سکتا ہے—ایک صفحات کے تیز رفتار تکرار کو سنبھال لیتا ہے، جبکہ دوسرا رک جاتا ہے۔ ڈرائیور صرف پروٹوکول کی دستاویزات کی بنیاد پر یکساں کارکردگی کا فرض نہیں کر سکتا؛ ہر ماڈل کو حقیقی دنیا کے ٹیسٹنگ کی ضرورت ہوتی ہے۔
یہ ڈرائیور کیوں اہم ہے
یہ ڈرائیور کبھی بھی سب کچھ جاننے کا دعویٰ نہیں کرتا۔ جب بھی یہ پرنٹر سے پڑھنے کے بجائے کسی ویلیو کا اندازہ لگاتا ہے، تو یہ اس فیلڈ کو ایک اندازے (guess) کے طور پر نشان زد کر دیتا ہے۔ یہ شفافیت ان خاموش غلطیوں کو روکتی ہے جو ورنہ ڈی بگنگ (debugging) کے کئی گھنٹے ضائع کر سکتی تھیں۔
ڈرائیور حاصل کرنا
یہ ڈرائیور Chrome یا Edge میں چلتا ہے اور اسے صرف ایک Bluetooth سے لیس ڈیوائس اور ایک سپورٹڈ Niimbot پرنٹر کی ضرورت ہوتی ہے۔ لائیو ڈیمو یہاں آزمائیں:
https://iscarelli.github.io/niimbot-web-bluetooth/demo/
اس کا سورس کوڈ GitHub پر موجود ہے، جہاں کمیونٹی ماڈل ڈیٹا فراہم کر سکتی ہے، بگ (bugs) ٹھیک کر سکتی ہے، یا دوسرے براؤزرز کے لیے ڈرائیور کو ڈھال سکتی ہے:
https://github.com/iscarelli/niimbot-web-bluetooth
Niimbot کے مالکان ماڈل ڈیٹا بیس کو بھرنے میں مدد کر سکتے ہیں؛ اس عمل میں تقریباً دس منٹ اور دو لیبل لگتے ہیں۔
دوسرا پہلو
جب تک کمپنی اس فرق کی وضاحت نہیں کرتی، ڈویلپرز کو پیمائش شدہ ویلیو کے ساتھ ہی کام کرنا ہوگا۔
خلاصہ سادہ ہے: وہ ہارڈ ویئر جسے آپ ویب پیج سے کال کرتے ہیں، شاید وہ وہ نہ کرے جس کا وعدہ اس کی اسپیک شیٹ کرتی ہے۔ اہم پیرامیٹرز کی تصدیق کریں، خاموش ناکامیوں کی توقع رکھیں، اور ایسے ڈرائیورز کا انتخاب کریں جو غیر یقینی صورتحال کو چھپانے کے بجائے اسے ظاہر کریں۔