Convert RTF to ODT

RTF was designed to move a formatted document from one program to another, and it is very good at that. It was never designed to be the format a document lives in while somebody works on it for a fortnight, and the difference shows up in a way that is easy to miss: every time you press save, Writer serialises the whole document through the RTF filter and reconstructs it from that text on the next open.

Anything the filter has no representation for is approximated or dropped at that moment. Some field types, certain section and frame properties, particular list configurations and the finer parts of the style model do not have RTF equivalents, and the loss is silent because what you see on screen still looks like the document. One round trip is usually invisible. Twenty of them, on a file being edited daily by a translator or an editor, is not.

The pattern is always the same shape: a program upstream that emits RTF, and a person downstream who has to work on it in LibreOffice. Translation agencies send source files as RTF because it is the format every CAT tool and every client can read. Transcription and dictation platforms return drafts as RTF. Small publishers take submissions in it because it is what an author on any machine can produce. Qualitative research tools export coded documents to it.

None of those senders are going to change, and none of them should — RTF is the correct choice for the handover precisely because it is the format nobody can fail to open. The mistake is treating the handover format as the working format. Convert on arrival, work in ODT, and export back to whatever the client wants at the end. That is one conversion at each boundary instead of one on every save.

An RTF is characters. Open one in a text editor and the prose is there in plain sight, surrounded by backslash-prefixed control words describing the font table, the colour table, the style sheet and the formatting of each run. It is verbose, entirely printable, repairable by hand, and validated by nothing at all — a file that is slightly wrong usually opens, slightly wrong.

An ODT is a ZIP archive containing XML: `content.xml` for the text, `styles.xml` for the styles, a manifest, and the pictures as real files in a folder. The registry marks it as a container with an ISO standard behind it and lists LibreOffice Writer, Microsoft Word and Google Docs as software that reads it. You can unzip one and grep the XML, which is a genuinely useful property when a document has gone wrong or when a hundred of them need the same substitution.

Two compounding reasons. First, the ZIP: the XML inside an ODT is deflated before it reaches disk, and XML compresses extremely well because it repeats its own tag names constantly. RTF has no compression at all and stores every control word literally.

Second, pictures. An RTF writes an embedded image as hexadecimal text — about two characters per byte of picture — while an ODT stores the original image file in the archive untouched. A document with half a dozen screenshots can be an order of magnitude larger in rich text than in OpenDocument. If the RTF you were sent seemed impossibly large for a twelve-page letter, that is why, and the conversion fixes it without anyone having to think about it.

RTF does have styles, which is more than its age suggests and the reason this conversion works as well as it does: named paragraph styles, headings, character styles, fonts, sizes and spacing map onto their OpenDocument equivalents rather than being flattened into direct formatting. Tables keep their cells, borders and merges; lists keep their numbering; headers, footers, footnotes, hyperlinks, bookmarks and page setup all have representations on both sides.

What OpenDocument adds is depth the older format has nowhere to put. Page styles are first-class objects rather than section properties, list styles are defined once and reused, and the separation between `content.xml` and `styles.xml` means a document’s appearance can be replaced wholesale without touching a word of the text. For anyone who intends to restyle a stack of incoming documents to a house design, that separation is the whole argument for converting first.

An RTF declares a character set and escapes anything outside plain ASCII against it. That was reasonable in 1987 and it is a standing source of mangled text now, because a file written by an old program on a machine with different regional settings can name a code page that does not match what it actually holds. Accented names, Central European characters, curly quotes and dashes are where it shows.

A conversion cannot repair it, and knowing that saves an afternoon. If the RTF already displays wrongly in Writer, the characters in the file are wrong and the ODT will carry the same wrong characters across faithfully. OpenDocument is Unicode throughout, so once the text is correct it stays correct — which means the right move is to fix the affected text once, immediately after converting, rather than at the end of the project when it has been copied into three other documents.

Working in ODT does not commit you to delivering one. Writer exports to DOCX, to RTF, to PDF and back to plain text, and the registry lists Microsoft Word among the programs that read OpenDocument directly, so even sending the ODT itself is a defensible choice with most clients. The point of converting is to make the export a single deliberate act at the end rather than an accident that happens every time you press Ctrl+S.

If the deliverable has to be RTF — because the agency’s tooling wants it, or the client’s system does — export to RTF once, from the finished ODT, and check the result before sending. One trip through the filter loses very little and it is a trip you chose. Keep the ODT as the master copy, because that is the file that still holds everything, and treat the exported RTF the way you would treat a PDF: an output, not the document.

On our server rather than in your browser. Converting between two word-processing formats needs a real office engine, and this page says so plainly rather than implying that everything on this site runs locally. The file travels over an encrypted connection to a container running LibreOffice headless, and that container has no outbound internet access of its own.

Every job is given its own scratch directory and its own LibreOffice profile — two `soffice` processes sharing a profile corrupt it, and the symptom is a conversion that never returns rather than an error — and the directory is deleted when the job ends whatever the outcome. Anything still running after sixty seconds is terminated. The free tier accepts 25 MB per uploaded file, which for an RTF is less document than it sounds, since the format is so much larger than what it holds.

Check the style list before you check the text. If the document arrived with a sensible set of named styles you have the good case and everything downstream is easy; if it arrived as one style with a great deal of direct formatting, the originating program never used styles and no conversion can invent them. Knowing which of those you have decides whether restyling is a menu choice or a job.

Then look at the three places that carry the risk: tables with merged cells, multi-level list numbering, and the point where a long document breaks between pages. If the file is one of a batch from the same source, checking one carefully tells you almost everything about the rest, because the failures come from the emitting program’s habits rather than from the document. Keep the original RTF until the first document has been through your whole process once — it is the only record of what the sender actually produced.