Label Printing و RTL/Barcode Layout

وقتی preview تمیز است اما لیبل واقعی fail می‌شود

یک لیبل فارسی/انگلیسی روی مرورگر کاملاً مرتب دیده می‌شود: نام گیرنده RTL است، tracking code لاتین زیر آن است و barcode هم واضح به‌نظر می‌رسد. بعد روی چاپگر 300-DPI چاپ می‌شود و scanner می‌خواند. تیم template را بدون بازآزمایی روی چاپگر 203-DPI و رول باریک‌تر می‌برد؛ barcode برای جا شدن scale می‌شود، tracking code داخل run راست‌به‌چپ می‌ریزد و scan گاهی payload متفاوتی برمی‌گرداند. ظاهر خوبِ preview هیچ‌کدام از این شکست‌ها را ثابت یا رد نمی‌کند.

هدف درس ساخت RTL Label and Barcode Print Verification Sheet v1 است: evidence باید ثابت کند template، printer profile، DPI/media، bidi treatment، symbol constraints، HRI/font و scan roundtrip برای همان نسخه‌ی چاپی معتبرند.

مرز مالکیت COM-032

COM-032 مالک تولید/چاپ و verification لیبل است. COM-031 صف packing و priority را مالک است؛ COM-033 capture/scanning UX و business-context confirmation را. این درس نمی‌گوید کدام سفارش اول بسته شود و decode موفق را هم به معنی «همان بسته‌ی درست» نمی‌گیرد.

سه خط قرمز:

1. screen preview != print proof
2. barcode image exists != symbol constraints passed
3. scan decoded != downstream business confirmation

مدل ذهنی: Canonical data → Bidi-safe layout → Symbol → Printer profile → Physical print → Readback → Promote

مسیر قابل ممیزی:

canonical label data → explicit field directions → barcode encoder → versioned template → printer/DPI/media profile → raster/physical print → visual & symbol checks → scanner readback → payload match → PROMOTE or REPAIR

هر تغییر در template version، DPI، media width، scale، font یا symbology می‌تواند evidence قبلی را stale کند. state موفق باید از همان print path ساخته شود، نه از screenshot یا اعتماد به تنظیمات قبلی.

FACT، INFERENCE و DESIGN را جدا نگه دار

FACT: مخزن رسمی GS1 نسخه‌ی 26.0.0 را نسخه‌ی جاری General Specifications معرفی می‌کند. این استاندارد foundational درباره‌ی identification، AIDC و barcodeهاست و برای verification نیز evidenceهایی مثل نوع barcode، روش چاپ، verifier و decoded text را جدا ثبت می‌کند.

FACT: راهنمای رسمی GS1 برای HRI، متن خوانای مرتبط با barcode را به‌عنوان سطح انسانی در نظر می‌گیرد؛ خوانا بودن HRI جای verification خود symbol را نمی‌گیرد.

FACT: W3C Writing Modes رفتار RTL/LTR را تعریف می‌کند و راهنمای i18n W3C می‌گوید base direction در HTML باید با semantic markup مثل dir و برای runهای جدا با isolation/bdi مدیریت شود، نه فقط با CSS.

INFERENCE: اگر layout preview و barcode verification دو authority جدا دارند، promotion باید evidence هر دو را مستقل نگه دارد.

DESIGN: MAKNOW می‌گوید هیچ templateای تا وقتی printer profile + bidi + symbol checks + roundtrip match + layout review کامل نیست PROMOTE_VERIFIED نمی‌شود.

قرارداد ۲۵بعدی Print Verification

Gate 1 — Template و printer profile را version کن

label_template_id و template_version بدون printer_profile کافی نیستند. profile باید DPI، media و raster assumptions همان مسیر چاپ را نمایندگی کند.

Gate 2 — DPI و media بخشی از evidence هستند

تغییر 300→203 DPI یا عرض رول می‌تواند module width، wrapping و rasterization را عوض کند. تصمیم قبلی را copy نکن؛ fixture را regenerate کن.

Gate 3 — Base direction و field direction را جدا کن

