Why Thai Text Layers Break in PDFs: The Broken Pipeline of Conversion and Rendering

Exploring the structural flaws of Thai fonts and text layer engines when converting docs to PDF and extracting data.

Part 1: The Root of the Document — TrueType Fonts (TTF) and Open Formats

The integrity of a Thai PDF text layer begins long before the “Export to PDF” button is ever clicked. It starts at the very origin of the data pipeline: document authoring.

To understand why Thai script breaks so easily, we must look at how characters are handled at the root. For this workflow, the process initiates with two critical decisions:

1. The Choice of Font Engine: TrueType Fonts (.TTF)

Unlike Western scripts where characters sit sequentially on a single baseline, Thai is a multi-level script. Vowels and tone marks can sit above or below the consonant (e.g., สระ, วรรณยุกต์).

Using standard TrueType Fonts (TTF) ensures that each glyph, combined character, and positioning coordinate is fully mapped within the font’s internal tables. When formatting Thai text, relying on system-native TTF structures provides a clean digital anchor for each character component, ensuring that the software recognizes the script’s absolute layout rather than just treating it as a visually combined graphic block.

2. Document Authoring with LibreOffice and the .DOCX Standard

Instead of using restrictive proprietary software, the initial document drafting and editing are performed using LibreOffice, a powerful open-source office suite.

The Editing Process: LibreOffice provides robust compliance with complex script types, making it highly reliable for managing the intricate spacing requirements of Thai formatting without introducing hidden formatting metadata that could corrupt the layout.

The File Structure: Once the text and layout are finalized, the document is saved in the .docx format. This XML-based architecture preserves the explicit structural hierarchy, formatting flags, and font mappings of the Thai text blocks, setting up a completely predictable framework before the conversion engine takes over.

However, saving a perfectly structured .docx file with the correct .ttf fonts in an offline editor is only half the battle. The real challenge — and where most automated systems break down — lies in how this structural pipeline transitions from an editable format into a static PDF text layer.

Part 2: The Silent Culprit — How PDF Readers Break the Thai Text Layer

Even if a document is perfectly authored with compliant TrueType fonts and converted via a clean engine, the battle for a flawless Thai PDF is only halfway won. The final, and often overlooked, link in this digital pipeline is the PDF Reader Engine itself.

For Western languages, rendering a text layer is a straightforward, sequential operation. But for complex, multi-level scripts like Thai — where vowels and tone marks stack above and below consonants — the PDF Reader must do more than just display shapes; it must reconstruct the correct text stream behind the scenes.

The Impact on Search and AI Text-to-Speech (TTS)

When a PDF Reader fails to interpret the positional metadata of Thai characters properly, the underlying Text Layer becomes deeply corrupted. This breakdown triggers two major technical failures:

Broken Searchability: If the reader engine fails to map the stacked vowels and consonants in their true linguistic sequence, the “Ctrl + F” search function fails entirely. Words are treated as broken fragments rather than continuous strings.

AI Text-to-Speech (TTS) Distortion: Modern AI narration and TTS engines rely heavily on the browser or reader’s text extraction layer to read documents aloud. If the reader extracts a corrupted text layer where tone marks are misplaced or character spaces vanish, the AI engine will mispronounce words, completely ruining the natural speech flow.

The Discovery: Why SumatraPDF is the Solution

Through rigorous testing of various PDF readers and browser-integrated PDF viewers — which often suffer from severe rendering and extraction bugs when handling Thai script — I discovered a powerful exception: SumatraPDF.

SumatraPDF stands out because of its lightweight yet highly accurate text rendering architecture. When opening a Thai PDF in SumatraPDF, the software executes a precise character-mapping process:

Perfect Font Mapping: It flawlessly handles the embedded .ttf tables, ensuring that the visual layout matches the semantic data layer perfectly.

Clean Text Extraction: Unlike heavy, bloated readers that distort word spaces or misplace floating vowels upon extraction, copying text from SumatraPDF into a plain text editor reveals a 100% accurate, uncorrupted layout.

By utilizing SumatraPDF as the primary reader, we ensure that the Thai text layer remains completely intact, perfectly searchable, and fully optimized for AI narration tools without any distortion.

Part 3: The Unicode Illusion — Why Web Browsers and AI TTS Engines Fail

