A question about “vertical scroll”

[Paolo Carnovalin]

Hi guys!
I am creating an ebook (reflowable epub3) that contains many tables of different sizes.
The best readability of the book is achieved in 'vertical scrolling' mode. But I ask you: is it a common feature for all ereaders to be able to set reading in vertical scrolling mode?
I have tried it with iPad. What experience/reader do you have?

[Turtle91]

iPads "Books" app does it, so does Marvin (on iOS), so do desktop readers/viewers such as Sigil and Calibre. I'm not very familiar with the other devices/apps but I would not design a commercial book expecting their device/app to do that.

There have been a couple discussions here about tables and proper best-practice formatting (Tex will pop in here in a little bit with the links ). Generally speaking, 2 - 3 columns max is acceptable for text that really needs to be in a table; try and display the text in an alternate (reflowable friendly) format if possible. If the table must be larger than that, then it's better to embed an image of the table. BEWARE: Audio listeners will lose the information presented if you do this.

[Quoth]

Assume
1) No vertical scrolling
2) Many epub3 features won't work.
Have both the epub3 and epub2 indexes.
Test on an epub2 based eink.
Test also mobo and azw3 on an eink Kindle. Amazon has more than 90% of ebook market and while upload is epub, the download is mobi, azw3 or KFX. Maybe 1/2 of ebooks (Amazon app included) are read on phones.

Almost everything "works" in desktop viewers, but they are not typical.

[Tex2002ans]

Originally Posted by Paolo Carnovalin

The best readability of the book is achieved in 'vertical scrolling' mode. But I ask you: is it a common feature for all ereaders to be able to set reading in vertical scrolling mode?

No. The main reading method of ebooks is "pagination", similar to a physical book.

It is not like a website, where you have infinite scrolling down.

Like Turtle/Quoth have said, some ebook readers have an option to enable "vertical scrolling", but that's in the extreme minority.

(And all physical readers—like Kindles, Kobos, etc.—do not have vertical scroll.)

Originally Posted by Paolo Carnovalin

I am creating an ebook (reflowable epub3) that contains many tables of different sizes.

Can you give examples of the tables?

Originally Posted by Turtle91

There have been a couple discussions here about tables and proper best-practice formatting (Tex will pop in here in a little bit with the links ).

• 2021: "Formatting tables best practices"
• 2021: "Tables in ePub"
• 2019: "Tables: what is the best way to render them on ebooks?"

Originally Posted by Turtle91

Generally speaking, 2 - 3 columns max is acceptable for text that really needs to be in a table; [...]

Yes, that's about right.

Remember, in ebooks, people can read with HUGE FONTS and on very tiny screens (cellphones).

So, what can fit on a huge 7"x10" page in a physical book, cannot physically be squished down into a cellphone-sized screen.

You'd then have to reformat or Transpose/Verticalize your information, like the example I gave in 2021:

Originally Posted by Tex2002ans

Transposing/Verticalization, where you flip the X- + Y-axis, can also be used. For example:

6x3

Name    Color  Cool?  Number  Tabs  # Teas
Tex     Red    Very        1    15      30
Turtle  Gray   Meh         2    99       5

3x6

Name    Tex   Turtle
Color   Red   Gray
Cool?   Very  Meh
Number     1    2
Tabs      15   99
# Teas    30    5

You may want to do this in your ebooks if you get to ~4-5+ columns, depending on the data.

Originally Posted by Turtle91

try and display the text in an alternate (reflowable friendly) format if possible.

Yes. In some cases, you may have to split your big tables/data into pieces.

Originally Posted by Turtle91

If the table must be larger than that, then it's better to embed an image of the table.

I strongly recommend against images-of-tables. It's a mess. See the previous discussion in those links above for more detailed information.

Try to HTML-ize your tables as much as possible.

Originally Posted by Turtle91

BEWARE: Audio listeners will lose the information presented if you do this.

