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
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.