You set up a WooCommerce invoice plugin, generate a PDF, and the customer name in Arabic — or the address in Hebrew, or a product title with Chinese characters — comes out as empty boxes, question marks, or blank space. The Latin text is fine; everything else is broken. This is one of the most common complaints about invoice plugins, and it is not your fault or your data’s fault. It is how most of these plugins handle fonts.
Why it happens
Almost every WooCommerce invoice plugin renders its PDF with a bundled HTML-to-PDF engine (usually dompdf). To keep the download small, plugins ship only a Latin font and subset it — they include the glyphs for A–Z, digits and common European accents, and nothing else. When your invoice contains a character outside that subset — any Arabic letter, any CJK character, Cyrillic, Hebrew, Greek — the font simply has no glyph for it, so the PDF draws a blank box (the infamous “tofu”) or nothing at all.
Right-to-left scripts add a second failure on top of the first. Even with the right glyphs present, Arabic and Hebrew need text shaping and bidirectional layout: Arabic letters change form depending on their position in a word, and the whole run has to flow right-to-left. A PDF engine that only lays out left-to-right Latin text will print the letters disconnected, in the wrong order, or reversed.
How to confirm this is the cause
- Latin text (English, numbers, prices) renders perfectly, but one specific script is broken. That points to a missing font subset, not a corrupted order.
- Copy the customer’s name out of the WooCommerce order screen — it displays fine in the browser. The data is intact; only the PDF can’t draw it. This rules out a database or encoding problem.
- The broken characters appear as identical boxes or blanks rather than wrong characters. Boxes mean “no glyph.”
The fixes, from worst to best
1. Manually swap the font (fragile). Some plugins let you drop a full Unicode TTF (like Noto Sans or DejaVu Sans) into a directory and register it. This can restore missing glyphs, but it does nothing for right-to-left shaping, it breaks on the next plugin update, and most store owners should not be editing plugin internals.
2. Switch off PDF and print from the browser (a downgrade). The browser has all the system fonts, so an HTML invoice prints correctly — but you lose the automatic PDF attached to the order email, which is usually the whole point.
3. Use an invoice plugin that ships a full Unicode font and does RTL shaping (the real fix). The clean solution is a plugin that includes a complete Unicode font and performs proper bidirectional layout, so Arabic, Hebrew, Persian, CJK and accented Latin all render correctly with no configuration. This is a design decision the plugin author makes up front; you cannot bolt it on reliably from the outside.
Why “renders every language” should be a free feature
Correct text rendering is not a premium add-on — it is the baseline of a document that represents your business. A plugin that paywalls “multilingual support” is charging you to fix its own font handling. Look for one where every language renders in the free tier, and the paid tier is reserved for genuine extras like bulk printing and custom templates.
The plugin built for this exact problem
Invoices, Packing Slips & Delivery Notes for WooCommerce renders every language — Arabic, Hebrew and Persian right-to-left, plus every accented and non-Latin script — because it ships a full Unicode font and proper text shaping instead of subsetting Latin-only glyphs. The invoice, packing slip and delivery note are free, it attaches the PDF to your order emails automatically, and it works with the block checkout and HPOS.
Related reading: showing VAT/GST/sales tax on invoices, sequential invoice numbering, and how freemium WordPress plugins work.