Label Printing و RTL/Barcode Layout

A clean preview can still produce a broken physical label

A bilingual label looks perfect in a browser: Persian recipient text flows RTL, a Latin tracking code appears below it, and the barcode looks sharp. The team prints on a 300-DPI device, then reuses the template on a 203-DPI printer and narrower stock. The barcode is scaled to fit, mixed-direction text reorders, and a scanner sometimes returns a different payload. None of those failures is proven or disproven by a pretty preview.

This lesson builds RTL Label and Barcode Print Verification Sheet v1. Promotion requires evidence that the template, printer/DPI/media profile, bidi treatment, symbol constraints, HRI/font behavior and scan roundtrip all hold for the same print path.

COM-032 ownership boundary

COM-032 owns label generation/printing verification. COM-031 owns packing queue and fulfillment priority. COM-033 owns scan-capture UX and business-context confirmation. This lesson neither chooses the next order to pack nor treats a decoded symbol as proof that the correct business entity was scanned.

Three hard boundaries:

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

Mental model: Canonical data → Bidi-safe layout → Symbol → Printer profile → Physical print → Readback → Promote

Use an auditable chain:

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

A change in template version, DPI, stock width, scale, font or symbology can stale earlier evidence. A success state must be rebuilt from the actual print path, not copied from a screenshot or an older device profile.

Keep FACT, INFERENCE, and DESIGN separate

FACT: GS1's official standards repository lists General Specifications 26.0.0 as the current January 2026 foundational standard for identification and AIDC/barcode use. The specification also treats barcode verification evidence—such as barcode type, print method, verifier and decoded text—as explicit evidence rather than visual appearance alone.

FACT: GS1 HRI guidance covers readable text associated with the barcode. Human-readable text assists people; it does not replace verification of the machine-readable symbol.

FACT: W3C Writing Modes defines RTL/LTR writing behavior, while W3C internationalization guidance recommends semantic HTML directionality such as dir and isolation/bdi rather than using CSS alone to establish base direction.

INFERENCE: Because browser layout correctness and symbol/print correctness have different authorities, a safe promotion gate keeps their evidence separate.

DESIGN: MAKNOW permits PROMOTE_VERIFIED only when printer-profile binding, bidi treatment, symbol checks, readback match and layout review are all explicit.

The 25-dimension Print Verification Contract

Gate 1 — Version the template and printer profile

label_template_id and template_version are not enough without printer_profile. The profile must bind the assumptions for DPI, media and rasterization.

Gate 2 — Treat DPI and media as evidence

Moving from 300 to 203 DPI or changing stock width can change module width, wrapping and rasterization. Rebuild the fixture rather than copying the old decision.

Gate 3 — Separate base direction from field direction

The label can be globally RTL while tracking codes, URLs and identifiers are explicit LTR runs. Semantic direction/isolation prevents mixed-direction text from depending on incidental renderer behavior.

Gate 4 — Keep payload and HRI separate

barcode_payload is machine-readable data; human_readable_text is a human-facing representation. HRI can help operators but does not define or verify the encoded payload.

Gate 5 — Reverify symbol constraints after scaling

If the barcode is resized to fit, prior quiet-zone, symbol-size and contrast evidence becomes stale. “It still looks like a barcode” is not evidence.

Gate 6 — Record font and raster path

Font substitution, hinting, drivers and raster scale can move or clip text. font_profile and raster_scale must be reproducible.

Gate 7 — Identify the physical/fixture print job

print_job_id connects a template/profile to the readback evidence. A scan verifies a particular print output, not an unspecified source file.

Gate 8 — Roundtrip requires decoded payload equality

Read the printed output and require decoded_payload == barcode_payload. A visually clean label that decodes differently is rejected.

Gate 9 — Layout review remains independent

A symbol can scan while bidi order or HRI is wrong. layout_review=PASS separately checks reading order, clipping, isolation and legibility.

Gate 10 — Missing decisive evidence fails closed

UNKNOWN or STALE quiet-zone, size, profile or roundtrip evidence cannot be coerced into success.

Worked examples

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

Template LBL-SHIP-01@7 is bound to ZT411-300-v3 and 100x150mm; tracking is explicitly LTR; symbol checks pass; scan readback equals the expected payload; layout review passes.

