From Paper to Pixels to Pipelines - Tate Andrea Aung

This talk explores the evolution of document management from traditional methods to modern automation systems. The speaker discusses the challenges faced in document workflows, particularly in the APAC region, emphasizing the need to adapt to multilingual and diverse document formats. Key topics include the importance of script-agnostic OCR and context-aware extraction to improve data processing accuracy. The session highlights innovations like iText PDF Calligraf for complex script rendering and XLIFF reflow for dynamic layout adjustments during translations. By addressing these challenges, organizations can transform static documents into active data pipelines that drive automated workflows and decision-making.

Thank you for being here today and welcome to my talk from paper to pixels to pipelines. My name is Tate and I'm a solutions engineer at Apprise. In my day-to-day, I work with businesses and their teams to help them move from manual document workflows to automate their pipelines our SDKs. So, I'll be honest, I have a bit of a habit of going against the stream. So, if

there is a process or a workflow that everyone just accepts as standard, my first instinct is to tear it down and see what's actually possible beyond it. Document workflows are exactly like that. Something that everyone accepts as painful and then move on. Now, suppose you've got a modern stack, a cloud infrastructure, and maybe some LLMs in the mix. And then someone asks you to build a feature

that involves processing a PDF, like extracting the fields, handling multiple languages, and generating a compliant output. Suddenly, you're 3 weeks in writing code that breaks on every new document format and nobody questions it. Oh, these documents are just unpredictable and there's nothing much we can do. That's the standard answer we get and I don't accept that. By the end of this talk, I hope you won't either.

So, what's on the agenda? In this talk, we will move through four eras, stone, paper, digital, and automation. Each era solved a problem and created a new one. I'll keep the history brief because the part I really want to get to is what's happening right now in the automation era, specifically the challenges we're seeing here in APAC. But first, what actually is a document? Simply put, a

document is anything that records information. There was a time when creating a single document took days of physical labor. Today, we generate millions of them without thinking twice. Receipts, contracts, invoices. Now, how many documents did we actually touch today just to get into this room? So many of you used documents just to get here today. A passport, a boarding pass, a conference badge. Now, look at this.

This is a page from a Canon printer manual. It's a warning label, a simple caution sign that has been successfully translated in six languages, English, French, German, Japanese, Korean. You've all seen something like this. Now, imagine that same challenge, but for this. This is a complex, real user manual for a Delta Electronics Programmable Logic Controller. They are very dense technical diagrams, wiring schematics, safety specifications, all in

Chinese, and it needs to go out separately in English, Hindi, Tamil, and six other languages. Here is what happens when you translate it without the right tooling. Hindi, for example, runs 30 to 40% longer than Chinese for the same content, and that extra text has to go somewhere in that page. Paragraphs may start overlapping with important safety diagrams, or the lines may be gone entirely. In industries

like aerospace or medical devices, the FDA requires medical device documentation to be translated into the local language of every market it's sold in. So, a broken layout for a translated document is not just an aesthetic problem. It leads to confusing instructions for device users who need to handle them with care. There is a risk of someone getting hurt and the device being pulled from the market. 5,000

years ago, our only challenge back then was simply preserving information at all. You only documented what was truly essential. Stone and clay came to help us with It was durable, but impossible to move. So, you only carved what was truly important, like laws, decrees, religious texts. The limitation? Documents stayed where they were and the moment we wanted to share knowledge, we needed something lighter. We moved on

from stone to try lighter materials. Our first attempt at this was papyrus, which was lightweight and it could be carried in one hand. The problem with papyrus was that it was extremely brittle and the plant only grew in Egypt along the Nile. Next came parchment, which was made from the skin of animals, stretched thinly and dried in the sun. This material was extremely flexible, but was extremely

costly. To produce a single book, it would require the skin of roughly 200 sheep. You can start to see a pattern. We figured out a way to do something, liked it, but each solved one problem and created another. Too brittle, too expensive, too scarce. Now, to keep up with the growing world, we needed a solution that was light, cheap, and abundant. This led to the invention of

