Remote print configuration

Remote print uses a fixed message JSON format (see below). You build the server program to receive ERP/WMS jobs, store them (queue/DB), and expose WebSocket / HTTP that returns jobs in that format. Desk PCs install the client and enter your endpoint URL under Remote Print—not printHtml in the browser for unattended flow.

Common mistakes: ① remote print does not call webPrintPdf.printHtml etc.; ② JSON schema is fixed—do not invent your own; ③ npm APIs are only to inspect the real data shape—enqueue the same structure on your server and point the client at your consumer URL.

When to use

  • Warehouse or store PCs only print; ERP/WMS schedules on the server.
  • Many stations share one task API—no duplicate remote logic in every front-end.

How it works

The client connects to your exposed API (WebSocket or HTTP polling), receives fixed-format JSON, and prints locally—no browser.

  1. ERP/WMS submits jobs in the fixed format to your receive/store service
  2. Your server exposes WebSocket push or HTTP pull in that format
  3. Desk PC: install client, enter that URL in Remote Print settings
  4. Client connects → fetches jobs → silent local output

What you build on the server

  1. Learn the fixed message format (below; match client test tasks)
  2. Build receive + store logic (queue/DB)
  3. Expose WebSocket push or HTTP pull returning jobs in that format
  4. Desk clients connect to that API only—fill business fields, do not change the schema

npm APIs (printHtml, etc.) vs remote print

Remote print does not require calling webPrintPdf.printHtml, batchPrint, or other npm APIs in ERP/WMS or desk business code. Those APIs are for in-browser local print; in remote mode they only help you map parameters to JSON fields.

Correct path: assemble tasks in the fixed format on your server → your receive/store service → expose a WebSocket/HTTP consumer API → desk client Remote Print settings enter that URL → client prints locally (no browser npm).

See printHtml API, batchPrint API, and print options for field reference; use npm only for local PoC, not production remote enqueue.

Standard message format (fixed schema)

The JSON shape below is product-defined and matches client test tasks. Your server enqueues content, pdfOptions, printOptions, etc.—not generated by calling npm in a web page. Do not add/remove top-level fields.

{
  "id": "uuid",
  "timestamp": 1710000000000,
  "type": "printHtml",
  "content": "<div>Shipping label #10086</div>",
  "pdfOptions": {
    "paperFormat": "A4",
    "margin": { "top": "20px", "bottom": "20px", "left": "20px", "right": "20px" },
    "printBackground": false
  },
  "printOptions": { "paperFormat": "A4", "printerName": "Default printer" },
  "extraOptions": { "requestTimeout": 15 }
}

The example above is a printHtml schema illustration with common fields only. Real messages include more fields and nested options (full extraOptions, watermarks, etc.). Use the client test task JSON or the actual output from a local npm call as the source of truth, and see printHtml API, batchPrint API, etc. (field sets differ by type).

type matches npm method names (printHtml, batchPrint, …) as payload kind—remote flow does not invoke those methods; it only ships the same JSON shape.

Client setup (your exposed URL)

In Remote Print settings, choose WebSocket or HTTP polling and enter your server URL:

ItemDescription
Save remote print configSave: method (websocket / http) + url (your API)
Read current configRead saved method and URL
Clear configStop remote listen and clear local config

After saving, the client connects to your API and prints on valid fixed-format JSON.

Use built-in test endpoints in the client to verify setup (local WS/HTTP test URLs; port shown in the UI).

WebSocket mode

Client connects to your WS URL, prints on fixed-format JSON, reconnects after network issues.

Server push example (Node.js—you deploy; body must match fixed format):

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 9000 });

function buildTask() {
  return {
    id: crypto.randomUUID(),
    timestamp: Date.now(),
    type: 'printHtml',
    content: '<div>WMS label</div>',
    pdfOptions: { paperFormat: 'A4' },
    printOptions: { paperFormat: 'A4' },
    extraOptions: { requestTimeout: 15 }
  };
}

wss.on('connection', (ws) => {
  ws.send(JSON.stringify(buildTask()));
});

Client URL: your WS endpoint. Do not push when idle.

HTTP polling mode

Client polls your HTTP URL on an interval:

// No job
{ "success": true, "data": null }

// Job available (data is full print message)
{
  "success": true,
  "data": {
    "id": "...",
    "timestamp": 1710000000000,
    "type": "printHtml",
    "content": "<div>...</div>",
    "pdfOptions": { ... },
    "printOptions": { ... },
    "extraOptions": { ... }
  }
}

Print only when data is a complete task in the fixed format.

Pull server example (Express—you deploy):

const express = require('express');
const app = express();
const queue = [];

app.get('/api/print/pull', (req, res) => {
  const task = queue.shift();
  res.json({ success: true, data: task || null });
});

// Business system enqueues jobs
app.post('/api/print/push', express.json(), (req, res) => {
  queue.push(req.body);
  res.json({ success: true });
});

app.listen(8080);

Client URL: your polling endpoint.

Remote print vs local npm APIs

  • Remote: fixed JSON → your receive/store service → consumer API URL in client settings (no npm calls)
  • Local: Vue/React + npm; browser calls webPrintPdf.printHtml (useful to inspect JSON fields—not the remote path)
  • Both can coexist: unattended remote enqueue + client consumer URL; manual reprints via npm locally.
Download client free Documentation