reverse page order and reverse page numbering in one part of a book
Dear all, I am producing a book that is divided into two sections. The book is published in English, and thus it runs left to right. Part one is an academic study in English. Part two is a critical edition of an Arabic text. The book is exactly 100 pages long, with fifty pages going to the English study, and fifty pages to the Arabic edition. In Part One (which includes all the front matter of the book, such as the table of contents, etc.): the page ordering runs left-to-right, the pagination runs from 1 to 50, and the page numbers should be printed in Arabic numerals. However, in Part Two (the Arabic text): the page ordering should run right-to-left, the page numbers should run in “reverse” pagination (in which “page 1" of the critical edition begins at the “back” of the book), and the page numbers should be printed in Hindi numerals. In other words, the structure of the book’s pages would be as follows (ellipses used to jump): 1 2 3 … 48 49 50 ٥٠ ٤٩ ٤٨ … ٣ ٢ ١ I would like the Table of Contents then to look something like this: Forward . . . . . . v English Study . . . 1 Arabic Edition. . . ١ Index of names. . . ٥٠ So my question is: is this currently possible in ConTeXt, to produce a single PDF, with such a TOC, from one file? Or am I bringing on too much of a headache upon myself, and it is easier to produce two separate files — but if so, how would one produce a TOC that includes the parts and page numbers of both documents? Many thanks, and best wishes, Talal
Dear Talal,
Salaam. See below:
On Wed, 22 Jul 2015 03:49:29 -0600, talazem@fastmail.fm
Dear all,
I am producing a book that is divided into two sections. The book is published in English, and thus it runs left to right. Part one is an academic study in English. Part two is a critical edition of an Arabic text. The book is exactly 100 pages long, with fifty pages going to the English study, and fifty pages to the Arabic edition.
In Part One (which includes all the front matter of the book, such as the table of contents, etc.): the page ordering runs left-to-right, the pagination runs from 1 to 50, and the page numbers should be printed in Arabic numerals.
However, in Part Two (the Arabic text): the page ordering should run right-to-left, the page numbers should run in “reverse” pagination (in which “page 1" of the critical edition begins at the “back” of the book), and the page numbers should be printed in Hindi numerals.
In other words, the structure of the book’s pages would be as follows (ellipses used to jump):
1 2 3 … 48 49 50 ٥٠ ٤٩ ٤٨ … ٣ ٢ ١
I would like the Table of Contents then to look something like this:
Forward . . . . . . v English Study . . . 1 Arabic Edition. . . ١ Index of names. . . ٥٠
So my question is: is this currently possible in ConTeXt, to produce a single PDF, with such a TOC, from one file? Or am I bringing on too much of a headache upon myself, and it is easier to produce two separate files — but if so, how would one produce a TOC that includes the parts and page numbers of both documents?
For getting the Arabic pages to go the other way, I would leave that to the printer and/or post-pdf processing. After all, ConTeXt doesn't care about whether the book itself reads RTL or LTR. OTOH, you may have to reverse some of the \setuplayout parameters (such as margin and backspace) for the Arabic portion of the book. I'm sure you've seen Arthur Jeffery, Materials for the History of the Text of the Quran, for a nicely typeset example of what you are trying to do. Or even Revelation and Falsification edited by Kohlberg [a very misleading and sensationalist title by the way]. If you want to have two books in one, you *may* want to rethink this: Just have an Arabic TOC in the Arabic section (entirely RTL of course) and an English TOC in the English section. The English TOC need only point to the fact that the Arabic edition comes afterwards, and the Arabic TOC could do the same. That said: You could typeset both books as distinct products or components within a single project file - see page 20 of cont-eni.pdf (I once did two books this way). Then you can do cross-references between both books. IIRC you can then take the TOC in one product or component and place it in the other. So in the English book you can place the Arabic TOC and vice versa. Of course you will want to define a separate TOC control sequence for each. So you can get, e.g. \starttitle[title=Table of Contents] \start \LATINFONTOPTIONS \placeENGLISHcontent \stop \start \ARABICFONTOPTIONS \placeARABICcontent \stop \stoptitle which gives you exactly what you want. After all is said and done, the printer can reverse the order of the Arabic pages but that will not affect your TOC. Note that your example has English section names mapped to Arabic/Hindi page numerals (again, I would prefer a purely Arabic TOC). But your section titles in the Edition will not be in English. ConTeXt allows you to use dummy names for section title that will end up in your TOC, and this is documented in the manual I'm sure. Tangent: We need to start looking at the needs of Arabic indices in ConTeXt. Alan Braslau and Hans Hagen are already working on a new bibliography module that will eventually support RTL needs as well. Best wishes Idris -- Idris Samawi Hamid Professor of Philosophy Colorado State University Fort Collins, CO 80523
On Wed, 22 Jul 2015 05:58:04 -0600
Idris Samawi Hamid ادريس سماوي حامد
That said: You could typeset both books as distinct products or components within a single project file - see page 20 of cont-eni.pdf (I once did two books this way). Then you can do cross-references between both books. IIRC you can then take the TOC in one product or component and place it in the other. So in the English book you can place the Arabic TOC and vice versa.
This raises a related, more general question on how to handle multilingual documents. The English first half, Arabic second half is just one example. There are also bilingual texts with left and right columns or facing even and odd pages. We also all know of manuals containing a succession of different languages, sometimes sharing a unique set of figures, sometimes repeating the figures (with differing captions and labels). It is not obvious how to maintain parallel texts containing identical structure in multiple languages (in multiple files?). The project/product/component mechanism can help somewhat. I also know that Thomas had written a streams module to handle the synchronization of texts. However, I am not so sure how to go about this in a real, full-fledged case with a complicated text. Presently, I maintain multiple files that I compare and edit side-by-side using a "diff" tool such as meld (gtk) or kdiff3 (kde). I am sure that other users have good or better solutions that they might want to indicate. The question is how to create a structure that is both readable and manageable? Alan
On 07/22/2015 02:45 PM, Alan BRASLAU wrote:
The project/product/component mechanism can help somewhat. I also know that Thomas had written a streams module to handle the synchronization of texts. However, I am not so sure how to go about this in a real, full-fledged case with a complicated text.
Correction: "Thomas had a streams module written (by Hans)." I used it for a bilingual document for my course material, but in the end, it turned out that using it for a "real" book would have been extremely complex. In my field, there are numerous books with a bilingual layout, but I guess they are all still handcrafted, i.e. manual page breaks etc. I just shudder to think what would happen if someone has to add three words on page 3 of such a book - they would have to redo every single darn pagebreak? Thomas
On Wed, 22 Jul 2015 14:54:17 +0200
"Thomas A. Schmitz"
On 07/22/2015 02:45 PM, Alan BRASLAU wrote:
The project/product/component mechanism can help somewhat. I also know that Thomas had written a streams module to handle the synchronization of texts. However, I am not so sure how to go about this in a real, full-fledged case with a complicated text.
Correction: "Thomas had a streams module written (by Hans)." I used it for a bilingual document for my course material, but in the end, it turned out that using it for a "real" book would have been extremely complex. In my field, there are numerous books with a bilingual layout, but I guess they are all still handcrafted, i.e. manual page breaks etc. I just shudder to think what would happen if someone has to add three words on page 3 of such a book - they would have to redo every single darn pagebreak?
There are several different issues. Synchronization can be line-by-line, paragraph-by-paragraph, sectionblock-by-sectionblock... or, as is the case with the posting of this thread, part-by-part (i.e. halves). The different "products" in multiple languages might only be "synchronized" by structure, not by rendering at all. Maybe Mari (and others) have regular experience in managing multilingual documents and maintaining them under modification. And I bring up this issue under the present thread as managing left-to-right mixed with right-to-left text is a further complication that Idris (and others) address regularly. Alan
On 07/22/2015 03:47 PM, Alan BRASLAU wrote:
There are several different issues. Synchronization can be line-by-line, paragraph-by-paragraph, sectionblock-by-sectionblock... or, as is the case with the posting of this thread, part-by-part (i.e. halves). The different "products" in multiple languages might only be "synchronized" by structure, not by rendering at all.
Yes, and for good measure, add a couple of footnotes, floats, margin inserts, and let the fun begin. I think we'd need a couple of duplicates of Hans to take care of all this... Thomas
On 7/22/2015 4:28 PM, Thomas A. Schmitz wrote:
On 07/22/2015 03:47 PM, Alan BRASLAU wrote:
There are several different issues. Synchronization can be line-by-line, paragraph-by-paragraph, sectionblock-by-sectionblock... or, as is the case with the posting of this thread, part-by-part (i.e. halves). The different "products" in multiple languages might only be "synchronized" by structure, not by rendering at all.
Yes, and for good measure, add a couple of footnotes, floats, margin inserts, and let the fun begin. I think we'd need a couple of duplicates of Hans to take care of all this...
if i get good specs and the demands accept constraints and someone else write the documentation ... we also need to keep in mind that todays needs can be different from tomorrows (and your use of tex / xml is already a proof of this, paper solutions replaced by combinations of typesetting and interaction and ...) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 7/22/2015 3:47 PM, Alan BRASLAU wrote:
On Wed, 22 Jul 2015 14:54:17 +0200 "Thomas A. Schmitz"
wrote: On 07/22/2015 02:45 PM, Alan BRASLAU wrote:
The project/product/component mechanism can help somewhat. I also know that Thomas had written a streams module to handle the synchronization of texts. However, I am not so sure how to go about this in a real, full-fledged case with a complicated text.
Correction: "Thomas had a streams module written (by Hans)." I used it for a bilingual document for my course material, but in the end, it turned out that using it for a "real" book would have been extremely complex. In my field, there are numerous books with a bilingual layout, but I guess they are all still handcrafted, i.e. manual page breaks etc. I just shudder to think what would happen if someone has to add three words on page 3 of such a book - they would have to redo every single darn pagebreak?
There are several different issues. Synchronization can be line-by-line, paragraph-by-paragraph, sectionblock-by-sectionblock... or, as is the case with the posting of this thread, part-by-part (i.e. halves). The different "products" in multiple languages might only be "synchronized" by structure, not by rendering at all.
Maybe Mari (and others) have regular experience in managing multilingual documents and maintaining them under modification. And I bring up this issue under the present thread as managing left-to-right mixed with right-to-left text is a further complication that Idris (and others) address regularly.
To some extend we can typeset in parallel but only with properly structured input (and xml is then probably the best candidate). Anyway I think that the editing is the bottleneck: how does one most conveniently edit in parallel? We might need to think about that first: the typeseting component should adapt, convenient editing is core issue. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (5)
-
Alan BRASLAU
-
Hans Hagen
-
Idris Samawi Hamid ادريس سماوي ح امد
-
talazem@fastmail.fm
-
Thomas A. Schmitz