Kitchen and front-of-house printing

All physical printing in the venue goes through Cenaly Hardware Bridge — a small program on the till device the printers are attached to. A browser cannot talk to a thermal printer directly: it sends the document to the bridge, and the bridge speaks ESC/POS to the hardware.

Through the bridge you print: kitchen tickets per station, item and bag stickers, sale and refund receipts, the pre-check, X and Z reports, and the bag manifest on the handoff screen.

Kitchen tickets per station

A ticket has to arrive where the dish is cooked: cold station to its own printer, grill to its own, bar to its own.

Configuration lives in Kitchen (KDS) → the "Stations" panel, in the "station → printer" table inside it. For each station you set:

"Who prints" is a choice, not a checkbox. POS and KDS are different devices with different bridges, and the record of what has been printed lives on whichever one printed it. Turn both on and the kitchen gets two identical tickets.

The printer list is fetched from the local bridge, so a station has to be configured from the machine the printer is physically attached to.

What goes on the ticket. A large font (the cook reads the slip across a table), dish name, quantity, modifiers on their own lines under the dish, the note ("no onions"), the guest number and the course if the order is split by them. There are no prices or totals on a kitchen ticket.

Only new lines print. A second tap by the waiter does not produce a second ticket: the system remembers which lines already went to the station. If an item was added or its quantity changed, an "addition" ticket goes out — not a full duplicate of the order.

Item and bag stickers

A 60×40 mm label on the cup and on the box solves two handoff problems: bags stop getting mixed up between couriers, and the guest can see on the cup that the milk really is lactose-free — the modifier no longer stays on the kitchen ticket alone.

• item sticker — printed when a ticket is bumped to "ready", if the station has that setting on;
• bag sticker — printed at handoff;
• bag manifest — the slip inside the bag with the full order contents: courier and guest use it to check completeness, and a "you didn't pack an item" dispute with an aggregator is closed with printed evidence. The button is on the Expo screen.

The bridge does have a “label printer” role: a sticker goes to the device assigned that role, and when there is none, to an ordinary 60 mm receipt head as a narrow 32-character ESC/POS document, with the tear bar doing the separation. The native TSPL/ZPL languages of label printers are not supported — the same ESC/POS is printed.

Cashier documents

A venue whose only hardware is a fiscal register. Since 31.08.2026 the bridge does not push our documents through the register: a receipt printed as the till's service document would look like a receipt without being one. The bridge refuses, and instead of a print dialog the POS says that the till prints the receipt itself — the browser fallback does not kick in here. Exactly two documents are allowed through the register: a test print (otherwise there is no way to check whether such a till prints at all) and the pre-check (a guest bill is not a fiscal document by law). A separate receipt printer removes the restriction entirely.

Reprinting an issued receipt is always written to the risky-operations log; it asks for a manager PIN only for roles where "reprint under PIN" is enabled — see Loss control.

A fiscal receipt is a separate story: it is printed by the fiscal register and follows the country's law, see Fiscalisation.

The print queue and what the outcome means

The bridge has a restart-safe queue with retries: if the printer is offline, the job isn't lost — it waits and is retried. A queue indicator is shown in the POS header.

A stuck job can be cancelled. The classic kitchen disaster: a printer jams, it is fixed half an hour later, and on power-up it spits out fifty stale tickets. Jobs are cancelled one at a time from the queue in the till header: the bridge marks the job cancelled and simply skips it when the printer comes back. If the job has already gone to print, the cancel says so honestly — that paper will come out.

The "cancel" button appears only on stuck jobs — the ones that have been waiting for the printer for more than three minutes. Fresh jobs are listed but cannot be cancelled, and that is deliberate: a momentary hiccup (the printer woke up, a cable was nudged) is normal and the bridge will finish printing on its own, while a cancel button next to such a job would mean a lost receipt.

The print outcome has four states, and for a cashier they are very different news:

On "queued" the browser fallback does not kick in — otherwise one receipt would print twice.

Jobs are idempotent: re-sending the same document does not produce a second slip.

Code pages and non-Latin scripts

A thermal printer has no idea what UTF-8 is: it draws one glyph per byte from the currently selected single-byte table. That is why the code page is set per configured printer:

About Georgian, honestly. Which table a given print head speaks is a property of the physical unit and is absent from the protocol spec; that is why the table is chosen per device. If none fits, the text is romanised: a line reading bazuri tarifi is legible to the guest at the till, ?????? ?????? is not. Georgian does get printed in Georgian letters after all: when the head speaks no suitable table, the bridge renders the line as an image (raster printing with a built-in font) and sends it to the printer as graphics — the receipt carries real Georgian text rather than a romanisation. Romanisation stays as the fallback for devices that cannot do raster either.

Raster printing and the label-printer role need Cenaly Hardware Bridge 0.18.0 or newer (the current version is 0.23.0). Older bridges keep the previous behaviour: romanisation of non-Latin text, and stickers on the receipt head.

Turkish, Polish and Albanian Latin are deliberately not forced through CP1251, where ş, ğ, ą would turn into ?.

Related sections

• Cenaly Hardware Bridge — installing the bridge, device list, printer roles
• Kitchen (KDS) — stations, courses and print settings
• POS — receipt, pre-check, reprint
• Expo — bag manifest and stickers
• Cash shift — X and Z reports
• Loss control — reprint as a risk event

FAQ

The ticket printed twice — why?

Most likely the station has printing enabled on both POS and KDS. Those are two different devices with two bridges, and each printed its own copy. Leave one value in "Who prints".

The printer was unplugged — are the orders lost?

No. The job goes into the bridge queue and prints once the printer is back. But while it is queued there is physically no paper — and the interface says so plainly.

Can I print to the kitchen without the bridge?

Kitchen tickets and stickers — no, they only go through the bridge. Cashier documents have a browser fallback: printing through the ordinary print dialog. The exception is a venue whose only hardware is a fiscal register: there the till prints the receipt itself and the browser fallback is not used.

Why is the printer list empty?

The list comes from the bridge on this device. If the bridge isn't running, or the printer is attached to another machine, no devices appear — configure the station from the machine the printer is physically attached to.

Are modifiers printed on the bag manifest?

No, in the current version the manifest holds item names and quantities. Modifiers appear on the kitchen ticket and on the item sticker.