Printing Fails or Content Is Wrong
On this page
7.7 Printing Fails or Content Is Wrong
Identify the failing layer: person/content, submission, Windows queue, physical output, or business writeback. Do not print again simply to repair status.
7.7.1 Command, People, and Output Method
Print Current uses focus and normal output; Sequential uses visible checked rows; Automatic uses visible matches, not checkboxes. Saved imposition parameters do not change ordinary commands. Record layout/user/printer/side/copies/order/scope and license/role. Viewing the back is not choosing back output. Test one approved record rather than repeatedly clicking or submitting a full batch.
7.7.2 Queue, Device, and Supplies
Verify actual target, not virtual PDF/old shares. Inspect paused/offline/errors/older jobs and time/count without indiscriminately clearing shared work. Check panel, connection, orientation, ribbon, stock, and jams using vendor procedures; do not force cards out while running. Failed OS/vendor tests indicate base driver/device issues, while passing tests do not validate credential data/encoding. Cancelled jobs may already be in hardware; reconcile output/queue/people and retry only known incomplete items.
Figure 7.7-1. Show focus/checks, chosen side, redacted Windows queue, and device-state illustration, separating submission, queue, and physical output. Do not create production failures for screenshots.
7.7.3 Content, Size, and Color
If preview is wrong, inspect bindings/people/photos/fonts before driver scaling. If physical output differs, inspect paper/card dimensions, orientation, margins, offsets, and fit-to-page. Use a direction-marked measurable sample and change one setting per one-copy trial. Check fonts for missing glyphs, source resolution for blur, and content/quiet zones/physical size/scanning for codes. Media/ribbon/device affect color; screen adjustments alone cannot promise matching output.
7.7.4 Duplex, RFID, and Post-Print Actions
Test flip direction with clear markers. Driver/flipper/back design must agree; imposition is single-sided. Manual RFID proceeds print one, operator presents that card, encode, automatic next; it still needs a compatible writer despite printer-SDK independence. At a pending write, verify person/chip/module/message rather than skipping to the next. Fully automatic in-printer writing needs the vendor integration; UID lookup is not successful payload writing.
After trigger failure, inspect queue/card/database and repair approved business state rather than reprinting just for writeback. Isolate card/chip identity mismatches and account for the old card before replacement.
7.7.5 Automatic Printing Does Not Trigger or Duplicates
Check completed refresh, visible scope, locating keys, and every AND rule, including NULL/leading-zero/comparison behavior; do not remove all conditions. For duplicates pause and inspect persistent writeback/types and other consumers. Memory suppression is not cross-restart/station uniqueness; re-enabling can reprocess still-matching people. Disabling printing neither recalls queues nor disables refresh. Reconcile both switches, output, pending work, and persistent status; no immediate reprint is not proof of correct writeback.
Figure 7.7-2. Show separate switches, rule field/state, and output/queued/incomplete lists with fictitious data. State pause does not recall prior jobs; hide device and interface details.