AI-Generated Thai Word Documents Break in Microsoft Word: A Bangkok Lawyer Built the Fix

You ask Claude to draft a contract in Thai. The output looks correct in the chat window. You convert it to a Word file, open it in LibreOffice to check, and it still looks fine. You send it to the client. They open it in Microsoft Word and call back: the font is wrong, the bold headings are not bold, and the tone marks are floating above the wrong characters.

This is not a Claude problem. It is not a Microsoft Word problem. It is a gap between what AI tools know about Thai font rendering and what Microsoft Word actually requires, and it affects every AI-generated .docx file that contains Thai text.

A Bangkok lawyer named Promsin Boonchan (พร้อมสิน บุญจันทร์) identified the exact cause and built a fix that works. This article explains both.

Why the Preview Does Not Show the Problem

The deceptive part of this issue is where it surfaces. When you view a .docx file in LibreOffice, macOS Preview, or Google Docs, those applications guess at missing font information. They see Thai characters and apply a sensible default. The document looks fine.

Microsoft Word does not guess. It follows the document’s XML specification exactly. If a property is missing from the XML, Word uses its own fallback. And Word’s fallback for Thai in an improperly specified document produces the symptoms Promsin describes: fonts that shrink to roughly 10pt even when set to 16pt, bold formatting that applies to Latin characters but not Thai ones, and tone marks and vowels that separate from the consonants they belong to.

The result is a document that passes every review step a Thai professional firm might use, preview, LibreOffice, chat window, and only breaks at the point of delivery: when the client opens it in the Microsoft Word on their desktop.

The Root Cause: Two Font Channels, Only One Filled

Microsoft Word processes fonts at the character level rather than by run. Inside each run of text in a .docx file, there are separate font properties for different script types. Latin characters (English, numbers, punctuation) are handled by one set of XML properties: w:ascii and related attributes. Thai and other complex scripts are handled by a separate set: w:cs (font for complex script), w:szCs (size for complex script), w:bCs (bold for complex script), w:lang with bidirectional settings, and related properties.

When AI tools generate Word files using python-docx, the standard Python library for creating .docx files, they set the Latin-side properties. The complex script side is left empty. Thai characters fall through to whatever fallback font Word applies by default, which is not TH Sarabun New at 16pt. It is something else, at a different size, without bold support.

This is not a bug in python-docx. The library was built without complex script languages as a design priority. Promsin’s characterisation of the situation is accurate: western AI tools and the libraries they rely on were not built with Thai in mind, and Thai professionals have to handle one additional layer that does not exist for users working entirely in Latin-script languages.

The Fix: One Function Call Before Saving

Promsin built a tool called thai-docx to close this gap. The core of it is a function called enforce_thai(doc) that you call once, on the Document object, immediately before saving the file.

What it does is systematic: it traverses every run in the document, body paragraphs, table cells, headers, footers, styles, and document theme settings, and sets the complex script font properties wherever they are missing. For any run that does not specify its own font size, it inherits from the style rather than being overridden to a fixed value, so headings remain at their intended size rather than being collapsed to body text size.

The result is a document where every run has both its Latin and complex script properties explicitly set. When Microsoft Word opens the file, there is nothing left to guess at or fall back on.

What the Tool Handles Beyond Font Rendering

Promsin designed thai-docx around the full set of problems that appear when generating Thai legal documents through AI. Font properties are the central issue, but there are adjacent problems that arise in practice.

Mixed-language runs. A Thai legal document often contains sentences that mix Thai and English: a company name in the Roman alphabet within a Thai paragraph, or an English term followed by Thai explanation. Promsin’s tool allows the Latin and Thai fonts to be set independently within the same run, Times New Roman for the English portions and TH Sarabun New for the Thai, without needing to split the text into separate runs in the underlying XML. This matters for documents following the Thai government standard (TH Sarabun New, 16pt) where English terms appear inline.

Thai word-boundary justification. When a paragraph is set to justified alignment, Word needs to know where Thai words end in order to break lines correctly. Thai text has no spaces between words, so Word has to identify word boundaries itself. When it fails, it stretches the spacing between individual characters to fill the line width rather than between words. Promsin’s tool inserts zero-width space characters at word boundaries using a Thai tokenizer, giving Word the break points it needs. If the tokenizer library is not installed, the function skips this step and warns rather than failing.

PDF copy-paste cleanup. Text copied from Thai PDFs frequently contains invisible characters inserted between visible ones during PDF-to-text extraction. These invisible characters cause tone marks and vowels to appear displaced from their consonants. The tool includes a clean_pdf_thai function that normalises these sequences, removes invisible characters, and reattaches displaced tone marks to their correct positions without affecting Latin text or numerals.

A QA scanner. Promsin includes a verification script, verify_thai_docx.py, that checks a saved document and reports any runs still missing required complex script properties, identifying what is missing and what rendering symptom it will produce in Word. His advice is direct: never trust preview. Run the scanner. Exit code zero means the document is ready to send.

The Broader Point for Thai Professional Firms

The problem Promsin identified and solved is representative of a wider pattern. Thai is a complex script language in the technical sense: characters stack vertically, tone marks interact with vowels and consonants in ways that require the rendering engine to handle positioning explicitly, and word boundaries are not marked in the writing system. Most AI infrastructure, from the models to the libraries that generate output, was built for Latin-script languages first.

For a Thai law firm or accounting firm that uses AI tools to draft documents, this means an additional review layer is required that an English-language firm does not face. A contract drafted in English by Claude and saved as a Word file works exactly as it appears. The same workflow for a Thai document requires verification of the output at the rendering level, not just the content level.

Promsin’s tool addresses this at the source: patch the file before it leaves the firm, and use the scanner to confirm it is correct before it reaches the client.

How FirmFlow Relates

FirmFlow’s document workflows operate within the platform rather than generating standalone Word files through python-docx. When a contract is analysed through the Document Analyser, when a report is drafted through Report Drafting, or when meeting notes are recorded through the Meeting Summariser, the output stays within a controlled rendering environment where Thai font properties are handled consistently.

For firms that use AI to generate standalone Word files for external delivery, the gap Promsin describes is real and the fix is practical. The thai-docx skill is available through Promsin’s Claude Cowork community; he can be contacted directly to receive the skill file for testing. His original post describes the tool in detail and includes contact instructions for anyone encountering the same problem.

The underlying lesson is worth taking seriously regardless of which tools a firm uses: Thai-language output from AI tools requires verification steps that the tool’s own preview cannot substitute for. Professional delivery to clients, documents that open correctly on their machines in the software they actually use, requires one additional layer of Thai-specific care.

Promsin built that layer for his own practice and made it available to others. That is precisely the kind of practitioner knowledge that the Thai professional AI community is building, one workflow gap at a time.