[Tex2002ans]

Originally Posted by RbnJrg

Suppose you want to write an ebook in two languages, one language at the side of the other, paralell columns, so the text doesn't flow from one column to another. You could do it with a table, but a table has many issues with ereaders. In cases like that, a two columns layout is the best option.

The only reason I could think of that needs multiple columns is parallel text in multi-language books.

Besides that minor use-case, I would heavily scrutinize all of the reasons why multi-column text was chosen for a given section...

In physical texts, almost all of the reasons boil down to:

• Physical page size is large
  
  • Example: Newspaper, Magazines, Textbooks
    
  • A single column of text would have too many characters per line and become harder to read.
• Save space/pages
  
  • Example: Indexes, Dictionaries, Technical Papers
    
  • A single page can become more dense. You then need less paper for a given amount of text.
    

In digital text, these decisions almost always fail because the variables can be vastly different:

• You have zero control over device size
  
  • A page can become too small (think cell phone) or much larger (think 4K monitor)
• Users can choose very large font sizes
  
  • If you force X columns, the large text may get mangled.
• Some settings are just best left to the users/programs themselves
  
  • As stumped mentioned, ADE automatically creates another column when the window becomes large + automatically takes into account font size. No need for your code to interfere with that.
    
  • Or programs like Readium allow you to choose Single-/Double-column layout (I don't see why other readers wouldn't allow you to manually choose any # of columns if you wanted to).

Side Note #1: Also, in the case of digital text/ebooks, the horizontal (left/right) width is typically our limiting factor, while vertical (up/down) is "infinite". I discussed this somewhat in Tables in an epub? with an example:

Tables often designed to be "horizontal":

Attachment 111743

where in ebooks, we might "verticalize" them (13x3 -> 3x13):

Attachment 111748

or you may completely reformat:

Spoiler:

Jan. 1836: 14–16
Jan. 1837: 15–17
Feb. 1836: 14–16
Feb. 1837: 14–17

so that they play much nicer with massive font size and/or tiny screen size.

Side Note #2: Another purely typographical decision that was only made to save space/paper are Indexes that are laid out as block paragraphs instead of indented:

Spoiler:

Monticello, TJ moves to, 126–27; building operations, 143–52, 163, 287–88; occupied by British, 357, 362; described by Chastellux, 391–92

could easily be updated to:

Spoiler:

Monticello
	TJ moves to, 126–27
	building operations, 143–52, 163, 287–88
	occupied by British, 357, 362
	described by Chastellux, 391–92

Again, in an ebook there are zero limits on how "vertical" the text can be. Same exact information, just displayed in a slightly different way.

Side Note #3: I also ran into another case of "columns". Sometimes they occur when the book is full of very short footnotes:



I believe most of us would agree it would be absurd to carry these purely typographical decisions over into the ebook. The only reason it was designed that way in the print book was to save pages/space.

Originally Posted by chaot

To make the entries valueable it means making them functionable/clickable. And that would mean an intensive work of months, maybe years. Just now I don't know if I want to do that.

[...]

Please help me to think about. For me it's the first time I do something like that.

If you wanted to code it, you would have to go throughout your entire book and mark exactly where the page break was:

<p>This is a sample<a id="pageII-670"></a> sentence.</p>

Doitsu created a Sigil Plugin called "Incremental IDs" which might help with auto-numbering all those links, but you STILL have to manually place each page break:

https://www.mobileread.com/forums/sh...d.php?t=266120

Then you wrap up your Index using whatever methods (Regex):

<p class="index">Aischylos <a href="../Text/II-Chapter10.xhtml#pageII-670">II, 670</a></p>

There are also 3 different methods of "Real Page Numbers" in EPUB (page-map, pageList, page-list). I discussed them in Post #11 in "Real Page Numbers for Reflowable Kindles":

https://www.mobileread.com/forums/sh...02#post3404302

One method is obsolete, the other is EPUB2, and the other is EPUB3.

Originally Posted by chaot

It would mean at a rough estimate about up to 10000 links + the inline ToC links.
I would have to insert both registers to each volume, ... or making one volume out of three with 3225 (1115/1030/1080) closely printed paper book pages. Scaling the ereader to 22 or 25 lines per screen page, the ePub would got about 6000 to 7000 screen pages. Is that anymore to handle ... by humans and/or the ereader?

You hit the nail on the head with the "pages" =/= "screens". We also discussed "Real Page Numbers" (RPNs) + Indexes + everything to do with how useful "pages" are in these two topics:

Sick of Amazon Kindle books without Page Numbers...
Real Page Numbers for Reflowable Kindles