View Single Post
Old 10-28-2016, 10:10 PM   #9
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 2,625
Karma: 3120635
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
Thanks for your useful explanations.

This example shows that, sometimes, the gumbo parser is more royalist than the King (Epubcheck). The main point is that it's right and sound. Maybe it deserves better than the stern warning Sigil issues before using it if you select the option to mend on opening: it says roughtly "Sigil can correct automatically your html but you can lose data in the process", which always put me off up to now.

I did a second try from the same odt file. I asked ODTImport to produce an EPUB3 without asking Sigil to mend anything. This time, nearly everything was correct for the table, including colgroup and tbody tags. Mystery...

Two small things about this EPUB3:
1- One that can be easily corrected using Sigil is changing the extension name of all the files (from html(5) to xhtml) to please Epubcheck. (the gumbo parser is undisturbed about this trifle).

2- Epubcheck signalls also an error about a deprecated (for EPUB3 only) "cellspacing" attribute on this table, which does not disturb the gumbo parser. It's also easy to take out this attribute though maybe not for a beginner. (I use a saved regex to weed it out).

Last edited by roger64; 10-28-2016 at 10:29 PM.
roger64 is offline   Reply With Quote