2. Scale to 82% without reverification → HOLD_REVERIFY_SYMBOL

The earlier symbol checks are stale even if one ad-hoc scan happens to work.

3. Latin tracking code inside an RTL run without isolation → REJECTED_BIDI_UNSAFE

Digits and punctuation can reorder on a different rendering/print path. Direction must be explicit.

4. Reuse a 300-DPI profile on 203-DPI hardware → HOLD_PROFILE_REBUILD

A printer change invalidates the bound print evidence.

5. Clean print, wrong decoded payload → REJECTED_ROUNDTRIP_MISMATCH

This is the decisive counterexample to visual approval.

6. Proper transfer to 203-DPI and new media

Regenerate the profile and layout, rerun symbol/layout/readback checks, then promote only if the new evidence passes.

Common failure modes

• screenshot approval instead of print verification;
• unversioned printer profiles;
• scaling a symbol while reusing old quiet-zone/size evidence;
• embedding Latin tracking/URLs in an RTL run without isolation;
• collapsing HRI and encoded payload;
• trusting “it scanned” without comparing decoded and expected payloads;
• font substitution without layout review;
• reusing 300-DPI evidence on 203-DPI hardware;
• promoting with decisive UNKNOWN/STALE evidence.

Alternatives and trade-offs

Raster-first templates: strong reproducibility but more artifacts per DPI/media profile.

Printer-language templates: faster and device-aware, but more coupling to printer families, fonts and command semantics.

PDF print paths: easy review/archival, but driver scaling can violate assumptions; 100% scale and profile evidence still matter.

Client-side HTML printing: flexible localization and semantic bidi markup, but greater browser/driver/font variance. Correct HTML directionality does not remove physical verification.

One universal template: less maintenance, but it can hide DPI/media/symbology limits. Profile-bound template families are usually easier to audit.

Experienced bridge: twelve review questions

1. What exact template/version is under review?
2. Which printer model/DPI profile is bound?
3. Is media size/printable area explicit?
4. Are base and field directions separate?
5. Are tracking/URL/GTIN runs isolated LTR where required?
6. Who owns symbology and payload rules?
7. Is HRI separate and legible?
8. Were quiet-zone/size/contrast checks rerun after the last scale change?
9. Can font/raster behavior be reconstructed?
10. Does the scan belong to this print_job_id?
11. Does decoded payload exactly match expected payload?
12. Was transfer evidence recomputed or copied?

Guided and independent practice

The offline lab contains eight fixtures: baseline, scale-without-recheck, missing LTR isolation, DPI change without rebuild, wrong decoded payload, unknown quiet-zone evidence, font/layout failure and a properly recomputed transfer.

Independent mutation: change media width from 100mm to 80mm. You may not simply reduce scale and reuse the old success state; rebuild profile/layout/symbol evidence.

Verification evidence

An acceptable artifact supplies all 25 dimensions or an explicit non-success state; reconstructs template/profile/DPI/media; isolates mixed-direction fields; keeps payload and HRI separate; reverifies quiet zone/size/contrast after mutations; binds readback to the print job; requires decoded-payload equality; and keeps layout review independent.

The lab is fully synthetic and offline. It needs no real printer, scanner, API key, customer data or production order.

Assessment and transfer

To complete the lesson, you must be able to:

1. separate COM-032 from COM-031 and COM-033;
2. build RTL Label and Barcode Print Verification Sheet v1 from the baseline fixture;
3. diagnose scale, bidi, DPI and wrong-payload mutations fail-closed;
4. recompute the same label for 203-DPI/new media;
5. explain why preview, HRI or one successful scan is insufficient promotion proof.

References and freshness

• GS1 General Specifications 26.0.0 — current January 2026 release; rechecked 2026-09-15; practice review due 2026-12-31.
• GS1 HRI Guideline — human-readable interpretation boundary; rechecked 2026-09-15.
• W3C CSS Writing Modes Level 3 — foundational RTL/LTR rendering model.
• W3C Internationalization bidi guidance — semantic dir/bdi direction markup; rechecked 2026-09-15.

External FACT sources do not override local MAKNOW design authority. Profile binding, fail-closed states and promotion thresholds remain lesson DESIGN.