کل لیبل فارسی می‌تواند rtl باشد، اما tracking code، URL، GTIN یا شناسه‌ی لاتین باید run مستقل ltr داشته باشد. dir/isolation معنای direction را صریح می‌کند؛ صرف text-align:right کافی نیست.

Gate 4 — Payload و HRI را یکی نکن

barcode_payload داده‌ی machine-readable است؛ human_readable_text لایه‌ی انسانی است. HRI می‌تواند به operator کمک کند، اما payload را تعریف یا verify نمی‌کند.

Gate 5 — Scaling بعد از encode نیاز به re-verification دارد

اگر برای جا شدن label، barcode را resize کردی، quiet_zone_check، symbol_size_check و contrast_check قبلی stale می‌شوند. «هنوز شبیه barcode است» evidence نیست.

Gate 6 — Font و raster path را ثبت کن

فونت جایگزین، hinting، print driver و raster scale می‌توانند HRI یا layout را جابه‌جا کنند. font_profile و raster_scale باید قابل بازسازی باشند.

Gate 7 — Physical/fixture print job باید identity داشته باشد

print_job_id bridge بین template/profile و readback است. scan نتیجه‌ی یک print job مشخص را verify می‌کند، نه یک فایل source نامعلوم را.

Gate 8 — Roundtrip یعنی decoded payload با expected payload برابر باشد

scanner باید از خروجی چاپی payload را برگرداند و decoded_payload == barcode_payload شود. اگر print زیباست ولی payload اشتباه decode می‌شود، promotion رد است.

Gate 9 — Layout review مستقل از scan است

scan موفق ممکن است با متن bidi خراب یا HRI ناخوانا همراه باشد. layout_review=PASS باید reading order، clipping، field isolation و readability را جدا بررسی کند.

Gate 10 — Missing evidence fail-closed است

UNKNOWN یا STALE در quiet zone، size، DPI binding یا roundtrip به success coercion نمی‌شود. state ضعیف‌تر را حفظ کن.

مثال‌های حل‌شده

1. 300-DPI + RTL/LTR isolation + checks PASS → PROMOTE_VERIFIED

Template LBL-SHIP-01@7 برای ZT411-300-v3 و media 100x150mm raster شده؛ tracking code صریحاً LTR است؛ quiet zone/size/contrast PASS؛ scan payload دقیقاً match می‌کند و layout review PASS است.

2. Barcode را 82٪ scale کردی ولی recheck نکردی → HOLD_REVERIFY_SYMBOL

حتی اگر scan آزمایشی یک بار جواب بدهد، symbol constraints evidence قبلی stale است. ابتدا دوباره verify، بعد promotion.

3. Tracking code لاتین داخل RTL run بدون isolation → REJECTED_BIDI_UNSAFE

رشته ممکن است روی یک renderer خوب دیده شود اما punctuation/digits روی path دیگر جابه‌جا شوند. field direction باید explicit شود.

4. 300-DPI template روی 203-DPI printer بدون rebuild → HOLD_PROFILE_REBUILD

Printer change فقط config نیست؛ print evidence جدید می‌خواهد.

5. ظاهر تمیز، decoded payload متفاوت → REJECTED_ROUNDTRIP_MISMATCH

این قوی‌ترین counterexample به «چشم انسان کافی است» است.

6. Transfer واقعی به 203-DPI + رول جدید

اگر template/profile regenerate شده و همه‌ی symbol/layout/roundtrip checks دوباره PASS شوند، promotion دوباره مجاز است. نتیجه‌ی baseline oracle نیست.

Failure modeهای رایج

• screenshot approval به‌جای print verification؛
• printer profile بدون version؛
• scale کردن barcode و reuse کردن quiet-zone/size evidence؛
• گذاشتن tracking/URL لاتین داخل RTL run بدون isolation؛
• یکی‌گرفتن HRI با barcode payload؛
• اعتماد به «scan شد» بدون مقایسه‌ی decoded payload؛
• font substitution بدون layout review؛
• reuse کردن template 300-DPI روی 203-DPI؛
• promotion با UNKNOWN/STALE decisive evidence.

