Tables in an epub?

[Section8]

Folks,
I am in the middle of converting a pdf to an epub. The source includes several large tables (example .jpeg attached).

Currently, I'm just generating them as jpegs, but have been considering converting them to <table>s in the html. My strong intuition is that a table this wide in html isn't going to render in a sane way on any current ereader, and this isn't worth pursuing.

Are jpegs the best way to go with tables like this?

[mrmikel]

Almost always unless you can be sure they will be displayed on a large tablet. Even then somebody can increase the font size and blow up the table.

You might want to experiment with different types of images, gif, png, etc to see what gives you the best image for the least memory consumption. Probably not too big a deal if there are only a few of them.

HTML tables can be hard to center as well, without messing up the formatting inside the table.

Images are pretty easy to snapshot out of the pdf. Just make sure your viewer program snapshot is set to as good a resolution as you need.

[Section8]

Thanks. There are 4 of them. I'm probably going to just stick with jpegs.

[RbnJrg]

Originally Posted by Section8

Thanks. There are 4 of them. I'm probably going to just stick with jpegs.

Use .gif images; they are better to display tables and similars.

[Tex2002ans]

Originally Posted by Section8

Currently, I'm just generating them as jpegs, but have been considering converting them to <table>s in the html. My strong intuition is that a table this wide in html isn't going to render in a sane way on any current ereader, and this isn't worth pursuing.

• Is this for personal usage?
  • If it is for personal usage, you can do whatever you want.
• Is this aimed towards any specific devices?
  • Tablets/large devices you can be more lenient
  • If this is aimed towards ADE, you might have to work around ADE bugs, if it is aimed for only iBooks... etc. etc.
• Is this being sold at Amazon/B&N/other stores?
• Is this being sold from your personal site/store?
  • From your personal store, you can be more lenient.
• Is this EPUB aimed towards copy/pastability?
  • Let us say someone wants to reference this table. You just made their life a million times easier if they can just copy it right out of the EPUB, instead of having to manually recreate it.
  • Let us say there was an actual error in the original book. A fix in HTML is WAY easier than a fix in an image.
• Is this conversion aimed for a more ultimate goal? (HTML put on a website, looking towards future formats).

Also, if there are LOTS of images in the book, just keep in mind that all those images really start to add up in filesize. The equivalent HTML table will be MUCH smaller (and compress much better).

Depending on the design of the table, you may also want to swap the x and y axis to make it more "vertical" oriented, OR split the table into multiple tables.

The quickest way I have found to swapping (Transposing) an HTML table is getting all the information into a spreadsheet program (in my case, I use LibreOffice Calc), and following these steps:

https://help.libreoffice.org/Calc/Ro...es_Transposing

Then I can easily export as XHTML and do some quick cleanup.

Originally Posted by Section8

Are jpegs the best way to go with tables like this?

No JPG! PNG in this case! I have an explanation/examples here (and a link to the program that I use to compress PNGs (ScriptPNG)):

https://www.mobileread.com/forums/sho...5&postcount=26

This is a pet peeve of mine.... lossless formats should be used when dealing with "artificial" images.

Originally Posted by mrmikel

Almost always unless you can be sure they will be displayed on a large tablet. Even then somebody can increase the font size and blow up the table.

Well at a certain point, all but the most very basic design decisions will be exploded due to extremely large font sizes. IF the reader has poor eyesight (or prefers reading in a certain font/size), an image of a table with very tiny font won't do any better.

Also, keep in mind readers who are blind. Images of tables are completely useless to them.

I prefer to have actual HTML images in the books, so that they scale with the rest of the text, and go along with all the other user preferences.

Originally Posted by mrmikel

You might want to experiment with different types of images, gif, png, etc to see what gives you the best image for the least memory consumption. Probably not too big a deal if there are only a few of them.

It is a HUGE deal! Down with JPG!!! Down with GIF too!

The equivalent PNG will ALWAYS be smaller than GIF (PNG has less overhead).

Originally Posted by mrmikel

Images are pretty easy to snapshot out of the pdf. Just make sure your viewer program snapshot is set to as good a resolution as you need.

Yes, and remember that high resolution images can always be scaled DOWN, but low resolution images cannot be scaled UP (without looking like complete garbage).

Another thing that irks me about images of tables is when they take a tiny thumbnail image of a table that is COMPLETELY unreadable.

Here is an example of a table I "verticalized" + some more JPG-PNG examples.

Original Page from the PDF:



