Most developers focus on choosing an open-source or commercial document processing library based on its API surface, performance, ability to merge data, PDF export capabilities, Linux and Windows compatibility, and ease of deployment to the cloud. TX Text Control is an excellent choice for all of this, outperforming most other libraries. However, something is almost always overlooked in such evaluations.

In the real world, what matters most is whether users can design, preview, and adjust templates visually. Without this capability, the full potential of a library is lost. Imagine a developer integrating a document processing library into an application, only to find that users are having difficulty creating or modifying templates. This leads to frustration, an increase in support requests, and, ultimately, user dissatisfaction.

Libraries Miss Too Much

Let's be honest. No matter how powerful they are, document libraries are never a full substitute for a visual editor. The formats they operate on, such as DOCX, are huge and complex. Over the course of decades, a typical document format accumulates hundreds or thousands of properties, legacy behaviors, and layout quirks. Although a processing library can cover many common cases, it will always fall short of the full feature set of a fully capable editor like Microsoft Word. This means that many aspects of real-world documents, such as layout, styling, pagination, tables, images, margins, headers, footers, section breaks, complex fields, and embedded objects, may not be supported, or may only be partially supported, by a library.

Without a visual editor that renders the document as it will appear in the final result, you are essentially guessing. Guesses lead to layout breaking, misplaced elements, incorrect pagination, and formatting quirks. Users will be frustrated when their documents do not look as expected, leading to increased support requests and dissatisfaction.

Visual Feedback Is a Must for Template Creation

If you allow users to create or customize their own templates, such as invoice, letter, or report templates, you must give them the ability to see what the final document will look like.

The following screenshot shows the fully featured TX Text Control document editor, which is a WYSIWYG editor that runs on any platform and in any browser.

A true WYSIWYG editor shows the final document exactly as it will appear, including layout, page breaks, styling, and embedded images or tables. Users can modify the template with full control.

Without this ability, user-created templates become a gamble. Templates may work in some cases but fail in others. Any variation in data, images, or content could disrupt the layout. This requires more support, testing, and maintenance.

Relying on Microsoft Word Is Not a Real Solution

Some teams believe they can avoid the problem by having users create templates in Word and simply feeding them into their automation pipeline. However, using Word for an automated backend solution is risky.

MS Word is not an automation tool. It is a desktop application designed for human interaction. Automating MS Office (server-side or headless) is fragile and often unsupported. It is also prone to errors. MS Word produces extremely complex documents. Many of these features are not recognized or handled properly by libraries. This means that what you see in MS Word may not survive conversion to PDF or processing intact.

Users may insert features or formatting that are incompatible with your automation code. They may use tables, nested objects, custom styles, conditional formatting, or images in unexpected ways. Every creative move in Word can cause your automated process to fail.

Word also limits you to a desktop operating system. For example, you cannot reliably run Word in a Linux container on Azure or AWS. For a modern, cloud-based, scalable solution that relies on automation and flexible infrastructure, this is unacceptable.

You Need an Editor and a Library That Share the Same Core

A robust solution requires two parts that work together.

• The document processing engine or library is used for merging data, exporting to PDF, server-side operations, and automation.
• A true WYSIWYG document editor for designing, previewing, and editing templates and rendering documents exactly as they will be exported.

The following screenshot shows an exported PDF document generated from a template created in the TX Text Control document editor.

You get consistency when those two share the same core layout and rendering engine. What you see in the editor is what you get after exporting. This ensures safe templates and predictable behavior with no surprises.

With a solution like TX Text Control, developers get exactly that. The same layout core powers the editor and server-side document processing. Templates created in the editor will look the same when merged and exported as a PDF or DOCX file.

TX Text Control runs on Windows and offers a Linux-compatible core, so it can be deployed in containers and run in cloud environments, such as Azure or AWS. This provides the automation, scalability, and reliability you need, as well as the visual editing experience your users expect.

What This Means for Real-World Use

Building a document automation system without a WYSIWYG editor forces you into a constant cycle of manual corrections and firefighting whenever documents malfunction. Templates that once worked will suddenly fail due to subtle changes in formatting or layout. The backlog of bug reports will grow. Users lose trust. Maintenance costs will skyrocket.

With a visual editor and processing backend, however, templates become stable assets. Users can create and modify templates through a controlled interface. Developers can automate the generation, merging, and export processes. Deployment works on any operating system and in any environment. You get reliability, predictability, and scalability.

Performance of the Processing Engine

TX Text Control Core provides excellent performance throughout the entire document creation and processing process. The engine is designed to quickly execute layout calculations, efficiently handle large documents, and scale across modern server and cloud environments. Operations such as inserting tables or images or applying bulk formatting run with impressive speed. Inserting five hundred images into a document on Linux takes roughly thirty-four milliseconds, demonstrating the engine's efficiency in handling repetitive or heavy operations.

The platform-independent rendering engine uses an SVG-based drawing pipeline and its own font rendering. This maintains stable performance on Windows, Linux, and container-based deployments while eliminating reliance on platform-specific graphics components. Because the layout engine focuses on memory efficiency and optimized drawing strategies, TX Text Control Core scales well under load. Complex documents, long text flows, and large numbers of templates remain responsive and predictable, even when processed in parallel.

Benchmark Setup

A benchmark suite is used to measure performance by evaluating the execution time of typical document operations. These scenarios include inserting a table with 500 rows and 10 columns, adding text to all cells, inserting 500 images, and applying 500 random formatting operations. The benchmark runs each scenario 5 times and calculates the average execution time.

Learn More

In this article, we compare the performance of TX Text Control Core and Classic when converting plain text to DOCX and PDF. The results show that TX Text Control Core outperforms Classic in both scenarios.

TX Text Control Core vs. Classic Performance Comparison Plain Text to DOCX and PDF

The table below shows the current average execution time for each test scenario on Windows and Linux.

Test Case	Core Windows	Core Linux
Table insertion	7476 ms	7321 ms
Image insertion	40 ms	34 ms
Text formatting	86 ms	96 ms

Conclusion

A document processing SDK alone is insufficient. Neither a library nor a visual editor alone is enough. It takes a combination of both, plus a high-performance engine that scales, to create a stable and scalable document automation system.

Relying on MS Word introduces fragility and prevents the use of modern deployment models. Using open-source libraries without a visual editor results in unpredictable output.

A true WYSIWYG editor that shares the same core as the backend engine is essential for any serious document automation solution.

With TX Text Control, you get exactly that, as well as the performance and scalability that serious projects require.

Learn More

This article shows how to create a simple ASP.NET Core application using the Document Editor and deploy it in a Docker container on Linux. The article shows how to use the NuGet packages and how to deploy the Web server in a Docker container.

Getting Started: Document Editor with ASP.NET Core and Docker Support with Linux Containers