[texhax] typesetting a critical text edition [parallel]

[Sergei Mariev]

It seems to me an excellent solution. I wish I implemented it in my  
recent two critical editions... (Instead I was combining the source  
code fromt two latex files into one single .tex file with a very  
simple perl script... which means typsetting the whole document at  
least ten times for every single page break... months of sitting in  
front of the computer...)

Does anyone know of a terminal utility for Mac that splits pdfs into  
single pages and then recombines the files again to a single  
document? This way typestting synoptical critical  editions with  
ednotes would become really an enjoyable task!



Dr. Sergei Mariev
Akademischer Rat a. Z.
Institut für Byzantinistik der
Ludwig-Maximilians-Universität München
Tel.: +49 (0) 89 2180 5475
Mob.: +49 (0) 163 846 6200
Fax: +49 (0) 89 2180 16520




Am 20.06.2009 um 12:06 schrieb Uwe Lück:

> I know some people who worried about parallel typesetting for  
> translations and am distributing Pierre MacKay's[1] advice among  
> them. I am focussing here on the practical aspect of how you could  
> obtain the "parallel" feature.
>
> At 01:41 20.06.09, Pierre MacKay wrote:
>> Uwe Lueck wrote:
>>
>>> 3. For "original" even pages, "translation" odd pages, there is  
>>> always the "brute" method: typeset original and translation as  
>>> different LaTeX documents, augmenting the page number by 2 each,  
>>> print them, sort the pages at a table using your hands, eyes,  
>>> brain ... Roy Flechner told me that the fancyhdr package is  
>>> helpful for this.
> [...]
>> For facing translations, I set  verso pages in one file, using an  
>> increment of 2 for pagination, and recto pages in a separate  
>> file.  I can then do fine control of page ends with two instances  
>> of xdvi.  To blend the two files, I use dviselect and dviconcat,  
>> driven by a fairly simple bash script.
>
> Apart from dviselect[2] dviconcat[3] There also is dvitodvi.[4]  
> Some may need to know that xdvi is a UNIX previewer and that the  
> same can be done with YAP etc.
>
> After some thinking it seems to me that this method isn't just a  
> workaround, but the preferable way. This way you move manual page  
> breaks, otherwise you must move text around in the file.
>
> An aspect somewhat intermediate between the practical and  
> philosophical one is that some workers *do not know* how to use  
> dviselect and dviconcat and bash -- e.g., sitting at their PC or  
> notebook equipped with Windows.
>
> However, they could ask an IT group for the humanities or at the  
> math or physics department of their university. Either somebody  
> skilled does the dvi things, or you can get Windows versions of  
> these utilities. (?)
>
> I even know some who stick to DOS -- not so bad! -- they might  
> learn that Linux -- bash! -- is smarter -- and you get better  
> support for utilities and programs for Linux! This is about what  
> Pierre MacKay indicates in the more philosophical passages of his  
> posting:
>
>> The argument for the chain of programs is that each utility is  
>> doing what it does best, cleanly, and in a way that can easily be  
>> traced if anything goes wrong.  The Microsoft black-box solution,  
>> cramming every task into the same gargantuan utility, no matter  
>> how inappropriate, produces constant frustration, because the  
>> resultant programs become so complex that even their authors can't  
>> trace the errors.
>
> I go on in a second posting, because some people who get the  
> present one certainly don't want to see the rest.
>
> -- Uwe Lueck.
>
> [1] <pierre.mackay at comcast.net>
>
> [2] http://www.ebs-euchner.com/Portals/0/alphadidact/ 
> alphadidact_DVI.pdf
>
> ?? -- or rather:
>
>     http://www.ctan.org/tex-archive/dviware/dvibook/Dviselect/
>
> [3] http://www.ctan.org/tex-archive/dviware/dvibook/Dviconcat/
>
> [4] See README at
>
>     http://www.ctan.org/tex-archive/dviware/dvibook/
>
>