Plain Text Mode silently drops <hr> scene separators (EPUB)

[May47N]

Symptom

In Plain Text Mode, <hr> elements are removed from the output EPUB and
nothing is put in their place. In fiction they usually mark a scene break, so
two unrelated scenes end up running together as continuous prose.

Measurement

One book, 78 XHTML files: 416 <hr> elements in the source, 0 in the
translated output. No textual substitute either — no ---, *** or similar
line appears anywhere in the result.

They are load-bearing in this book. Two examples of what sits on either side
of one:

• a dialogue scene ends, <hr>, then the character is packing in a different
  place at a different time
• a scene ends, <hr>, then the very next paragraph names a different POV
  character and the narration switches to first person as someone else

The second case is the painful one: without the break the reader hits an "I"
that belongs to a different narrator and needs a paragraph or two to work out
what happened.

Cause

src/core/epub/plain_extractor.py:

• BLOCK_TAGS = p, h1–h6, li, blockquote, pre — no hr
• DROP_TAGS = svg, video, audio, iframe, form, script, style — no hr
• CONTAINER_TAGS — no hr

So <hr> is never collected, and since the body is rebuilt from collected
blocks only, it disappears. It is not an explicit drop decision — it just
falls through.

Worth noting the comment right above DROP_TAGS: tables, figures and pictures
are deliberately not dropped, "otherwise that content would be silently
deleted from the output". A scene separator seems to fall under the same
principle.

Suggested direction

<hr> carries no text, so it does not need to reach the model. It only needs
to survive reassembly — e.g. treated as a void block that is re-emitted at its
original position, the way <img> elements are already anchored.

Config

• v1.5.4, Docker, Plain Text Mode enabled
• OpenRouter, mistralai/mistral-medium-3.1, English → Russian
• MAX_TOKENS_PER_CHUNK=1800, PARALLEL_TRANSLATIONS=1

Same book as #253, different problem — filing separately since the mechanism
is unrelated.

[hydropix]

Fixed in #256, now open.

<hr> is collected as a "void block": it keeps its own slot in the paragraph list, is never sent to the LLM (so no extra cost), and is re-emitted as a bare <hr/> at its original position. Attributes such as class are dropped, as they are everywhere else in Plain Text Mode — the separator itself is what survives.

If you can, a confirmation run on the book you reported would be valuable: check out fix/issue-254-plain-text-hr-separators, re-translate it in Plain Text Mode, and confirm the output carries the same 416 <hr> as the source. The automated coverage exercises a synthetic 2-separator EPUB end to end, so a real book is the one thing it cannot replicate.

One thing to expect: the fix adds a paragraph slot per <hr>, so a checkpoint written by an older version for a partially translated file is rejected and that file restarts from scratch. That is a one-time cost, and only for files interrupted mid-translation before the update.

[May47N]

Confirmed on 1.5.6, same book as reported.

	source	1.5.4	1.5.6
<hr> elements	416	0	416

Exact match, all 78 files. Scene breaks are back where the author put them,
including the ones that precede a POV switch — which was the case that made
this worth filing.

Nothing else regressed alongside it: paragraph counts against source are
unchanged, and the same run brought the #253 duplication count to zero.

No checkpoint restart cost on my side, since I had no partially translated
files pending when I updated.

Thanks for the quick turnaround on this one.