One EPUB formatting question which I recently got interested in was: how to create a bilingual poetry book? That is, if you want to have a book of poetry in one language with line-by-line translation to another language (to aid a reader who knows the language of the original not too well), how do you do that? In a paper book, a good and well-tried solution is to have the texts in two languages placed on the left and the right page, facing each other. For an e-book, unfortunately, that approach cannot be reused; in particular because with an e-book you usually have only one page visible at a time. Splitting the page into two columns may be acceptable for short citations, but to format a whole poetic collection in this way would be inconvenient, for the columns are somewhat too narrow in this case even on bigger devices.
Here I describe a solution which I find acceptable. Though the problem in question is a rather narrow one, some details of the approach may be useful for other goals as well. In the examples I use the first lines of Catullus 1, with both the original text and the translation taken from the corresponding wikisource page.
There is, in fact, one special reason why I like to use passages from the Roman classics in EPUB examples. An e-book, which is scrolled page-by-page and remains open on the page where you stopped reading it last time, is in these respects amazingly similar to a papyrus scroll, which was what Catullus and Horace and Virgil used. Just think of that: when you are reading The Aeneid on your smartphone, your experience is in a way much closer to that of the original readers than what the generations before us had with codex-format books. Anyway, back to the topic…
The formatting of the poetic lines is done here in the same way as in my earier essay,
with a few small alterations: using dev rather than p as the tag for a poetry line (as proposed by Lee Passey in the comments) and adding page-break-inside attribute to avoid a page break in the middle of a split line (in the readers which support this attribute, certainly). I will not use line chunking here, in order to keep the examples simple and focused on the present topic. The entry in the style sheet goes as follows:
.poemLine {
font-size: 1em;
margin: 0;
border: 0;
padding: 0;
page-break-inside: avoid;
margin-left: 2.5em;
text-indent: -2.5em;
}
The obvious good thing about poetry in our case is that it is split into fixed lines. What if we just place the translation below each line of text, formatting both language versions using the same poetryLine style?
The result is rather unreadable, though the direction is probably not bad. Is there something small to be improved? Sure. Let’s just make a separate poemLine2 style for the translation: almost the same, but with one addition:
color: #808080;
Now the result looks this way:
Suddenly, I almost like it. My only objection is that if the user needs to consult the translation only occasionally, its constant screenspace-consuming presence can be annoying. Stating the problem in a more abstract and general way, it would be nice to have a possibility to create several layers of text in the book (e.g. original and translation in our case) switchable on and off at the user’s will at any time.
Such a concept of an e-book may be useful in more than one case. Imagine reading an abridged verion of a history book, switching to the full version on the passages which you are more interested in, and back when such a passage is over.
Let’s try to get some reasonable approximation of such functionality for our particular case, keeping in mind that the support of scripting in EPUB is optional and so solutions based on scripting are undesirable at the moment.
Luckily, with e-books we are not afraid to make the volume a bit bigger; it weights nothing in any case. So, let’s make two editions, a monolingual and a bilingual one, united in one e-volume and tightly interconnected with hyperlinks all over. That is, the lines in the monolingual part (catullus1.html) are to be formatted as follows:
<div class="poemLine"><a href="catullus2.html#l1_1b" id="l1_1"> + </a>Cuī dōnō lepidum novum libellum</div> <div class="poemLine"><a href="catullus2.html#l1_2b" id="l1_2"> + </a>āridā modo pūmice expolītum?</div>
And the lines in the bilingual part (catullus2.html) are to be formatted as follows (note the invisible elements: they are needed for the black and the grey lines to be aligned correctly together):
<div class="poemLine"><a href="catullus1.html#l1_1" id="l1_1b"> – </a>Cuī dōnō lepidum novum libellum</div> <div class="poemLine2"><span style="visibility: hidden"> – </span>To whom do I give this delightful new booklet,</div> <div class="poemLine"><a href="catullus1.html#l1_2" id="l1_2b"> – </a>āridā modo pūmice expolītum?</div> <div class="poemLine2"><span style="visibility: hidden"> – </span>recently polished with pumice?</div>
If you want to keep every line on the same page with its translation, you may wrap each such pair into an additional div element with page-break-inside style property set to avoid.
Now we have two versions of the page appearance, between which we can switch by clicking on the pluses and minuses (no actual links in the examples below, just the general appearance of the pages is imitated; the a tags are assumed to have text-decoration: none set to switch off underlining, otherwise the little links look worse). The link near every line ensures that you are always directed to the right page of the other version (because, obviously, one monolingual page corresponds to several bilingual pages).
A bit strange, but, hopefully, convenient enough (I have tried it in Aldiko on an Android phone). There is much space for task-specific alterations, certainly. You may create an option to leave only the translation on the screen; or make three layers for each line instead of two (e.g. original + translation + commentary), or design a nicer and more convenient appearance for the links (the simple ones are sometimes easy to miss with the finger), and so on. So, good luck to anyone who is going to experiment with that.
Anton. Excellent. Great work. A year or so ago we did thousands of pages of poetry with line notes giving colloquial meaning of old English. It was a nightmare. The poems had line-numbers, line notes, footnotes, poem end-notes and book-end notes. We used spans everywhere. It worked but was not elegant.
This approach is structurally sound, elegant, easy to create, and has a lot of future reuse value and opens processing options. I would tend to use lang attributes as well, but that is a detail. This will handle combos like Arabic, scripting languages and Latin magnificently.
I disagree with the concept of using a div as a poetry line, mainly because it isn’t a div. A paragraph in a div class=”stanza” is a poetry line. It’s structural inheritance. A poetry line has all the behaviours of a paragraph. It is a meaningful unit of content in poetry, it has alignment and text-indent properties, the end behaves like a paragraph (IE it must force a new line), and the accessibility behaviour is predictable. I will continue to use the backbone of content, the magnificent for poetry lines.
IMHO reading device behaviour should never be considered when creating a master, valuable XHTML. Time is too valuable to tag for current device limitations. Tag up for the best interpretation of the structure, semantics and processing. Process down for presentation dumb devices (Kindle).
Richard,
thank you for the comment! Hope that this approach will prove useful.
From the formatting point of view, with “p” and “div” the approach is equally usable. As for the particular choice, I see the point in both opinions; the poetry lines behave like paragraphs technically without being paragraphs semantically. In general, while formatting poetry I feel that HTML as it is provides satisfactory means for formatting poetry but “does not really have poetry in mind”, so some contradictions of that sort are probably inevitable.
That is a great idea! Thank you for sharing.
I am currently working on a similar case. My approach has been switching completey from one language to the other. But placing the translation below each line the way you did makes sense for my project as well.