Table of Contents

Class LegacyDocOptions

Namespace
DocToolkit
Assembly
DocToolkit.Primitives.dll

Controls how DocToDocxConverter treats content a Word 97-2003 binary document holds but a .docx package cannot be given.

public sealed class LegacyDocOptions
Inheritance
LegacyDocOptions
Inherited Members

Remarks

There is one setting, and it defaults to the safe answer. A legacy .doc stores pictures, drawings and form fields in a binary Data stream that the import can see but cannot carry across. By default the conversion refuses rather than silently producing a .docx missing those payloads — set AllowContentLoss to accept the loss deliberately.

This is the common case, and the measurement is now at scale. Across 111 real .doc files from a public .gov crawl, measured 2026-08-17, the default succeeded on 12 of them

  • 11%, while the opt-in succeeded on 99 (89%). A .doc holding a table carries the stream; plain text, bold runs and headings do not. Tables are ordinary, so expect the opt-in to be needed rather than to be an exception - and prefer DocToDocxConverter.ConvertWithReport, which returns the same bytes and names what was dropped.

Reading is never affected. DocToDocxConverter.ExtractText takes no options and never refuses: text is not what the binary stream holds, so there is nothing for a policy to decide.

Properties

AllowContentLoss

Convert even when the source holds content the .docx cannot carry, instead of throwing. Defaults to false.

public bool AllowContentLoss { get; init; }

Property Value

bool

Remarks

What is lost is the unprojected binary payload — pictures, drawings and form fields. Measured 2026-08-16: text, tables (every cell), and character formatting such as bold all survive the conversion intact, so this accepts a specific, bounded loss rather than a general "best effort".

Prefer DocToDocxConverter.ConvertWithReport when setting this: it returns the same bytes and tells you exactly what was dropped, so the loss is recorded rather than merely permitted.