WooCommerce PDF Invoice Not Rendering Arabic / RTL Text

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 the Noto Sans file for your script (Noto Sans Arabic, Noto Sans Hebrew and so on) 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 fix 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.

Shaping and direction are two different failures

“Arabic is broken” usually describes one of two distinct problems, and telling them apart is what makes the fix obvious rather than a matter of trying things at random.

Shaping is the failure where every letter appears in its isolated form, disconnected, like a row of separate stamps rather than joined script. Arabic letters change shape depending on whether they sit at the start, middle or end of a word, and a renderer that does not apply those rules produces text that is technically all there and effectively unreadable to a native reader.

Direction is the failure where the letters are correctly joined but the words run the wrong way, or where a mixed line falls apart: an Arabic address with a Latin street number in it, where the number lands at the wrong end. This is the bidirectional algorithm not being applied.

The two are independent. You can have correct shaping with broken direction, which typically means the font is doing its job and the layout engine is not. Broken shaping with correct direction usually points the other way. And boxes or blank space instead of any glyphs at all is a third thing entirely: the font in use simply has no Arabic characters in it, and no amount of layout configuration will conjure them.

The font subset trap

A fix that works locally and fails in production is nearly always this one. Fonts are frequently subsetted (stripped down to just the characters expected) to keep file sizes small. A build pipeline that subsets to Latin characters will produce a font that renders your test order perfectly and every Arabic order as empty boxes.

It is worth confirming that the font file actually reaching the PDF generator contains the ranges you need, rather than assuming that because the font family supports Arabic, your copy of it does. The same applies to the fallback chain: a generator that silently substitutes a default font when a glyph is missing produces output that looks almost right, with a few characters rendered in a visibly different face.

Test with a string that exercises the hard cases rather than a single word. A mixed line containing Arabic text, Latin characters and digits together will surface shaping, direction and glyph coverage problems in one pass, where a clean Arabic-only word can pass while the real invoice still breaks.

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.

Related reading: showing VAT/GST/sales tax on invoices, sequential invoice numbering, how freemium WordPress plugins work, and bulk-printing a whole day’s invoices at once.