How to Turn a Manuscript into an EPUB Without Garbled Text

The safest answer to EPUB に する is to keep the approved manuscript untouched, identify the encoding of a working copy, convert that copy to UTF-8, and reopen both the converted text and the exported EPUB. A successful conversion process is not enough. The handoff is ready only after representative wording still matches the approved source and the EPUB contains no missing package resources.

Separate the approved source from the working file

An approved manuscript contains details that are easy to damage silently: names, punctuation, chapter headings, and deliberate line breaks. Preserve that file as the comparison source. Give the working copy a dated name, and perform every conversion or line-ending change on the copy.

This is more than ordinary backup advice. If the source is overwritten, a later reviewer cannot tell whether an unusual character was already present or was introduced during conversion. A stable comparison point turns an argument about appearance into a test with a before and an after.

For final-manuscript handoff, record the source filename, modification time, detected encoding, line ending, and the person who approved the wording. That record marks the boundary between editing and delivery. It does not need to become a refrain throughout the procedure.

Identify bytes before choosing a conversion

A file can look readable in one editor while still being Shift_JIS, UTF-8, or UTF-16. Do not infer its encoding from the .txt extension or from the software that probably created it. Inspect the file and use the observed encoding as the conversion source.

The retained test for this article used a three-line synthetic manuscript. A UTF-8 source was deliberately encoded as Shift_JIS, then opened with Rune’s text inspector. The result reported Shift_JIS, LF, 36 characters, three lines, and no unconvertible candidates.

The next operation created a separately named UTF-8 Markdown file with iconv -f SHIFT_JIS -t UTF-8. Rune reopened that result as UTF-8 with LF and the same 36-character count. The different byte encodings naturally produced different file hashes, but the decoded wording and count remained stable.

These observations apply to the controlled sample. They do not prove that an already-corrupted byte stream can be recovered, nor do they prove that every glyph needed by a real book exists in its chosen font.

Compare meaning, not only counts

Matching character counts can reveal truncation, but they cannot catch every substitution. Select several editorial anchors from the approved source: a person’s name, a chapter title, a dash or ellipsis, and a sentence near the end. Compare each item with surrounding context after conversion.

Context matters because the same character may appear in several roles. A global replacement that repairs one word can damage another. Record the location and approved wording of every manual correction, then rerun the comparison after saving.

If the text is unreadable before conversion, stop. Repeatedly guessing encodings can erase useful evidence. Obtain a known source copy or treat the case as data recovery, which is outside this handoff workflow.

Inspect the packaged result after export

The reopened UTF-8 sample was placed in a dedicated Rune Studio workspace and exported as a small EPUB. The package contained a title page, navigation document, one body XHTML file, and a colophon. Both nav.xhtml and NCX pointed to that body file.

Local EPUB inspection returned valid=true with zero missing resources. This means the generated synthetic package was structurally complete according to the saved local check. It does not mean that a retailer will accept the book or that every reading system will render the text identically.

Rune Studio’s public product documentation describes red highlighting and suspension of autosave when characters cannot be converted. Those graphical behaviors were not observed in this CLI run. The evidence here covers encoding detection, separate-file conversion, reopening, EPUB export, and direct package inspection.

Use a narrow rollback when a check fails

When wording differs after reopening, return to the working text, not to the packaged XHTML. Confirm the source encoding, correct one conversion decision, create a new result, and compare again. This preserves a clear relationship between cause and outcome.

When the wording is correct but the EPUB reports a missing resource, keep the encoding result and inspect the package reference instead. A missing file and a garbled sentence belong to different layers. Restarting both operations together makes the successful part harder to identify.

Retain the command output, exit status, and result hash for the failed attempt as well as the successful one. A short failure history often explains why the final file is trustworthy.

Define the release decision in advance

When two people share the handoff, have both read the same anchors. One reviewer checking only filenames while another checks only visible text leaves a gap between custody and content. Place the observed encoding, wording comparison, and package result on one delivery sheet, then sign off against the same EPUB hash.

The converted manuscript must reopen as UTF-8 with the expected line ending. The selected names, punctuation, and ending sentence must match the approved source in context. The EPUB inspection must show no missing resources. All three conditions belong in the release record.

This method fits an editor who wants a traceable path from a legacy Mac manuscript to an EPUB. It is not a substitute for damaged-file recovery, font coverage testing, retailer validation, or visual review in target readers. Begin by duplicating the approved source and choosing the exact phrases that will serve as editorial anchors. That small preparation makes the later EPUB decision reproducible instead of dependent on memory.