When a PDF is viewed through a standard Web Browser (such as Chrome, Edge, or Safari), the integrated PDF viewer processes the document using standard web technologies. These browsers read the underlying data stream primarily via Unicode (UTF-8 or UTF-16) character encodings. While Unicode is the global standard for text interchange, its implementation within browser-based PDF rendering engines introduces a catastrophic breakdown when handling Thai script.

1. The Logical vs. Visual Processing Trap

In a standard text file or web page, Thai Unicode characters are typed sequentially (Consonant + Vowel + Tone). The operating system’s rendering engine automatically handles the visual stacking.

However, a PDF file operates on a Coordinate-Based Postscript System. It tells the reader exactly where to draw a glyph on a 2D plane. When a browser’s layout engine attempts to extract text from a PDF, it tries to map these absolute visual coordinates back into a logical Unicode stream. Because Thai vowels and tone marks sit on different vertical levels (above or below the baseline), the browser gets confused. It fails to reassemble the characters in their correct linguistic sequence, causing tone marks to detach, slide to the next character, or drop onto their own broken lines, as clearly demonstrated when pasted into a plain text editor.

2. The Impact on Browser-Based Search (Ctrl + F)

Because the browser’s internal text layer thinks the word “เอกสารชั้นต้น” is structurally written as a fragmented sequence of separated consonants and floating marks, the built-in search indexing fails completely. If you search for the correctly spelled word, the browser’s search engine cannot find a match because the text layer it “sees” is a garbled string of broken characters.

3. Why AI Text-to-Speech (TTS) Programs Synthesize Corrupted Audio

This dual-failure of conversion and browser rendering is exactly why modern application-based Text-to-Speech (TTS) tools read Thai PDFs with heavy distortion.

Most AI voice synthesis tools and screen readers do not look at the visual rendering on the screen; they inject a script to scrape the raw text layer directly from the browser’s PDF engine. When the script extracts a corrupted Unicode text stream where spaces vanish and characters are scrambled, the AI reads the text literally as it is extracted. The result is a broken, robotic, and completely unnatural narration that completely ruins the user experience.

Part 4: The Ultimate Local Pipeline — Preserving Thai Bookmarks and Structural Integrity

To build a professional digital archive or technical document, preserving the text layer is only one side of the coin. The other critical requirement is maintaining the document’s structural navigation, such as Bookmarks and Headers (Table of Contents).

When relying on cloud engines or mainstream browsers to handle Thai documents, creators are often forced to choose between a functional navigation tree or a searchable text layer. By shifting to a completely local pipeline, we can secure both.

1. Advanced Source Authoring with LibreOffice (The Power of Native Bookmarks)

The foundation of a reliable Thai PDF relies on generating a permanent, pre-compiled structure locally.

Structuring with Intent: During the drafting stage in LibreOffice, using standard TrueType Fonts like Noto Sans Thai, the document is organized with proper heading styles (H1, H2, H3).

The Embedded Architecture: When saving as a .docx file or exporting directly via LibreOffice, the software injects explicit Bookmark metadata into the file. This process binds the Thai heading text directly to the document’s navigation tables, preventing the text drift or font substitution that typically destroys Thai character mapping when processed by cloud-based conversion platforms.

2. Seamless Navigation and Flawless Extraction in SumatraPDF

The real magic happens when this properly authored document meets SumatraPDF. While Chromium-based browsers (Chrome/Edge) strip away or glitch out when processing complex Thai index structures, SumatraPDF processes the local file perfectly:

Intact Navigation Tree: Upon opening the document, the Bookmark panel renders flawlessly. Users can click through the Thai headers to navigate deep into the document without encountering corrupted symbols or broken character rendering.

100% Searchable and Extractable: As proven by real-world testing, typing a specific phrase like “เอกสารชั้นต้น” into SumatraPDF’s search engine immediately hits the target. Copying that exact text block out of the reader and dumping it into Notepad preserves every single character, floating vowel, and tone mark in its exact linguistic order.

Conclusion

Achieving a bulletproof, professionally navigable Thai PDF does not require cloud-based AI processing or heavy proprietary ecosystems. It requires technical discipline at the source. By structure-mapping documents locally with LibreOffice’s native bookmarks and deploying SumatraPDF as the final verification gate, engineers and archivists can produce pristine Thai digital documents that are structured for navigation, fully searchable, and completely ready for perfect AI Text-to-Speech integration.