MobileRead Forums - View Single Post - Google Play Books and Nested Lists

Quoth · 08-23-2021, 01:41 PM

Re: Epub 2.1 Spec.

I started programming with Z80 Assembler, Pascal, Occam, Forth, Modula-2 and then learned C++ BEFORE C in 1987. Then in 1988 I was introduced to the funky world of C on DOS and in late 1990s on Linux. It turns out that C originally had ambiguities and also not everyone implemented everything and not always the same way. Also there are C libraries best avoided.

Similarly real use of Word and Excel isn't a competition to use all the features. You are best with a subset that gets your job done and works on the most versions of MS Office (Used to be Office 4.3 & '95 then it was all from '97, then all from XP=2002 and later).

So I'd only be especially interested in the epub 2.1 spec if I was writing a program to render epub 2.1 files. Otherwise perhaps it whatever works on all epub dedicated ereaders (likely Adobe renderer) and seems similar on KF8 devices either converted by Amazon or Calibre. The most basic layout ought to be the same on mobi-kF7. It has to be AUTOMATIC from "odt" -> Save As "docx" and Convert to epub in Calibre without ANY editing of CSS or HTML afterwards. So not everything possible in Word or LO Styles makes sense. We do NOT try to replicate print books ever, but have a pleasant easy-to-read layout with enough but not too much whitespace.

It's best to use a clear and readible subset of HTML and CSS automatically generated from your Wordproccessor file input.

Then we edit a copy of that for paper with page styles for front matter, contents, body, appendix, rear matter etc. Maybe different body font and header spacings. We'll try then to replicate conventions of paper publishing (such as fractional spaces, headers, footers etc). I think Amazon's current idea that you can upload one file for ebook and paperback is bonkers.

We'd also only use InDesign if doing textbooks, magazines, newspapers and manuals. A crazy tool for fiction / novel paper publishing and even worse for ebooks.

08-23-2021, 01:41 PM	#50
Quoth Still reading Posts: 14,488 Karma: 107078855 Join Date: Jun 2017 Location: Ireland Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper	Re: Epub 2.1 Spec. I started programming with Z80 Assembler, Pascal, Occam, Forth, Modula-2 and then learned C++ BEFORE C in 1987. Then in 1988 I was introduced to the funky world of C on DOS and in late 1990s on Linux. It turns out that C originally had ambiguities and also not everyone implemented everything and not always the same way. Also there are C libraries best avoided. Similarly real use of Word and Excel isn't a competition to use all the features. You are best with a subset that gets your job done and works on the most versions of MS Office (Used to be Office 4.3 & '95 then it was all from '97, then all from XP=2002 and later). So I'd only be especially interested in the epub 2.1 spec if I was writing a program to render epub 2.1 files. Otherwise perhaps it whatever works on all epub dedicated ereaders (likely Adobe renderer) and seems similar on KF8 devices either converted by Amazon or Calibre. The most basic layout ought to be the same on mobi-kF7. It has to be AUTOMATIC from "odt" -> Save As "docx" and Convert to epub in Calibre without ANY editing of CSS or HTML afterwards. So not everything possible in Word or LO Styles makes sense. We do NOT try to replicate print books ever, but have a pleasant easy-to-read layout with enough but not too much whitespace. It's best to use a clear and readible subset of HTML and CSS automatically generated from your Wordproccessor file input. Then we edit a copy of that for paper with page styles for front matter, contents, body, appendix, rear matter etc. Maybe different body font and header spacings. We'll try then to replicate conventions of paper publishing (such as fractional spaces, headers, footers etc). I think Amazon's current idea that you can upload one file for ebook and paperback is bonkers. We'd also only use InDesign if doing textbooks, magazines, newspapers and manuals. A crazy tool for fiction / novel paper publishing and even worse for ebooks.