paper. Paper manufacturing was originally invented in China by Cai Lun. Now, paper made information portable, but we generated it faster than we could organize it. Maps, newspapers, ledgers, books, timetables, and more. Three problems emerged. Expensive to store, nearly impossible to search, and completely vulnerable to fire and decay. People were slowing us down, so digital was the answer. Three things drove the shift. Personal computers put creation on

everyone's desk. Standardized formats like PDF and Word let us digitize efficiently. And affordable storage made archiving cost-effective. So, we went paperless. Problem solved, right? Unfortunately, we digitized the paper, but not the processes behind it. A PDF is still unstructured data, and the valuable information is trapped inside a static file. This is what brought us to the automation era. The question is no longer what does the document

say? And the answer And the question is what does the document do? And the answer today is a lot. Documents in modern systems aren't static files, they are active events in software. They trigger workflows. So, a document arriving in your system, an upload, an email attachment will kick off an entire pipeline. You can ingest it, extract the data, validate it, make a decision. And next, they even

teach models because every document that passes through your system is training data. The machine learns what a salary slip looks like, what a KYC form looks like without you writing a single rule. And finally, they can transport data forward. But all of this only works if the system can actually understand the document correctly. And depending on where you are building, documents behave very differently. Which brings us

to the part I am most excited to talk about. Documents have evolved globally, but different regions have very different realities. APAC in particular has some unique structural challenges that have pushed developers towards smarter, more flexible technical approaches. If you've built anything involving documents in India, I guarantee at least one of these problems has burned you. I'm going to walk you through four real-world challenges common in the

APAC region. First, multilingual pipelines. Second, complex script rendering. Third, diverse national ID formats. And fourth, bilingual layout reflow. Let's start with multilingual pipelines, our first challenge. Anyone here recognize these scripts? We have Hindi, Thai, Khmer, and Tamil. I'm from Singapore, and we have four official languages: English, Mandarin Chinese, Malay, and Tamil. That is already very complex, but it is nothing compared to the 22 recognized languages here

in India. Anyone here built a pipeline that had to handle more than one of these? Show of hands. Here's the developer problem. Each script on a document adds a layer of complexity to data extraction. You cannot write one rejects, one field detection rule, and have it work across all languages. The moment your pipeline encounters a language it wasn't explicitly trained on, it breaks. In APAC, your OCR

and extraction rules must handle documents containing multiple languages simultaneously. This could be a loan application in Hindi, a contract in Tamil, a bank statement in Thai. The system has to be flexible enough to handle all of them without you building a separate pipeline for each. So, how do you actually solve this? This is where script-agnostic OCR comes to be able to come in to recognize more than

100 languages in a single pass without requiring separate pipelines per script. But, reading the text is only half the battle. Once you have the raw text, how do you know which part is a field label and which part is a value in a document? Imagine you're processing salary slips for a fintech in Mumbai. You're hardcoding find the label monthly salary and grab the number next to monthly

salary in this document. Now, this may work perfectly until the same document comes in with the label in Hindi. So, your rule doesn't fire anymore and the field comes back empty. And worst of all, nobody throws an error. The smarter approach is context-aware extraction because this engine understands key-value relationships from the structure and layout of the document alone without needing to know what the label say or

what language they're in. Next, you layer on top of that accuracy scoring that tabulates a confidence score for extracted field, so you know when to trust the output and when to flag it for review by a human in the loop. Finally, we have a normalized JSON output with a language-independent schema. Consistent structure regardless of the input script. Although we have a altogether we have a simple acronym

to help make this memorable, scan. This is the foundation of a multilingual pipeline that actually scales. Now, let's look at this image. Solving the problem of reading multiple scripts is hard, so historically people handled this with templates, but those templates break the moment the alphabet changes. So, rendering text is a challenge. And has anyone ever shipped a document that looked fine in your system, but the user

came back and said that the text was wrong? Here's why that happens. Think about English. Every letter in English is like a LEGO brick. It's a hard, fixed plastic block. To write the word cat, you just snap the letters c, a, and t together in a row. The shape of the a never changes, no matter what letter is next to it. And that a standard PDF engine

thinks about text. But Hindi, for example, isn't LEGO. Hindi is clay. Hindi characters are not static blocks. They are like wet clay, and when they touch each other, they merge, stretch, and change shape to form a single new sculpture. Two characters can fuse into one, or one character can wrap itself around another one. So, they can stack vertically instead of sitting side by side. And a standard

