December Adventure Day 14
Dec 14, 2025 - ⧖ 2 minPublished as part of 'December Adventure 2025' series.
This morning I continued my adjustments to make Frankenstein work.
Each xhtml file in a Standard Ebook epub file basically looks like this:
<?xml version="1.0" encoding="utf-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:epub="http://www.idpf.org/2007/ops"
lang="en-GB"
epub:prefix="z3998: http://www.daisy.org/z3998/2012/vocab/structure/, se: https://standardebooks.org/vocab/1.0" xml:lang="en-GB">
<head>
<title>Chapter XXIII</title>
<link href="../css/core.css" rel="stylesheet" type="text/css"/>
<link href="../css/local.css" rel="stylesheet" type="text/css"/>
</head>
<body epub:type="bodymatter z3998:fiction">
<section id="chapter-23" role="doc-chapter" epub:type="chapter">
<h2>
<span epub:type="label">Chapter</span>
<span epub:type="ordinal z3998:roman">XXIII</span>
</h2>
<p>It was eight o’clock when we landed...</p>
<p>...</p>
<p>...</p>
...
</section>
</body>
</html>
One assumption of the script that splits up the xhtml files is that
each immediate child of the <body>'s <section> will be "small". So
all it does is take each child, see if adding it to the current chunk
is still within the size threshold and either add it or make a new
chunk.
However, Frankenstein proved that assumption false. There were two
examples of children that were big: another <section> and
<blockquote>. The <blockquote> examples are kind of fun, because
Frankenstein is a story-within-a-story (-within-a-story...).
Today's solution was to "unwrap" <section>s. A <section> doesn't
do anything in a fediverse post, so it seems safe to do that.
<blockquote>s impact rendering so I'm unwrapping it, but re-wrapping
each child in its own <blockquote>. So this:
<blockquote>
<p>Three be the things I shall have till I die:</p>
<p>Laughter and hope and a sock in the eye.</p>
</blockquote>
Becomes this:
<blockquote>
<p>Three be the things I shall have till I die:</p>
</blockquote>
<blockquote>
<p>Laughter and hope and a sock in the eye.</p>
</blockquote>
Semantically bad, structurally questionable, but renders fine.
Good enough for me.