Automated Hebrew Document Generation: The RTL Failure Modes and How to Catch Them

Automated document generation - quotes, contracts, confirmations - is one of the highest-return automations in a business, and also one that breaks in Hebrew in ways it never does in English. The problem is not "Hebrew support" in general but five specific failure modes, each looking different, all of which surface at the customer if you do not test for them first.

Failure 1: the mixed string

This is the most common of all. A line containing Hebrew alongside Latin text or a number - an invoice number, an email address, a product code, a URL - can display in a different order from the one you intended. "Invoice INV-2041 for customer" can appear with the number somewhere else entirely in the line.

What happens technically is that the bidirectional algorithm decides display order by character type, and punctuation on the boundary between scripts takes the direction of its surroundings. The sign you have hit this: the string is correct in the database and wrong in the document - which is exactly what misleads, because people check the data rather than the output.

The practical prevention: put Latin values in their own field in the template rather than embedding them mid-sentence in Hebrew. An invoice number on its own line never reorders.

Failure 2: a font that is not embedded

A document that looks perfect on your machine and reaches the customer with boxes or missing characters is nearly always the same cause: the Hebrew font exists on your machine and is not embedded in the file. This is especially common in PDFs generated on a server, where the font set is entirely different from a desktop.

The only check that catches it is opening the file on a device other than the one that produced it - a phone is ideal. If the text renders properly there, the font is embedded.

Failure 3: brackets, quotes and marks

In right-to-left text, brackets and other paired characters display mirrored relative to reading flow - that is standard, correct behaviour. The problem begins when a technical value sits inside the brackets, such as a numeric range or a code: the reader sees an order that looks wrong even though the data is fine.

The fix is not technical but editorial: technical values do not go inside brackets within a Hebrew sentence but into a separate field or a table row. The same rule also resolves a large share of failure 1.

Failure 4: tables and alignment

The first row is the commercially dangerous one. When column order flips in a quote, the customer may read one item's price against another item's description - and that is a mistake that reads as misleading even when it is purely technical.

Failure 5: extracting text from a PDF

This is a separate problem that surfaces late: a Hebrew document that looks perfect can return reversed text when something reads it programmatically - for search, copying or processing. The reason is that display is stored by position rather than by logical order.

It only matters if something reads the document afterwards: archive search, automated document intake, or a customer copying from it. If the document is only read by eye and sent, it is irrelevant. If it enters a process, test for it in advance rather than after the archive is already full.

The test that catches all five

One test document deliberately containing every hard case: a Hebrew name, a Latin name, a document number, an email address, an amount with decimals, a date range, a table row with a long description, and a paragraph mixing Hebrew and English in the same sentence.

Generate it after every template change and open it in three places: on a computer, on a phone, and in software other than the one that produced it. Five minutes, and it catches what otherwise appears in front of a customer. The logic of making that part of handover is in an automation runbook.

Why does it work on screen and break in print?

This question recurs, and the answer is nearly always one of two. First: the screen renders with the fonts installed on the machine, while printing or PDF export uses a different set - which returns to failure 2. Second: the display allows a line wrap that printing truncates, so a mixed line that looked fine gets shortened and reorders.

There is a third case, less common and especially confusing: a document created in one tool and opened in another before printing. Every such handover is an opportunity for a different interpretation of direction, so the final document is best generated once and not edited on the way.

The practical test is the same in all three cases: generate, open on another device, and print to file - three actions that catch the gap before it reaches a customer.

What else is worth defining in the template

• Automatic document numbering, with no stray space between fields.
• A filename that does not rely on Hebrew characters if it travels between systems.
• One date format across every document.
• What an empty field does - decide whether it disappears or shows blank.
• A signature or logo at a fixed size, that does not shift with content length.

The fourth point produces most of the embarrassing documents. An empty field displayed with its label - "Order number:" with no value - reads as an error, and handling it is a template decision rather than a manual fix after every generation.

Sources

• Business automation for small businesses in Israel
• Israel Tax Authority - business information