PDF engine doesn't know any of this. It treats the clay like LEGO, forces every character to sit in a row without touching. There is no error and no warning when such a disruption happens. The document looks complete, but you've actually rendered a pile of disconnected parts that no native speaker can read. And this is what that looks like. On the left, this is a standard engine trying

to process Hindi. It forces the characters apart, the clay gets crushed, and what comes out is a fractured mess again, there is no error or warning. The pipeline thinks it succeeded. On the other hand, on the right, this is a shape engine shaping engine that is doing a very good job. Think of it as the sculptor. It sees the characters, knows the rules of the clay, and

says, "These three pieces are touching. I need to mold them into a specific shape." The result is a text that is visually correct, semantically correct, and legally correct. That's the difference between a pipeline that works and one that only thinks it does. So, what would this mean in the actual translated document? In Hindi, conjuncts break apart. And then in Tamil, vowel signs end up in the wrong

place. And in Bengali, ligatures simply don't form. So, you are wondering then what? The fix to this is specifically something like iText PDF Caligraf, which brings OpenType shaping intelligence into your PDF pipeline. When it sees those Hindi characters, it doesn't just place them in a row. It's able to read the font's OpenType rules, applies the correct substitutions, so that two Hindi characters actually merge into a correct

single character, and crucially, it writes the correct Unicode back into the document as metadata, so that the text is searchable and extractable downstream. Now, if everyone here took out their ID right now, how many different formats do you think we'd have in this room? This is the third challenge. Look at the difference between an Indian Aadhaar card and an Indonesian KTP. Different layouts, different view positions, different

ID number formats. A 12-digit number with spaces at the bottom versus a 16-digit number without spaces at the top. On the left, we even have a barcode, and on the right, we don't. And even something as simple as the date of birth uses a slash in one and a dash in the other. Imagine if you had built a template-based extraction system, you would have hard-coded find name

at row three, column one. This might work perfectly on the Aadhaar card, but it would return empty on the Indonesian KTP card. So, when you multiply this across six countries, you're not building a product anymore. You are maintaining a spreadsheet of exceptions. In other words, template-based extraction cannot scale across borders. The solution is ML-based layout understanding, a model that learns the structure of a document type rather

than memorizing fixed field positions. It generalizes across formats without you having to write a new template for every country. And even once you have extracted and structured your data correctly, there is one more layout challenge that trips up a lot of teams, especially when documents cross language boundaries. We know languages look and sound different, but something developers often don't think about until it's too late is how

much space the same content can take up in different languages. Hindi and Tamil can run 30 to 60% longer than English for the same content. When you translate a document and the text expands by half, tables overflow, headers detach, and the page breaks fall mid-clause. The translation is perfect, but the PDF is broken. This is the bilingual layout reflow problem, and the solution can be built on

something called XLIFF, or XML Localization Interchange File Format. This is the industry standard format for passing translatable content between tools. Once translation is done, the content is imported back into the original design rules. Instead of forcing the translated text into boxes that were sized for English, the layout is able to reflow dynamically so that the containers expand and shrink based on the actual length of the translated

string. If a paragraph grows so long, it pushes content onto a new page, the shift is handled automatically across the entire To really show you what this looks like in practice, I will show you a demo through my next few slides. Here is a brochure from a price. And what we are going to do is to translate it from English into Hindi in this demo. First, we

upload this document and click to trigger the translation pipeline. Now, on the left is the approach without XLIFF. It is the typical content replacement approach used by most PDF SDKs. You will take each text string in the document and replace it in place with the translated version. If you notice on the left, there is even code at the bottom to embed the fonts. On the right, we

have the XLIFF reflow approach where there is no font section that is needed to embed it. All right? It is a simple two-method SDK calls. Extract XLIFF and apply XLIFF. The XLIFF reflow process works like First, extract the translatable segments as XLIFF, which is actually a standardized XML-based format. Next, you send this to an LOM translation engine that works only on the content layer. Then, the translated

