HTML/CSS for two columns 'seems' not to function

[stumped]

ok - the OP talked only of having his entire personal register in 2 columns, not an extract.

anyway, that can partially be done because some of the apps/ readers base their decision on when to show 2 columns, based on font and windows size, not CSS, Thus a small font for the extract may make it happen.
for only a smell extract, an embedded image may be the quickest / simplest fix

[RbnJrg]

Originally Posted by stumped

what do you want to view it with

e.g. for ADE (2.0.1 ) on PC , reflowable 2 column is automatic, it is triggered by font and window size.

for (android) kindle app you just tick allow multiple columns etc....

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.

[chaot]

I don't want to let you wait for Monday. But I had to become clear about some issues.

First! User devices dependent ePubs could be done by producing different versions, e.g. a version for Kindle, for KF8, for 'pure' .epub readers, and so on.

Or to use one stylesheet, fitting all, or let's better say some different users devices via media queries: I read some info (a bit theoretical) and the w3 schools page. To understand it right: A Kindle looks in the Styles list for the Kindle reserved stylesheet and uses automatic that one, a KF8 auto-detact the KF8 stylesheet and so on? Fine!

But there is a very real other problem: I couldn't test these versions, as I got only my Tolino 3HD.

Standard lists in <li> tags. By the time @Tex2002ans thought about (#28), they were already done. A personal register (1030) plus a title register (1190 entries).
Especially in regard to the latter and to the size of a Kindle PW or Tolino reader (6 inches), a two columns register seems me not so useful anymore.

The book Werke comes in 6 volumes, but these registers only reference the journalistic work of Joseph Roth, Volume I, II & III. The roman numerals in the register entries indicate these volumes, followed by latin numbers indicating the page numbers. As there are no page numbers in an ePub, the registers introduced to the ePub as a visual copy only would be of limited use/value, while they only would indicate the 'zone', where is to find something (e.g. in beginning, middle or at the end).
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.

That would mean (a more detailed assessment is done): about 6000 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?

Blaming God and ourself!

[chaot]

Hi!

I could just say I was stoned/pissed when I thought about 'languages', or generally understanding problems (and published it). It's not so easy - explaining it's even more complicated, and awkward. So I will leave it alone.

I got very recently a PM (out of the forum) what showed me, how serious some, when not all off you guys, acting here.

Let me gain and retain your favour again. Thanks!

[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

[severus]

Originally Posted by JSWolf

But, there isn't a way to have the text flow from one column to the other if that's what you want.

Originally Posted by RbnJrg

In epub2, no (you can do it in epub3). The two colums layout is to use -like the example- with a book in two languages. Also as alternative to a table.

I'm reviving this very old thread to see if anything changed about having the text flowing from one column to the other on a kindle device. Sadly, I'm unable to show the results of my work because I got nowhere at all.

If anyone could share a sample EPUB - either epub2 or epub3 with the code - I'd really appreciate.

[DNSB]

The only multicolumn epubs I've seen that looked good used epub3 fixed layout where every bloody letter on the page is absolutely positioned so throw out all the epub features like reflowable text.

[Quoth]

Not possible on a proper reflowable ebook that suits different screen sizes of Kindle and font size changes for the user.

Multicolumn was invented for newspapers. The only books that commonly use it are bibles. Fortunately you can get single column bibles. Multicolumn is ghastly on a small screen or small paper page.

[JSWolf]

I can get multi-column in RMSDK but that's it.
: 2
In body, use oeb-column-number: 2;