From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Hendursaga <hendursaga@aol.com>
Cc: orgmode <emacs-orgmode@gnu.org>
Subject: Re: Create in Org a bilingual book with facing pages
Date: Wed, 28 Sep 2022 06:14:21 +0000 [thread overview]
Message-ID: <874jwsauv6.fsf@posteo.net> (raw)
In-Reply-To: <87zgeku66t.fsf@aol.com> (hendursaga@aol.com's message of "Tue, 27 Sep 2022 12:34:50 -0400")
Hi, thank you for your comments.
Hendursaga writes:
>> The bilingual critical edition (ancient Greek/Spanish) of the
>> letters of Demosthenes and Aeschines has recently been published in
>> Spain, a book whose production and typesetting I have taken charge
>> of, using Org and Org-publish.
> What is the name of this book / the publisher's page? I don't really
> know Spanish, and only a little Greek, but I'm fascinated by bilingual
> editions, especially with critical apparati. I've been looking for a
> workflow for creating my own (possibly critical) bilingual works, but
> so far, months later, I haven't really found anything satisfactory.
Demóstenes y Esquines, Cartas atribuidas. Publisher: Dykinson.
Perhaps it is not yet in the catalog, because the book is very recent.
On this page you can see other critical editions (among other books)
that I have produced:
https://maciaschain.gitlab.io/lunotipia/muestra_trabajos.html. Certainly
critical editions are some of the most fascinating kinds of books out
there. My favorites are the Oxford Classical Texts, the Budé Collection,
and Teubner. In bilingual format the Loeb Classical Texts are also
excellent. All these have marked a canon.
>> First of all, for this kind of work you have to take into account an
>> inherent limitation of TeX: the compilation process in TeX is a
>> single-threaded process. That is, in TeX you cannot compile
>> different parts of a document, with different configurations (=
>> different preambles), at the same time.
>
> To clarify: you mean that you would have to have two distinct
> documents so that, say, the page titles, fonts, indices, etc can be
> specific to that "language half" of a work? I would've thought you
> could just have everything in one document. That's how I've been
> (trying to) do it so far, using the reledpar package, an extension of
> reledmac. Did you / have you tried using that? I've also tried various
> other packages, like the parallel package.
I think that the automatic synchronization of the facing pages of a
bilingual editions, either in TeX or in any other software, is a utopia.
Or, to be less radical and pessimistic, that is something possible in
very few scenarios. The ideal scenario would be for text A and text B to
have *exactly* the same number of lines and the same content per page.
This rarely happens. When it comes to poetry in verse it is more common
to happen. But factors such as the corpus of footnotes or the critical
apparatus, which are parts of the page with a variable height, also have
an influence. In the case of this book there was a significant gap
between the two texts. That is to say, that in the end a manual
intervention is necessary to balance the pages according to the content.
In the case of TeX/LaTeX, the single-thread TeX limitation is also
added. Packages like parallel (or paracol, which is newer) work fine
when dealing with simple text. At more complexity they are unusable. And
furthermore, in this case text A is a critical edition that needs its
own configuration. Parallel or paracol simply don't work here.
The case of reledpar could be the solution (since it is a version of
reledmac for parallel texts), but, unfortunately, it almost never is.
Reledpar works fine (more or less) when the scenario I mentioned at the
beginning occurs: if text A and text B are almost identical in length
page to page and paragraph to paragraph. Otherwise, manual
synchronization becomes very difficult and reledpar has a very erratic
behavior. Reledmac is wonderful, but I think reledpar is not a good
package and my recommendation is to avoid using it if possible.
As I said at the beginning, the ideal in TeX/LaTeX would be to be able
to compile with true parallel threads of text with a different
configuration, which is impossible. So my strategy is to create two
separate documents and load them with pdfpages. The good thing is that
Org helps a lot in this process, giving the feeling that I am working
with true parallel threads, since all the processes involved are
asynchronous.
>> On the other hand, since in this book the content of the odd and
>> even pages is variable, the synchronization has been done per page,
>> so that the reader always obtains the same content on the odd and
>> even page when facing the open book. For the Greek document I used
>> the reledmac LaTeX package[...]
>
> I've looked at reledmac, and I agree, it is pretty sophisticated. Can
> you clarify which synchronization method(s) you use? If you do use
> reledpar, in section 6.2.2, it lists the different ways you can
> synchronize. Otherwise, could you try to explain in terms it uses?
You might also want to take a look at ekdosis, a new package for
critical editions. It is not as complete as reledmac (for now), but it
has some interesting features, such as the possibility of exporting to
TEI.
As for what you ask me about the synchronization, this one is visual. It
is inevitable, from what I said before. And I think it is also
necessary. No matter how sophisticated typographic software is, in the
end human intervention is always necessary for things like this, which
depend on content and not on form. And for things like correcting
typographic rivers and such. Maybe in the not too distant future we can
train an IA to do it, but at the moment TeX doesn't understand content
:-). Of course, this synchronization must be done when both texts are
already hypercorrected. It is enough to add some marks to the text,
indicating where to generate a cut. Reledmac has the \ledpb command for
it, which I have redefined like this:
\makeatletter
\renewcommand{\led@check@pb}{\xifinlist{\the\absline@num}{\l@prev@pb}{\clearpage}{}}
\makeatother
>> Once both PDFs are obtained and synchronized, they are loaded into
>> the master Org document using the pdfpages LaTeX package. Since it
>> was necessary to introduce in certain pages some commands specific
>> to each page, such as page styles, index entries or labels for
>> references, and to avoid having to load the pages one by one with
>> pdfpages commands, I wrote a function that obtains the number of
>> pages of the synchronized PDF (via mutool) and it does all that
>> work. [...]
>
> To clarify once more: when you introduce page-specific commands, is
> this in the original PDF documents that you generate, or are those,
> like, trimmed and then you add on the headers etc later, or what?
Page-specific commands (such as page styles, reference labels, and so
on) are not in the original PDFs but are passed through the pdfpages
package, using the 'pagecommand' key. For example, with PDF pages you
can put something like (for page 1):
\includepdf[pages={1},noautoscale=true,pagecommand={\thispagestyle{empty}\label{foo}]{file.pdf}
What my function does is get the number of pages in the PDF and do all
that work, adding the commands I want on the needed page.
>> And that’s it. The next challenge for this fall is going to be a
>> trilingual edition of the New Testament (Greek, Latin, Spanish).
>> [...]
>
> Are you aware of Kevin Klement's trilingual edition[1] of
> Wittgenstein's Tractatus Logico-Philosophicus? (OK, it's technically
> bilingual, but with two separate English translations along with the
> original German!) He uses PHP (gross, I know!) to collate everything
> into a LaTeX document to then generate the various final versions.
> Besides the PHP, you might pick up a technique or two! (Or three!)
Interesting. For critical editions (among other text types for
Humanities), the standard for storing textual data is TEI
(https://en.wikipedia.org/wiki/Text_Encoding_Initiative). The problem
with TEI (at least for me) is that it consists of XML, and I hate XML
:-). In this regard, I think that a lightweight markup language as
powerful as Org could be a good alternative to TEI. And Org is indeed
human-readable. One could even think of a possible Org backend for
TEI...
Best regards,
Juan Manuel
next prev parent reply other threads:[~2022-09-28 6:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 9:09 Create in Org a bilingual book with facing pages Juan Manuel Macías
2022-09-27 12:29 ` Ihor Radchenko
2022-09-27 16:50 ` Juan Manuel Macías
2022-09-28 3:15 ` Ihor Radchenko
2022-09-28 7:50 ` Explicit page breaks (was: Create in Org a bilingual book with facing pages) Juan Manuel Macías
2022-09-29 3:13 ` Ihor Radchenko
2022-09-29 5:29 ` Explicit page breaks Juan Manuel Macías
2022-09-29 6:05 ` Max Nikulin
2022-09-29 6:21 ` Thomas S. Dye
2022-10-03 7:14 ` Ihor Radchenko
2022-10-04 20:24 ` Juan Manuel Macías
2022-10-05 7:59 ` Ihor Radchenko
2022-09-27 16:34 ` Create in Org a bilingual book with facing pages Hendursaga
2022-09-28 6:14 ` Juan Manuel Macías [this message]
2022-09-28 14:14 ` Hendursaga
2022-09-28 15:14 ` Juan Manuel Macías
2022-09-28 7:14 ` Christian Moe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jwsauv6.fsf@posteo.net \
--to=maciaschain@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=hendursaga@aol.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).