Offline printing

Offline printing keeps label printing operational when your connectivity to Loftware Cloud is interrupted. Loading label templates from theControl Center's Documents, merging variable data, applying Automation business logic, and delivering print jobs to printers can be executed locally at the site. When connectivity returns, clients synchronize print history and other operational records back to Control Center.

Note

By default, you can run the application in offline mode for up to 5 days. To extend the offline period, follow the instructions in Web Printing installation guide.

Supported Loftware offline printing patterns

Loftware Automation (Enterprise) with caching enabled

In this pattern, Automation runs on your local Windows server and prints to local Windows print queues (or direct printer connections). When Automation is licensed at the Enterprise product level, you can enable caching of all files used for label printing so Automation maintains a local copy of label templates, images, and other assets from the Control Center's Documents, . During an Internet outage, Automation can continue printing using the local cache (provided the print request contains all variable data and does not rely on online data sources).

  • Best for: high-volume production sites that require deterministic on-site printing and want to minimize the impact of cloud outages.

  • Local dependencies: Loftware Automation service, printer drivers, and LAN connectivity to printers.

  • Connectivity behavior: when online, assets refresh from Documents and print history uploads; when offline, printing continues from the local cache (within the limits described in this document).

Loftware Web Client offline mode (attended printing)

Web Client supports offline mode out of the box for attended printing of web applications. When it starts, the Web Client checks its local cache for the most recent labeling data it has downloaded. If it is cached, the Web Client can run the application locally without contacting Loftware Cloud.

Offline limitations: In offline mode, database content is limited to the last used table or query displayed while online, and online resources (e.g., reading images from Documents or updating data in a cloud database) can cause errors. To enter offline mode, start the Web Client while offline; if the connection drops while it is running, restart the Web Client.

To learn more about Web Client offline mode, follow the instructions in Web Printing installation guide.

Loftware Desktop Designer + Loftware Print

In this case, label design and attended printing are performed using Loftware Desktop Designer and the Loftware Print application on a local PC.

  • Offline behavior: operators can continue to design/print using locally available label files and resources. Printing to local Windows print queues can continue while the Internet is unavailable.

  • Key limitations: these desktop clients do not provide offline caching of cloud-managed files. If you rely on opening labels/assets directly from Documents, those files will not be available when offline unless they were exported/saved locally beforehand.

  • Connectivity window: if you sign in to Loftware Cloud and then lose Internet connectivity, you can continue running, but you must reconnect within 5 days (or your redefined offline period); otherwise the application closes.

 

Loftware LMS Enterprise / on-prem Control Center (Hybrid installation)

This option shifts responsibility for high availability (servers, databases, backups, disaster recovery) entirely to your organization. See the Synchronization topic in the Control Center user guide.

Loftware Cloud Trigger API + on-prem Automation

In this pattern, a cloud application (for example, Workday or SAP) sends label data to the Loftware Cloud Trigger API over HTTPS. Loftware Cloud then routes the payload to the correct on-premises Automation instance using an outbound, pre-established connection initiated by Automation to Cloud Service Bus. This avoids inbound firewall openings. Automation opens the label template from Documents (or its local cache), fills variables, prints to local printers, and logs print history back to Control Center. Loftware’s architecture caches label templates locally to improve performance and to help prevent printing outages.

How offline printing works

Local caching (label templates, assets, and optional reference data)

Offline printing relies on a local cache so the print engine can render labels without reaching Loftware Cloud during an outage. In Loftware, caching typically includes label templates and assets stored in the Control Center's Documents (images, fonts, etc.).

  • Web Clientt: caches the last downloaded version of a Web Application and can run it offline if it is already cached locally.

  • Automation (Enterprise): can be configured to cache all files used for label printing. If a file is not in the cache, Automation retrieves it from the Documents; a background scheduler refreshes the cache at configurable intervals.

Job intake and local queueing

For resilient operation, ensure print requests can still be accepted when the Internet is down. In Loftware deployments, this is usually achieved in one of two ways:

  • local intake (for example, MES/ERP sends jobs directly to an on-prem Automation trigger, such as file drop, TCP/IP, SOAP/REST, etc.)

  • attended printing with Web Client running from its local cache. If your print initiation depends on Cloud Trigger API, job submission requires cloud connectivity; however, once connectivity is restored, the on-prem Automation processing and printing remain local.

Print execution (local rendering and spooling)

The local print engine merges the job data with cached label templates, applies business rules, generates the printstream (or uses a driver), and submits the print job to a local print queue. Because the final hop to the printer is within the plant LAN, printing can continue even if the Internet is down.

Sync and reconciliation after connectivity returns

  • Print history sync (Control Center): Loftware clients log printing activities to Control Center. If the connection to Control Center fails and you print while offline, print event logs are retained locally and uploaded when the connection is re-established. For the Web Client, print jobs are uploaded the next time you run the Web Client in online mode.

  • Label template/version behavior: define what is permitted offline (for example, only previously cached and approved label templates). For Automation (Enterprise) caching, files are refreshed on schedule when online; during an outage, Automation uses the locally cached versions.

  • Reprint safety: use unique job IDs and/or business keys (order/lot/serial) to prevent duplicates during retries. When online, Control Center provides centralized history and controlled reprinting; offline, ensure your local process enforces the same duplicate-prevention rules.

  • Desktop Designer / Loftware Print connectivity window: if you sign in to Loftware Cloud and then lose Internet connectivity, you can continue running, but you must reconnect within 5 days (or your redefined offline period); otherwise the application closes. These clients do not cache online files from Documents.

Prerequisites and sizing

  • Local computer: size the on-prem print node for peak print throughput (jobs/minute) and peak rendering complexity (images, barcodes, PDF generation, etc.).

  • Local storage: allocate space for cached templates/assets plus queued jobs and logs for the full outage window (plus safety margin).

  • Printers: ensure printers are reachable on the plant LAN and that required drivers/print languages are installed/available locally.

  • Time sync: keep accurate site time (NTP) to preserve audit quality during outages.

Limitations and trade-offs

  • Offline printing is limited to what is available locally: cached templates/assets and locally reachable printers.

  • Central visibility (history, monitoring dashboards) can be delayed until connectivity returns.

  • Template change management becomes stricter: you must ensure the right versions are cached and approved before disconnects.

  • Additional on-premise infrastructure (servers/clients) must be maintained and backed up.

Troubleshooting (quick checks)

  • Nothing prints during outage: verify local print node services are running; verify printers are reachable on LAN; verify templates are cached.

  • Jobs stuck in local queue: check queue depth, verify printer queue permissions.

  • Duplicate labels after reconnect: validate job ID/idempotency behavior on the job sender; ensure retry logic treats timeouts as “unknown” and queries job status before resubmitting.

  • Template/version mismatch: verify which template revision is in cache; confirm approval policy; refresh cache during planned maintenance windows.

  • History not syncing: check outbound connectivity, credentials/keys, and time synchronization; verify local logs are not exceeding retention limits.