[Tex2002ans]

Originally Posted by JSWolf

The SVG table in the SVG wrapper did work as expected, but because it fit the entire table on screen at once, it was too small to read.

Indeed, this goes back to my first post where I mentioned it is just physically "impossible" for a very large table to fit on a very small device. The text just becomes impossibly small to read.

And while you would HOPE that your readers would choose a more suitable device for non-fiction, technical works (tablets, PCs, etc. etc.), you can't guarantee that...

Potential pro for bitmap image: Now, depending on your device, SOME of them allow you to click on a JPG/GIF/PNG, and get a full-scale version of the image, which you can then scroll around. This might be a case where a large table might MIGHT beat out a comparable SVG. I do not believe these devices can allow you to do the same thing via SVG (expand + scroll).

Pro for SVG: On devices that do not have such capabilities, the legibility of the text in the SVG image would DESTROY the shrunken JPG/GIF/PNG (image resizing algorithms on typically do HORRENDOUSLY on text).

Originally Posted by JSWolf

The HTML table was good to read until I increased the font size to be too large to fit width wise without going past the edge of the window. But if the font size was not too large, it displayed best because it was more readable and the rows that didn't fit dropped to the next page (and so on).

Yep, that specific Split Table broke the ol' "4-column rule" (it was 5 columns). This is something where you have to logically break up the tables on a case-by-case basis depending on what data is inside, while still maintaining comprehension.

For that specific table, there was the "Weights" spanning 4 columns + the "Portfolio Number"... it would be QUITE odd having Portfolio Number + 3 of the 4 "Weight"s. And then the 2nd Table with "Portofolio Number" + 1 "Weight" + the rest of the data.

This again goes back to the pro/con balancing scale... Coming up with the best way to transfer a table to be readable on a smaller device.... sometimes it is just not possible to logically split the data while maintaining comprehension.

Side Note: And here we come back to the balancing scale. Most just settle on making a bitmap image of the table, and screw the disadvantages, it works "good enough" It takes about two seconds to generate an image (and IS compatible with nearly every device).... but it takes a lot more hard work trying to make books more accessible/user/reader friendly!

Originally Posted by JSWolf

The font size did not change with the SVG table in the SVG wrapper. I could change the font size with the HTML table.

Also, you have to keep in mind the other advantages of the HTML table. For example, I would say THIS:



is better than this:



(Notice the SVG text is specified as black... Black on black, no good!).

and here is a screenshot of the 96dpi image of the table:



This is an example of the disadvantage of going the image route... while it looks fine on white background + black text, it begins to fall apart when the user decides to use anything else as their background colors.

And sure, sure, the HTML table I made isn't as pretty... but it follows user preferences. The HTML table can change font size/color, and scale to quite a large font size on the same size screen (comparable to the image/SVG).

Also, your book will become much more accessible to a person with poor eyesight (this is one of the FANTASTIC advantages of ebooks compared to their (crappy) physical counterparts!).

Originally Posted by JSWolf

Given that you don;t know the font size nor the screen size, the HTML table is a better option. Especially when reading on a cell phone screen such as an iPhone. As for a 6" eInk screen, I would say again, the HTML table is better. given how many rows are in the SVG table, it would come out smaller and harder for to read. The HTML table as long as the font size is not too large to go off the side of the screen, it's the winner.

You could also do something like split your really large tables into smaller SVG files. Maybe 15/20 rows each. This would allow the entire SVG to expand slightly larger, potentially giving slightly bigger text.