DS Server

Linux

Topic

Since version 4.0, the Core build of DS Server runs on Linux, on virtual machines, bare-metal servers, in Docker containers and on Linux platform services. It handles fewer formats there than the Classic build on Windows, and it brings its own fonts instead of using those of the system. A document process that works on a Windows installation can therefore fail or look different after a move to Linux; the problems below show where, and what to change.

Problems that aren't specific to Linux, such as a server that ends at startup, are on Installation.

A Document Format Isn't Supported

Your application converts documents to DOC or RTF, or merges DOC templates, and the same requests are to run on a Linux installation.

The change log of version 4.0 limits the Linux version to these formats:

Supported on Linux
Document formatsDOCX, HTML, PDF and XLSX
Image formats, load and savePNG, JPG and BMP
Image formats, load onlyTIFF and GIF

DOC, RTF and the TX Text Control format TX aren't in this list, neither as returnFormat values nor as input documents or templates, so the change log gives no support for them on Linux.

  1. Check the formats your application sends and requests against the table. Supported File Formats lists the formats of each endpoint.
  2. Use DOCX for templates and documents, and PDF or DOCX as return formats.
  3. If your application needs DOC, RTF or TX, run the Classic build on Windows. Core and Classic compares the builds.

Page Images Can't Be Rendered as Bitmaps

Your application requests page images as PNG, JPG or another bitmap format, and DS Server runs on Linux.

The change log of version 4.0 states that the Linux version renders documents as SVG only; it has no bitmap rendering.

  1. Request page images from POST /documentprocessing/document/thumbnails with the image format SVG, which the endpoint supports since version 3.2.0.
  2. If your application needs bitmap page images, run the Classic build on Windows.

Text Appears in Another Font

Documents created on Linux use other fonts than on Windows, and line and page breaks move.

Since version 4.0, DS Server brings its own font system, and fonts no longer have to be installed on the server. The core folder contains a Fonts folder with a set of open fonts, among them Liberation Sans, Liberation Serif and Liberation Mono, Lato, Merriweather and Roboto. The classic folder has no such folder. A document that uses a font the Fonts folder doesn't have is rendered with a replacement font with other character widths.

  1. List the fonts in the Fonts folder of your installation. Their licenses are in Fonts/licenses.txt.
  2. Compare them with the fonts of your templates, and use fonts from the folder in templates that DS Server processes on Linux.

The Core build uses the Core engine of TX Text Control. The .NET Server's page Fonts explains how this engine chooses a replacement font and how to find out which fonts are replaced.

The Server Has an ARM64 Processor

You plan to run DS Server on a Linux server or container with an ARM64 processor, or on a distribution without the GNU C Library, such as Alpine Linux.

For Linux, the core folder contains the native libraries of the document engine only in runtimes/linux-x64/native: they are built for x64 processors and linked against the GNU C Library (glibc). The newest symbol versions they require are GLIBC_2.34 and, from libstdc++, GLIBCXX_3.4.29. Besides the C and C++ runtime libraries, libc.so.6, libm.so.6, libdl.so.2, libpthread.so.0, libstdc++.so.6 and libgcc_s.so.1, they need no library of the system.

  1. Run DS Server on an x64 server or an x64 container image.
  2. Use a distribution based on glibc 2.34 or later, for example a current Ubuntu or Debian. On Debian and Ubuntu, the packages libc6, libstdc++6 and libgcc-s1 provide the libraries. The .NET Server's page Linux describes the same requirements of the native libraries of TX Text Control 34.0, which DS Server 5.0 is based on.

The Service Writes Its Log to Another Folder

DS Server runs as a service, but its logs folder stays empty or doesn't exist.

The log folder in appsettings.json, ./logs, is relative to the working directory of the process, not to the installation folder. A service that starts DS Server from another directory writes its log there.

  1. Start DS Server from its installation folder, for example with the working directory of the service set to that folder.
  2. Or set the environment variable Logging__DSServerFile__Options__FolderPath to an absolute path, such as /var/log/dsserver, and give the account of the service write access to it.

Related Pages