One route by which characters go missing before an EPUB is built is representability loss when a manuscript is saved in another encoding. If a tool overwrites the file after substituting or dropping characters the target encoding cannot hold, the source text is already damaged before export. Font, conversion, and device-rendering failures are separate causes outside this article.
For this route, check representability before saving to the target encoding and refuse the write when a character fails. This article covers that limited sequence and where to intervene. Finding which characters fail, and reopening a garbled file, are covered separately.
"Missing" and "garbled" are different events
The symptoms look similar; the underlying events are not.
- Garbled — the wrong encoding was assumed on reading. The characters are still in the file, and reopening correctly restores them
- Missing — the encoding could not represent them on writing. The characters are gone from the file, and reopening restores nothing
Recoverable versus not is the decisive difference. Garbled is not an emergency. Missing means that file cannot be brought back.
The order events happen in
- You write in UTF-8. Variant characters and symbols display normally
- For some reason the file is saved in another encoding such as Shift_JIS
- The saving tool writes the file after substituting or dropping characters the encoding cannot represent
- You export without noticing
- The finished book is missing exactly those characters
Step three is the problem. If nothing objects there, no later check can recover anything.
"I'll notice later" does not hold
A missing character does not leave a mark saying it is missing.
If a variant form in a personal name is replaced by a similar standard form, the sentence still reads correctly. Rereading raises no flag. A blank would be noticeable; a plausible substitution is missed even by the author.
Manuscripts are also saved automatically. Saves happen shortly after edits, without a deliberate action. Not remembering the moment of saving means not being able to place the moment of loss either.
And there is generally no way to restore a manuscript that has already lost characters. Without a backup, they have to be retyped. Twenty occurrences means twenty searches.
rune Studio stops the save before the loss
rune Studio will not save while the chosen encoding cannot represent a character in the file.
I verified this by driving the development build from the command line. A test manuscript containing three name variants was asked to save as Shift_JIS. The result: no save, and a report that one character could not be represented in that encoding. No file was written.
To be precise about scope: this refusal to write is what I confirmed when saving from the command line. For saving from the application window, the documentation describes a warning at save time, automatic saving being paused, and an on-screen notice. What actually happens when saving from the window was not verified in this pass. What was verified is the command-line path only.
Checking the same manuscript against Shift_JIS returned exactly one unrepresentable character, with its position and the character itself. The other two variants were representable. So the save stops with a known, single place to fix.
The documentation says automatic saving pauses too
The product documentation says automatic saving pauses while unrepresentable characters remain. The operation test in this pass confirmed only refusal on the command-line save path, not automatic saving in the application window.
That sounds minor and is not. Being unable to save is inconvenient, and the inconvenience is exactly the signal that something needs fixing now.
The documentation says they are marked in red
The product documentation says unrepresentable characters appear against a red background, with consecutive runs grouped. This screen behaviour was not exercised in the operation test.
You still need backups
A save that halts does not remove the need for backups. It halts when a character cannot be represented; it cannot protect you from text you deleted yourself.
The practical habit is duplicating the manuscript folder each time a chapter is finished. One dated folder makes it obvious how far back you can go. Encoding accidents and your own editing mistakes are separate problems, and it is worth having a separate answer to each.
Who this suits, and who is fine without it
It suits anyone handling old manuscripts or files received from others. Even a document you started in UTF-8 picks up other encodings through collaboration and hand-off.
Stay in UTF-8 from start to finish and this barely arises. Everyday Japanese rarely contains anything UTF-8 cannot represent. With no encoding change planned, you can ignore this.
Scope note: what was verified is that the save halts and that unrepresentable characters are reported. Whether a store accepts a given character, or a device renders it, is outside this.
Summary
- Saving to another encoding is one route that can damage source text before EPUB export
- Loss leaves no visible marker, so planning to notice later does not work
- The tested command-line save refused to write and returned the unrepresentable character with its position
- Automatic-save pausing and red on-screen marking come from product documentation and were not exercised in this pass
For a first step, check what encoding your manuscript is currently saved in. If it is not UTF-8, running a representability check once is cheap insurance.
See the current product scope on the Rune Studio product page.