Here is an image of my "verticalized" HTML table in Sigil:



JPG (Grayscale 90 + 80 quality):



The filesize is 82.8 KB and 65.6 KB. The artifacting in the image will only get worse from there if you want to try to aim for a "reasonable" filesize.

PNG (Grayscale PNG saved right from GIMP + Compressed with ScriptPNG):



The filesize is 37.8 KB and 31.3 KB. These images have ZERO artifacting, and are less than half the size of those JPGs.

In the future, let us say an even better lossless filetype comes out, or an even better compression algorithm. These images can also be made even smaller with ZERO loss.

Here is the PDF:

http://library.mises.org/books/Willi...20Currency.pdf

and I have attached the actual WIP EPUB if you want to take a look.

[RbnJrg]

Originally Posted by Tex2002ans

It is a HUGE deal! Down with JPG!!! Down with GIF too!

I'm not agree with you; .gif images is -maybe- the best option. Of course, .jpg images is the worse election.

[Section8]

Tex2002ans,
Thanks for all the info. The pdf I am converted was downloaded from http://cybertracker.org. It was released under a creative commons license and I am converting it mainly for my own use, but might upload it to the MobileRead library.

In the original pdf, I think these tables are images (not searchable or selectable as text). After some googling around, I was able to use this service: http://www.extractpdf.com to extract all of the images. These tables and several diagrams came back as .pngs, and the photgraphs are jpegs. In all, 32 images & about 2.8 Mb total. I am going just use these pngs for the tables, after trying to shrink them with the tools you recommended

[Tex2002ans]

Originally Posted by RbnJrg

I'm not agree with you; .gif images is -maybe- the best option. Of course, .jpg images is the worse election.

I just want to stress again... avoid JPG for artificial images (tables/charts/graphs)!!!

GIF is good, but PNG is great!

There are only 2.5 areas where GIF has an advantage over PNG:

• Animation
  • Not relevant in ebooks
• Very small icons with no transparency
• (.5) Works in ancient browsers. (GIF was created in 1987, PNG in 1996)
  • There are potentially some very old ereaders that can't handle PNG
  • PNG is a part of the EPUB spec though, so these devices are most likely pre-EPUB.

https://en.wikipedia.org/wiki/Portab...ompared_to_GIF

For some lively discussion about the topic: http://stackoverflow.com/questions/1...ges-gif-or-png

There is only one bug that you have to keep in mind with PNG images (only applicable to Kindles): Kindlegen cannot handle transparency in PNGs (converts transparency to a black background).

I have not stumbled upon one case of an artificial image (table, chart, diagram, figure) where GIF was better than PNG. PNG can handle every case where a GIF can be used, PLUS more.

Originally Posted by Section8

Thanks for all the info. The pdf I am converted was downloaded from http://cybertracker.org. It was released under a creative commons license and I am converting it mainly for my own use, but might upload it to the MobileRead library.

Fantastic!!!

The company that I work for, everything is CC3.0 (or public domain).

Most of my EPUB work is done OCRing PDFs of older book scans (Black & White), but I also help convert newer publications as well (so I deal with color charts/graphs/diagrams... and if I am lucky, I get the actual vector source (Those nice charts I had in my ScriptPNG post were generated from the vector files) ).

Originally Posted by Section8

In the original pdf, I think these tables are images (not searchable or selectable as text).

Well, when I run across these, I OCR them and convert them to their HTML equivalents (for the advantages stated above). It takes a nice chunk of time, but I see it as: I spend the time to convert it to HTML ONCE, and it will never have to be converted again.

I mean.. why would you want to lower the quality of your EPUB version because of someone making a bad decision when they exported the PDF? (exporting tables/charts/graphs as non-vector formats).

If the author is still alive, and this PDF was created recently (within the last few decades)... perhaps try to get in contact with the author himself. Perhaps he still has the source files sitting around, and you can generate higher quality tables!

Originally Posted by Section8

These tables and several diagrams came back as .pngs, and the photgraphs are jpegs.

Great great. Although sometimes you have to watch out, sometimes these PNGs went through a lossy conversion somewhere along the line. Once you go lossy, you can never go back!

Here is a real life example of the horrible conversion/JPG artifacting you might run into (and the HUGE filesize of JPG compared to PNG):

Original image was done by the author, and was probably generated by some sort of crappy PDF -> image conversion (800+ KB JPG). Artifacting left and right, and that filesize should make you gasp!!



