Extracting Plain Text from Ami Pro .SAM Archives

Text extraction as a triage strategy

The hardest part of a legacy archive project is not converting documents. It is deciding which documents are worth the effort. A decommissioned server might yield 8,000 .sam files, and a meaningful fraction will be duplicates, empty templates, abandoned drafts, and routine correspondence with no retention value. Converting all of them carefully wastes a lot of review time.

Extracting plain text first inverts the problem. One fast batch gives every document a searchable text sibling. Now you can query the archive — for a contract number, a client name, a regulation, a project code — and get an answer in seconds instead of opening files one at a time.

That turns an intimidating pile into a ranked list. The documents that match your queries get a full-fidelity DOCX or PDF conversion and a human review; the rest stay as text plus their original .sam files, indexed and retrievable if anyone ever needs them.

Why you cannot just read the file in Notepad

Ami Pro files are text-based, which fools people into thinking extraction is trivial. Open one in Notepad and you will indeed see words — surrounded by bracketed markup, style definitions, layout instructions, and inline formatting codes woven through the sentences.

Copy that out and you get text contaminated with control sequences. Searches produce false positives on markup keywords, phrases break mid-sentence where a formatting code interrupted them, and tables become unintelligible runs of values. It looks like text extraction and behaves like noise.

Real extraction requires parsing the document structure: separating the style and layout sections from the content, resolving formatting codes rather than emitting them, reconstructing table cells into readable rows, and inserting paragraph boundaries where the document intends them. Same output extension, completely different quality.

Encoding: the detail that decides quality

Ami Pro predates Unicode’s dominance. Documents from the DOS and OS/2 era store text in legacy code pages — one of the DOS pages, or a Windows page such as 1252, or a regional variant for Central European, Cyrillic, Greek, or Turkish content. The same byte value means a different character depending on which page applied.

Get this wrong and you get mojibake: names like Müller become M?ller or Müller, currency symbols turn into random letters, and quotation marks and dashes become gibberish. In an archive of legal or personnel records, corrupted names are not a cosmetic issue — they break the searches you built the text layer for.

The fix is to detect the source encoding and map it to UTF-8 during extraction rather than reinterpreting bytes afterwards. When you test a sample, deliberately choose documents containing accented names, currency amounts, and typographic punctuation. If those come through clean, the encoding handling is right.

Building a searchable index

What you give up

Plain text discards everything that is not words. Styles, fonts, and emphasis are gone, so you cannot tell a heading from a paragraph except by convention. Tables become rows of text that read acceptably for simple grids and poorly for anything with merged cells or nested structure.

Images, diagrams, and equations cannot be represented at all. For a technical archive that is a significant loss, and it is the main reason text should be a triage layer rather than the final output. A document whose substance is a WMF schematic will produce a text file that looks almost empty and tells you almost nothing.

Be explicit about this with stakeholders. "We extracted text so the archive is searchable" is accurate and useful; "we converted the archive" implies a fidelity that text extraction does not provide.

Where text output is genuinely the right final answer

Sometimes text is not a stepping stone. If the destination is a data pipeline — regex extraction of reference numbers, language detection, classification, deduplication, entity extraction — plain text is the ideal input, and any formatting would only be stripped anyway.

It is also the right choice for full-text search infrastructure that stores the text layer separately from the display copy, and for bulk analysis where you want to characterise an archive statistically: how many documents mention a particular contract, how the vocabulary shifts by decade, which departments produced what.

And it is the fastest legitimate way to answer an urgent question. When someone needs to know today whether a 1997 agreement contains a specific clause, extracting text across the archive and grepping for the phrase beats any careful, format-faithful migration plan.