Convert Files to LWP: Limits of Lotus Word Pro Output

Creating LWP Means Targeting a Retired Word Processor, Not Choosing a Modern Save Option

Converting a file to .lwp means trying to make a document that Lotus Word Pro can consume. LWP is the format associated with IBM Lotus Word Pro, part of Lotus SmartSuite, rather than a general interchange format such as PDF, RTF, or OpenDocument. IBM stopped marketing SmartSuite in 2013 and ended support on September 30, 2014. That history matters: a current office suite can often import an old LWP so that people can leave the format, but the reverse direction is much less common and should be planned as a legacy-delivery task with a named receiving system.

Before creating LWP, identify the exact destination: a specific Word Pro version on an isolated workstation, an old records application that imports Word Pro files, or a test collection for software preservation. If the goal is merely to send an editable file, use DOCX, ODT, or RTF instead. If the goal is a fixed record, use PDF. A file called .lwp is useful only when its receiving software can parse Word Pro's internal data; changing a modern file's extension does not create that data and can leave the recipient with an unreadable file.

The Backward Mapping From Current Document Features to Word Pro Records

A typical LWP file is a proprietary binary document held in an OLE Compound File Binary container. In common Word Pro documents, a WordPro stream carries the word-processing content and associated formatting, fonts, tables, and embedded material. By contrast, a current DOCX commonly packages XML parts, relationships, images, and metadata in a ZIP-based container. Conversion to LWP therefore cannot copy bytes from one container to the other. It must interpret the source model and write an older set of Word Pro records that approximates it.

That approximation has a firm direction-of-travel problem. Modern documents can carry tracked changes, comment threads, accessibility metadata, content controls, web video, sophisticated drawing objects, modern fonts, and features added after Word Pro's product era. A legacy LWP writer has no reliable native place for many of them. Basic paragraphs, headings, character emphasis, simple lists, and straightforward tables are the safest candidates. The right question is not “will every visible item convert?” but “which source features can the receiving Word Pro version represent, and which must be flattened, omitted, or kept in a companion PDF?”

Six Decisions to Make Before Sending a Document Back to LWP

• Name the receiving version: IBM's historic list spans Word Pro 96 through Millennium Edition 9.6, so “LWP compatible” is too vague for a critical transfer.
• Use a simple source: plain paragraphs, basic styles, short tables, and common fonts create fewer unknown mappings than a design-heavy template.
• Resolve tracked changes first: accept or reject revisions and turn comments into ordinary text or a separate review sheet before export.
• Flatten what must look exact: retain a PDF beside the LWP when pages, signatures, diagrams, or branded layout must be seen exactly as approved.
• Test on the receiving system: opening the output in a different modern program does not prove the target Word Pro installation can use it.
• Keep the source and a log: record the source format, conversion tool, date, target version, and any manual corrections.

Why Import Support Does Not Automatically Provide Trustworthy LWP Export

LibreOffice documents a dedicated import filter for Lotus Word Pro 97 and later. Its published developer documentation says the filter parses the LWP document with Lwp9Reader and converts the result through intermediate StarOffice XML. That is useful evidence for recovering LWP content into a current suite. It is not a promise that the suite can write fully faithful LWP from DOCX, PDF, HTML, or every other source. Import and export are separate engineering jobs: importing needs a reader for old records, while export needs a tested writer that chooses valid records and compatible fallbacks for every source feature.

An especially risky source is PDF. A PDF records final page appearance, often in positioned glyphs and drawing commands, rather than the reusable headings, paragraphs, and table structure an editable Word Pro document expects. Turning PDF into LWP first requires reconstruction of that structure, then the legacy mapping. A scanned PDF adds OCR mistakes before either step. If an old application only needs the wording, begin from an original DOCX, ODT, RTF, or plain-text source whenever possible. If the PDF is the only source, compare names, numbers, table cells, and page breaks line by line in the target application.

Do not mistake an importer’s debugging or intermediate files for a user-facing export feature. LibreOffice can expose an lwpimport.xml file when its LWP importer is built for debugging and the DBG_LWPIMPORT_DIR setting is supplied. That fact shows that an old LWP can be interpreted into an intermediate representation; it does not supply a portable recipe for producing a real LWP from arbitrary modern input. For an organization preserving a legacy workflow, a test fixture opened and re-saved by the exact old application remains stronger evidence than a file that merely appears to have the right extension. Put the target version and operating system on that fixture’s cover page so the recipient can confirm it opened the expected artifact. Archive a screenshot of that successful opening with the delivery record.

When the Recipient Says the New LWP Is Corrupt or Looks Nothing Like the Source

The first cause is often a false conversion: a DOCX, RTF, or text file was simply renamed with an LWP extension. Its name ends in .lwp, but it does not contain the compound-document streams and Word Pro records that a real reader expects. The precise fix is to return to an actual LWP-capable export path or, if the receiver permits it, send RTF or DOC instead. Do not try to cure this by selecting another encoding. Character encoding affects text bytes; it does not manufacture a valid proprietary document structure.

The second cause is a valid document with unsupported content. Fonts missing from the old computer can reflow lines; nested tables can widen or collapse; embedded charts and equations may arrive as absent objects or static substitutes. First reduce the source to a controlled test: one heading, two styled paragraphs, a small table, and one image. Open that test in the exact target Word Pro version. Add features in stages until the breaking point appears. For a production package, send both the tested LWP and a PDF reference so the recipient can distinguish a layout difference from a missing sentence or value.

Legacy LWP Output Compared With Safer Delivery Choices

Questions About Making a Lotus Word Pro File Today

Can any file really become a usable LWP document?
No. “Any” describes the input convenience, not a guarantee of feature-for-feature output. A simple text document is far more realistic than a complex PDF, a scanned image, or a DOCX with current collaboration features.

Is changing the extension to .lwp a conversion?
No. A Word Pro reader needs its own binary structures and streams. Renaming a file changes only its label and commonly produces an error or unreadable content in the target program.

Which Word Pro release should I test against?
Use the exact release installed by the recipient. Historical IBM documentation lists versions from Word Pro 96 through Millennium Edition 9.6, and compatibility should not be assumed across every generation.

Why should a PDF accompany the LWP file?
The PDF is a visual reference. It helps the recipient verify page appearance when old fonts, tables, or embedded objects change during the backward conversion.

What is the safest workflow for a critical record?
Keep the original source unchanged, create a small test LWP, open it on the destination system, compare all important content, then deliver the tested LWP with a PDF and a short conversion log.