# Architecture

> Run the Document Viewer in ASP.NET Core: the tx-document-viewer web component, TextControl controller, streamed pages, render modes, PDF.js and access tokens.

- **Product:** TX Text Control .NET Server
- **Section:** Documentation
- **Kind:** Topic
- **Path:** TX Text Control .NET Server > Document Viewer > Architecture
- **1867 words**
- **Web URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/architecture/
- **LLMs URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/architecture/llms.txt
- **LLMs-Full URL:** https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/architecture/llms-full.txt

---

Deploying the Document Viewer, hosting it next to the Document Editor or connecting a separate frontend all depend on how the viewer works at runtime: which parts run in the browser and on your server, how a document reaches the browser, how PDF documents are displayed and how the endpoints of the backend are protected.

[Product Architecture](https://docs.textcontrol.com/tx-text-control-dotnet-server/overview/architecture/#document-viewer) gives the overview of all components; this page goes into the details of the viewer.

### The Parts of the Viewer

The viewer consists of a frontend in the browser and a backend in your ASP.NET Core application:

```text
Browser: tx-document-viewer web component, TXDocumentViewer object
        |
        |  HTTP requests to /TextControl
        v
Your ASP.NET Core application: TextControl controller
(package TXTextControl.Web.DocumentViewer or TXTextControl.Web.DocumentViewer.Classic)
        |
        |  in the same process
        v
TX Text Control engine: Core or Classic
```

- **The frontend** is a web component with the element name `tx-document-viewer`. Each instance has its own encapsulated markup and styles, so a page can contain several viewers. The HTML helper of ASP.NET Core and the plain JavaScript setup create this component. The Angular and React components load the same viewer script from the backend and initialize the viewer in an element of their own. All of them share the JavaScript API, the [TXDocumentViewer](https://docs.textcontrol.com/tx-text-control-dotnet-server/reference/javascript-document-viewer/txdocumentviewer/llms-full.txt) object.
- **The backend** is a controller named `TextControl` that the viewer package adds to your application. Every request of the viewer goes to it, including the viewer's own scripts, which it serves at `/TextControl/GetResource`.
- **The engine** loads the document and renders its pages in the process of your application. The viewer needs no separate backend process and no WebSocket connection, unlike the Document Editor.

How the backend is added depends on the application:

| Application | What it needs |
|---|---|
| ASP.NET Core MVC | Nothing beyond the packages: the controller routing of the template is enough, as the [ASP.NET Core](https://docs.textcontrol.com/tx-text-control-dotnet-server/getting-started/document-viewer/aspnet-core/llms-full.txt) tutorial shows |
| ASP.NET Core Web API for Angular, React or JavaScript | `app.UseTXDocumentViewer()` in *Program.cs* and a CORS policy, as the [Angular](https://docs.textcontrol.com/tx-text-control-dotnet-server/getting-started/document-viewer/angular/llms-full.txt) tutorial shows in "Configure Program.cs" |
| Blazor Web App | Registered controllers and `app.UseTXDocumentViewer()`; the blog article [Getting Started: Document Viewer for Blazor in ASP.NET Core](https://www.textcontrol.com/blog/2025/03/25/getting-started-document-viewer-for-blazor-in-asp-net-core/) shows the setup |

A separate frontend sets its `basePath` to the URL of the backend, for example `https://localhost:7275`. Because frontend and backend run on different origins, the backend must allow cross-origin requests.

### How a Document Reaches the Browser

1. The page with the viewer loads, and the viewer component initializes. The pages of the document are loaded asynchronously afterward, so the viewer doesn't delay the loading of your page.
2. The backend loads the document, from a file set with `DocumentPath`, from data set with `DocumentData` or from data that `loadDocument` sends at run time. [Loading Documents](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/loading/llms-full.txt) describes the three ways.
3. The engine renders the pages. Since version 32.0 SP3, the viewer loads documents with long polling: the server keeps the request open and streams the pages as it generates them. Users read and annotate the first pages while the rest of a long document is still processed. In the developer tools of the browser, these requests appear as fetch requests.

The blog article [Document Viewer: Long Polling Support for Loading Documents](https://www.textcontrol.com/blog/2024/04/25/document-viewer-long-polling-support-for-loading-documents/) shows this with a document of 196 pages.

### Render Modes

The engine renders pages in one of four ways, set with [DocumentViewerSettings.RenderMode](https://docs.textcontrol.com/tx-text-control-dotnet-server/reference/txtextcontrol-web-mvc-documentviewer/documentviewersettings/rendermode-property/llms-full.txt), a value of [ComponentRenderMode](https://docs.textcontrol.com/tx-text-control-dotnet-server/reference/txtextcontrol-web-mvc-documentviewer/componentrendermode/enumeration/llms-full.txt). The mode decides how sharp the pages look when users zoom in:

| Value | Renders pages as | Notes |
|---|---|---|
| `Auto` | The format and method the viewer chooses to balance performance and appearance; the default | Recommended for most applications |
| `Bitmap` | Images | Can be less sharp when users zoom in; small text looks smooth at lower screen resolutions, such as Full HD |
| `GlyphOutlines` | Vector graphics, with the text drawn from the outlines of its glyphs, so no fonts are needed on the client | Suits high screen resolutions such as 4K; small elements can be hard to read when scaled down |
| `Font` | Vector graphics with embedded text, drawn with the fonts available on the client | Requires the fonts of the document on the user's computer |

The responses of `Font` are the smallest and those of `Bitmap` the largest. The following settings render all pages as vector graphics:

```cshtml
@Html.TXTextControl().DocumentViewer(settings => {
    settings.DocumentPath = "App_Data/template.docx";
    settings.Dock = DocumentViewerSettings.DockStyle.Fill;
    settings.RenderMode = ComponentRenderMode.GlyphOutlines;
}).Render()
```

The blog article [Document Viewer: Setting the Rendering Mode](https://www.textcontrol.com/blog/2024/08/22/document-viewer-setting-the-rendering-mode/) compares the modes.

### How PDF Documents Are Displayed

TX Text Control has no PDF renderer of its own. By default, the engine imports a PDF document and converts its content into a document of its own, which can look different from the original; for displaying PDF documents exactly as they are, the viewer can use PDF.js, the PDF renderer of Mozilla, in the browser instead. [Load PDF Documents With PDF.js](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/loading/#load-pdf-documents-with-pdf-js) compares both and shows the settings.

### Protect the Endpoints

Every request of the viewer goes to the `TextControl` controller, so protect its endpoints: the view passes an access token in the query string of [BasePath](https://docs.textcontrol.com/tx-text-control-dotnet-server/reference/txtextcontrol-web-mvc-documentviewer/documentviewersettings/basepath-property/llms-full.txt), the base URL at which the viewer calls the controller, and a middleware registered before `app.UseTXDocumentViewer()` rejects requests without a valid token. [Access Tokens](https://docs.textcontrol.com/tx-text-control-dotnet-server/security/access-tokens/#check-the-requests-of-the-document-viewer) shows the middleware and how the token is issued and passed from each frontend.

### Engines

The backend uses the engine of the packages you install: `TXTextControl.Web.DocumentViewer` with `TXTextControl.TextControl.Core.SDK` for the Core engine on Windows and Linux, or `TXTextControl.Web.DocumentViewer.Classic` with `TXTextControl.TextControl.ASP.SDK` for the Classic engine on Windows. The Core engine doesn't load DOC documents, and it loads RTF documents since version 34.0. [Supported File Formats](https://docs.textcontrol.com/tx-text-control-dotnet-server/overview/file-formats/llms-full.txt) lists the formats of each engine.

### The Viewer and the Document Editor in One View

Both components can run in the same application and even in the same view: the viewer sends HTTP requests to its controller, while the editor keeps a WebSocket connection to its middleware and the separate backend process described in [Architecture](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-editor/architecture/llms-full.txt) of the Document Editor. Because both packages define an `Html.TXTextControl()` helper, a view that uses both creates the viewer in code; [Show the Editor and the Viewer in One View](https://docs.textcontrol.com/tx-text-control-dotnet-server/integration/aspnet-core/#show-the-editor-and-the-viewer-in-one-view) in the Integration Guide shows such a view.

### Next Steps

- [Loading Documents](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/loading/llms-full.txt): pass documents to the viewer.
- [JavaScript API](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/javascript-api/llms-full.txt): control the viewer in the browser.
- [Browser Requirements](https://docs.textcontrol.com/tx-text-control-dotnet-server/installation/requirements/browsers/llms-full.txt): what the network between browser and server must allow.

---

## Nearby

- **Previous:** [Document Viewer](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/llms-full.txt)
- **Next:** [Loading Documents](https://docs.textcontrol.com/tx-text-control-dotnet-server/document-viewer/loading/llms-full.txt)