Yes. Text-to-Speech is very important, so try your best to do your HTML tables as good as possible.

[Paolo Carnovalin]

Thank you Turtle91!

... but I would not design a commercial book expecting their device/app to do that.

Of course! actually I am trying to dissuade my customer from making the eBook version of this material that is already distributed in print and pdf copy.
I try to submit all the negative aspects, which are many undoubtedly. The strongest of these is definitely the presence of very wide and long tables. It is impossible to 'tame' their display.
I prefer not to consider to embed an image of the table, (also) to meet the accessibility criteria that will soon become mandatory for validating ePub3 books.

[Paolo Carnovalin]

Originally Posted by Quoth

Assume
1) No vertical scrolling
2) Many epub3 features won't work.
Have both the epub3 and epub2 indexes.
Test on an epub2 based eink.
Test also mobo and azw3 on an eink Kindle. Amazon has more than 90% of ebook market and while upload is epub, the download is mobi, azw3 or KFX. Maybe 1/2 of ebooks (Amazon app included) are read on phones.

Almost everything "works" in desktop viewers, but they are not typical.

Thank you Quoth!!!

[Paolo Carnovalin]

Can you give examples of the tables?

My problem was not formatting the code, but explaining to my client that when inserting such a large element into an ePub you can never be sure how this element will be seen by the person reading the book. The only possible loophole is the use of vertical scrolling, which allows the tables not to be truncated; with my question I was trying to understand if this possibility was also a "universal" loophole

[Tex2002ans]

Originally Posted by Paolo Carnovalin

My problem was not formatting the code, but explaining to my client that when inserting such a large element into an ePub you can never be sure how this element will be seen by the person reading the book.

Yes, but if you show an example of one of these large, multi-screen tables, perhaps more specific advice can be given.

Originally Posted by Paolo Carnovalin

The only possible loophole is the use of vertical scrolling, which allows the tables not to be truncated; [...]

Off the top of my head, I can't think of many (any?) tables that would make sense in a single page, but wouldn't if split across pages.

What can happen though... is accidentally missing your <thead> + <th>. Those two let headers duplicate across screens, helping make the multi-page table be more readable.

Without <thead> + <th>:

Position    FirstName  LastName
1
2
3
4
[...page break...]
5
6
7
8
[...page break...]
9
10

vs. With <thead> + <th>:

Position    FirstName  LastName
1
2
3
4
[...page break...]
Position    FirstName  LastName
6
7
8
[...page break...]
Position    FirstName  LastName
9
10

The 1st type, you might get lost and forget which column is which.

The 2nd type, the column headers follow you across pages.

- - -

Side Note: And if the table doesn't make sense, then I strongly recommend reading the advice/book I recommended in 2021.

What most likely happened is the original author designed a "table-like graphic".

For more "table design" best practices info, also see some of my comments from a few months ago:

• /r/LibreOffice: "Remove gaps between Borders"
• /r/LibreOffice: "Automatic page number in header forced highlight?"

If you squash this problem at the source—and teach them better and clearer ways of representing the original data—you can also help all their future documents as well. (And the readers will thank you too!)

[Hitch]

Originally Posted by Paolo Carnovalin

My problem was not formatting the code, but explaining to my client that when inserting such a large element into an ePub you can never be sure how this element will be seen by the person reading the book. The only possible loophole is the use of vertical scrolling, which allows the tables not to be truncated; with my question I was trying to understand if this possibility was also a "universal" loophole

For what it's worth: for our customers with larger tables, assuming they cann pay for it, of couorse--we put in BOTH. We put in a section at the bck of the book with "HTML tables," which each table in HTML format, so that the text is readable for accessibility and all that, and searchable and an imaged version, in the body of the eBook. We put a link, below the imaged version ("For HTML version, click here" and a link back at the HTML table).

This works quite well. YES, it's extra work and yes, it's extra $$ for the customer, but...most customers with huge tables seem to have the budget or the willingness to go that extra mile.

Hitch