I got the source document from the author, and was able to generate a PNG (42.9 KB)):



I must admit, it was a "lossy" PNG conversion since I Indexed it to 4 gray colors.

Grayscale JPG (90 quality) (257 KB):



Grayscale JPG (80 quality) (203 KB):



Artifacts between PNG + 90 JPG + 80 JPG:



As you can see, the "halo"ing gets worse and worse the lower quality you go with JPG.

A GIF would look exactly like the PNG version (no haloing artifacts), BUT the GIF will have a larger filesize.

Anyway, this entire topic reminded me of this book with a very large Appendix FULL of tables. One of these days, I will go back and "verticalize" them.

PDF Scan:


EPUB with Images of Tables:


EPUB with HTML Tables:


The HTML table also has the advantage of footnotes being linked back/forth.

I can attach both versions of the EPUBs if anyone is interested.

EPUB with images: 1.41 MB
EPUB with HTML: 611 KB

Side Note: PDF is just about the WORST format to work backwards from.

[Jellby]

Originally Posted by Tex2002ans

GIF is good, but PNG is great!

GIF is only okay-ish: No real alpha channel, only 256 colors. The later is not much relevant for grayscale images, but the former can make a difference when the page color is not white (or whatever background color the GIF was designed for).

There are only 2.5 areas where GIF has an advantage over PNG:

• Animation
  • Not relevant in ebooks
• Very small icons with no transparency
• (.5) Works in ancient browsers. (GIF was created in 1987, PNG in 1996)
  • There are potentially some very old ereaders that can't handle PNG
  • PNG is a part of the EPUB spec though, so these devices are most likely pre-EPUB.

GIF is also part of the ePub spec. You didn't say the opposite, but it may be worth mentioning.

The only advantage I see in GIF is that it is supported by the old Mobipocket format, whereas PNG is not... but if you are converting from ePub to Mobipocket, the converter will convert from PNG to GIF too.

[dwig]

Originally Posted by Jellby

...
The only advantage I see in GIF is that it is supported by the old Mobipocket format, whereas PNG is not... but if you are converting from ePub to Mobipocket, the converter will convert from PNG to GIF too.

... that or it will convert the PNG to a JPEG.

One BIG CAUTION with PNG. It is an extremely plastic format that has many many variants and options, many of which are poorly supported by a large number of apps. It also supports custom ancillary data. This later ability can result in massive PNGs depending on the tool used to create them and the save/export method and options chosen.

If you know your conversion tool's options and choose wisely, PNG can be an excellent option. It's not a magic format and the conversion tools won't automagically create the best flavor of PNG for your use. When using a tool like Adobe (nee Macromedia) Fireworks which uses PNG as its native format and using its "Save..." option yields a very poor PNG for use in ePubs or for direct web use. Always use and "Export ..." functions and choose the flavor of PNG (lossy compressed, lossless, 24bit RGB color, CMYK color, indexed color, ...) that is appropriate for the particular image and its use.

[Freeshadow]

If you want maximally optimised PNGs, the 1st step would be to run them trough Ken Silverman's PNGOUT http://advsys.net/ken/utils.htm

Then recompress them using the newest DEFLATE implementation: Zopfli. Use advancepng available in this package: http://advancemame.sourceforge.net/comp-download.html choose maximal compression level to use the Zopfli algorithm and set the i parameter to 1000.

SVGs can be recompressed with advzip using the same parameters because they are zipped XML containers.

[eping]

Originally Posted by mrmikel

Almost always unless you can be sure they will be displayed on a large tablet. Even then somebody can increase the font size and blow up the table.

Readers (or apps) should be improved, table appearance should be maintained(font size inside table should not be changed as text size)

On small screen, table and image should be allowed to zoom and move like on iBooks. (Kindle 3 already implemented.)

So that we need not use this lagging method of converting tables into images.

Even table can not be rendered correctly, how can we think ePub can be accepted widely?

Adobe, IDPF, you should do better!

[Leonatus]

Originally Posted by eping

Even table can not be rendered correctly, how can we think ePub can be accepted widely?

Tables in epubs use to cause crashes on my device. I have to remove them by saving the text in Open Office Writer and applying the "table to text" feature. Manually, in order to maintain the other formattings. Then create an epub with writer2pub and do final cleaning up with Sigil.

That's lamentable, because ceators of ebooks put so much energy in formatting tables to achieve certain text features, but it's completely useless to me.

Whenever possible, keep it flat!