XLIFF is re-imported back into the document. And most importantly, this new content is combined with the original presentation rules. So, if you look at these two output, comparing with and without reflow, if there is anything that is wrong during the font embedding process, the output will show boxes, as you can see on the left. XLIFF, on the other hand, is magic for document translation. As you can

see on the right, the text is color the the text is correct. The colors are correct. The layout is correct, and the tables hold their structure. The output depicts font colors, margins, and layout very accurately and closely to the original. Now, the reason you didn't have to write explicit font embedding code on the X Lith Reflow approach is because the SDK behind this X Lith Reflow, which

by the way is a priced SDK, treats X Lith Reflow as a high-level smart reconstruction task, rather than a low-level patching. In a standard SDK, you may have to act like a mechanic. You might have to manually go and fetch the font files, check the Unicode ranges, and embed them into the PDF dictionary. But, with the Reflow method, especially with a priced SDK, you can act like

an architect. It will automatically handle the heavy lifting of font engineering automatically in the background, so that automatic system matching system font matching is able to happen. Now, when the SDK passes your X Lith file, it reads the target language attribute. I want it will be able to say, "Oh, I can now search the local system for a font that does support the Tamil Unicode range." Just

because there is this target language attribute that was present in the X Lith file. Now, to demonstrate that this problem compounds with every new language, we will switch the language to Tamil, and then we will compare the output. On the left, you can see that they are all boxes now, and this is because on the content replacement approach, which is the older approach, we did not embed

a suitable font for the Tamil language. So, you can see that in this typical content replacement approach, every new target language requires a developer to be a mechanic sourcing the right font, embedding it correctly, and then testing it. This is manual engineering task for every new language you wish to support. And XLIFF Reflow is able to help you to overcome this problem without having to write a

single line of font embedding code. Let me give you a mental model for what you just saw. Without XLIFF Reflow, it's like taking a printout, scribbling out the English with a marker, and trying to write the Hindi translation in the exact same box. The box was never designed for Hindi. It was never designed for its length. XLIFF Reflow is like sending your document to a professional typesetter

who understands Hindi. They take the content, set it in the right script with the right typeface, and hand you back a properly typeset document where the layout is able to breathe, and nothing is overflowing. So, to recap the the innovations that we have covered today, we have four apex-specific pain points, and four innovations that emerged to solve them. First, do you require multilingual document pipelines? Well, we

have the script-agnostic OCR, context-aware extraction, accuracy scoring for the extraction, and finally normalized structured outputs like JSON. Next, are you experiencing broken script rendering? In the open-source world, we have something called HarfBuzz, which is a dedicated text shaping engine that many rendering systems use under the hood. But, integrating HarfBuzz into a production PDF pipeline is non-trivial because HarfBuzz only takes the one thing in. It takes the

characters in, hands you back correctly shaped glyphs, and what you do with those glyphs after that is entirely your problem. You still have the part where you have to get it into a font, get the font into a PDF, and make sure that the document stays searchable, and is able to extract these new scripts. HarfBuzz doesn't touch any of this, so you may end up building the

rest yourself. Now, iText PDF Calligra does all of this out of the box. Next, we have ML-based layout understanding that is able to work for identity documents across borders. Finally, we have If you are experiencing translations breaking your layout, we have the excellent reflow engine as the perfect solution and magic for your document translation needs. These are niche edge cases. They are the baseline requirements for building

document automation in APAC. And by solving them, we are not just fixing PDFs, we are building the foundation for document pipelines that actually work at scale across borders in any language. That is the reminder I want to leave you with. Documents are now live data pipelines. They are not static records. Every document that enters your system is an opportunity to trigger a workflow, train your data, extract

a structured data, and drive a decision automatically, accurately, and at scale. The shift in thinking is what separates teams that are still manually processing documents from teams that have truly automated their document pipelines. Thank you so much for joining me today, and I hope this gave you a new lens on a problem you might have thought was solved, and maybe surfaced a few challenges you've been quietly

wrestling in your own document pipelines. If you want to go deeper on any of this, whether it's testing our OCR engine, seeing how iText PDF Calligra handles your language scripts, you can come find us at booth one at the price. We would love to dig into your specific use case. Thank you. >> [music]