Alternatives و trade-offها

Raster-first template: reproducibility خوب و کنترل دقیق print path، ولی برای هر DPI/media profile artifact بیشتری نگه می‌داری.

Printer-language native template (مثل command language): سرعت و device control بهتر، ولی coupling به printer family و font/rendering behavior بیشتر می‌شود.

PDF print path: review و archival ساده‌تر، اما scaling dialog/driver می‌تواند assumptions را خراب کند؛ print-at-100% و profile evidence باید صریح باشد.

Client-side HTML print: انعطاف localization بالا، ولی browser/driver/font variability بیشتر است. HTML bidi semantics کمک می‌کند، اما physical print verification را حذف نمی‌کند.

یک template universal: maintenance کمتر، ولی اگر DPI/media/symbology limits را پنهان کند false confidence می‌سازد. template family یا profile binding معمولاً auditپذیرتر است.

Experienced bridge: دوازده سؤال review

1. template id/version دقیق چیست؟
2. printer profile به کدام model/DPI بسته است؟
3. media size و printable area ثبت شده؟
4. base direction از field direction override جداست؟
5. tracking/URL/GTIN runهای LTR isolate شده‌اند؟
6. symbology و payload authority مشخص است؟
7. HRI از payload جدا و خواناست؟
8. quiet zone/size/contrast بعد از آخرین scale دوباره check شده؟
9. font/raster profile قابل بازسازی است؟
10. scan مربوط به همین print_job_id است؟
11. decoded payload byte/logical-value با expected payload match است؟
12. transfer evidence واقعاً recompute شده یا فقط template قبلی reuse شده؟

تمرین هدایت‌شده و مستقل

Lab هشت fixture آفلاین دارد. baseline را اجرا کن؛ بعد scale without recheck، LTR code without isolation، DPI change without rebuild، wrong decoded payload، unknown quiet-zone evidence، font/layout failure و transfer بازسازی‌شده را مقایسه کن.

تمرین مستقل: media width را از 100mm به 80mm تغییر بده. اجازه نداری با کم‌کردن scale و copy کردن state قبلی success بگیری؛ باید profile/layout/symbol evidence را دوباره بسازی.

Verification evidence

خروجی قابل‌قبول باید هر ۲۵ dimension را یا مقداردهی کند یا state صریح non-success داشته باشد؛ template/profile/DPI/media قابل بازسازی باشند؛ mixed-direction fieldها isolation صریح داشته باشند؛ payload/HRI جدا بمانند؛ quiet zone/size/contrast بعد از mutation دوباره verify شوند؛ scan readback به همان print job متصل باشد؛ decoded payload match شود؛ و layout review مستقل PASS باشد.

Lab کاملاً synthetic و offline است؛ هیچ printer، scanner، API key، customer data یا production order واقعی لازم ندارد.

Assessment و transfer

برای پایان درس باید بتوانی:

1. مرز COM-032 را از COM-031 و COM-033 جدا کنی؛
2. RTL Label and Barcode Print Verification Sheet v1 را از fixture baseline بسازی؛
3. scale، bidi، DPI و wrong-payload mutationها را fail-closed تشخیص دهی؛
4. همان label را روی 203-DPI/media جدید recompute کنی؛
5. توضیح دهی چرا preview، HRI یا یک scan موفق به‌تنهایی promotion proof نیست.

منابع و freshness

• GS1 General Specifications 26.0.0 — نسخه‌ی جاری January 2026؛ rechecked 2026-09-15؛ practice review due 2026-12-31.
• GS1 HRI Guideline — مرز Human Readable Interpretation؛ rechecked 2026-09-15.
• W3C CSS Writing Modes Level 3 — RTL/LTR rendering model؛ foundational stable.
• W3C Internationalization bidi guidance — dir/bdi و semantic direction markup؛ rechecked 2026-09-15.

FACTهای بیرونی authority محلی MAKNOW را جایگزین نمی‌کنند؛ profile binding، fail-closed states و promotion thresholdها DESIGN این درس هستند.