View Single Post
Old 12-02-2023, 06:51 AM   #11
Quoth
the rook, bossing Never.
Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.Quoth ought to be getting tired of karma fortunes by now.
 
Quoth's Avatar
 
Posts: 11,456
Karma: 87454321
Join Date: Jun 2017
Location: Ireland
Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper11
Quote:
Originally Posted by DNSB View Post
I won't get into fixed layout ePub3 ebooks. PDF without the widespread support.
That reminds me about epub2 and epub3 differences.

There are two basic approaches to epub2

1. Simple and mostly automatic from well crafted MS Word or LO Writer docx file using paragraph styles properly. No attempt to exactly duplicate an existing paper edition. Larger images are each in own paragraph. Some smaller ones can be on the same line in a paragraph. There are no media queries, no SMALL CAPS, no drop caps, no floating images with flowing text, no tables (or only short ones the two columns that work on small screens and big fonts). No fractional spaces, no maths (other than regular text or an image). No transparency, no background images. No line-height settings (automatic from font metrics and user adjustable). No added soft hyphens as the user's renderer will do them (or not). Don't use List format, mimic it with a style and hand number because most ebook renderers can only start at 1, and be sequential. Bullets may need a special font user doesn't enable.

The only hand crafted epub edit being image CSS were a percent of screen width or height is needed. Calibre import of the docx and conversion.

This will convert perfectly to azw3/KF7 or KFX by Amazon's KDP.

Only a subset will work for old Mobi (really four models of Kindle, though a few others need FW updates for azw3) which will soon be gone due to battery failure. Mobi only supports inline styles and HTML3 and three Western Latin/Roman font-faces (Sans, Serif and Monospace each with normal, bold, italic or bold-italic). Some modern Greek letters supported. No Asian, Cyrllic, Hebrew, Arabic, or R to L.

Some apps don't respect the CSS so layout with them is poor. Some old ereaders need the epub put into the "Digital Editions" folder and then the CSS is respected!

If an Android or iOS app respects CSS, then it will look similar to any Nook, Sony, Kobo (using epub, not kepub), Binatone, iRiver etc. The azw3 on a Kindle will look very similar. The Kindle KFX and Kobo kepub versions delivered by the Amazon & Kobo stores will render a bit differently. Some people prefer it and others prefer the ADE style rendering. If the ebook uses a font not on the ereader a fall back is used. If the publisher embedded fonts the user (Kindle or Kobo) has to select a "Publisher" mode. You can't make the user do this.

Mobi doesn't have embedded fonts. However it looks far better than ebooks using either pdb format on Palm OS, Symbian or Windows CE. Terribly ancient Sony ereaders use LRF which strangely obliques the font instead of having an italic version. My theory is that Pocketbook physical ereaders having all the old formats as a gimmick and anyone needing them either uses Calibre (it does both sorts of pdb, LRF, old mobi etc) or gave up the old format maybe 10 to 15 years ago!

2. Hand crafted in Sigil, Jutoh, calibre or produced by a Desk Top Publishing system (InDesign or others) and being really clever.
Deliberate flowing of text around floated images, media queries, fractional spaces, SMALL CAPS, drop caps and more. Attempt to exactly mimic a paper layout. Perhaps (InDesign) having done the PDF first (better to workflow other way round). Treating ebook creation as if leading edge HTML5 + CSS3 web page design.
It will "break" in many ereaders. Actual apps using a web browser to render will be fine! Conversion to azw3, KFX & mobi by Amazon KDP may break entirely or need a lot of Amazon media queries.

It will look wonderful on your favourite app, not so great or "broken" on many actual eink ereaders. It's the content that matters for fiction, not glitzy layout. Text books etc a bigger issue, but they have a problem on ebooks anyway.

You can't insist on people using a particular App.



The delights of epub3


This is going to annoy some epub3 evangelists, but it's factual apart from the opinion of "what is an ebook?".

EPUB is a technical standard published by the International Digital Publishing Forum (IDPF). It became an official standard of the IDPF in September 2007, superseding the older Open eBook (OEB) standard.
It's epub2 because the previous version was started in 1998 by one company and open sourced as OEPBS.
https://en.wikipedia.org/wiki/Open_eBook

Epub2 was effectively in use before Amazon launched the Kindle in 2007 with already obsolete by 5 years mobi (they bought Mobipocket in 2005, the year Sony released the first ever eink ereader using LRF, but ereaders are from maybe late 1980s using monoLCD. I designed one in 1989 called the Notepad. It had a Pen! See 1991 Discman https://en.wikipedia.org/wiki/Data_Discman).

Unfortunately in May 2016 International Digital Publishing Forum (IDPF) members approved World Wide Web Consortium (W3C) merger, "to fully align the publishing industry and core Web technology". Obviously IDPF was "into" W3C (dominated by Google/Alphabet) before 2016.

However an ebook is simply a reflowable version of a paper book to suit any size screen and size of user selected font, line spacing and margins. It's also paginated on the fly. It's simply that HTML and CSS in a zip file was a handy way to implement it. Amazon KFX, with 90% + of English speaking market doesn't work like that.

A Web "page" is like a scroll usually. It's not just for reading what you could read on paper but delivers video, games, interaction etc. It's only paginated for printing to paper. Content is often dynamic from several sources and databases. It won't exist as a file.

The first epub3 spec was approved in 2011. That's TWELVE years ago. (cf issued of IP4 and IP6 on networking).

There really ought to be three epub3 specs:
1) epub3E for ebooks.
2) epub3M for multimedia and interactive.
3) epub3P for Print Replica, a duplication of PDFs. Amazon has two forrmats for this, the PDF encapsulated as a Kindle file and KFX fixed layout (also used when PDFs go via "Send To Kindle" for Kindle Scribe).

1. epub3 for ebooks
This adds more semantic HTML used on websites, but not in epub2, such as section instead of a div with class, or figure instead a p with a class. It also add MathML, making scientific & text books far better. It has a new System Table of Contents, but you can add the epub2 one also. Oddly doesn't seem to add client side image maps where you click on a region of an image and go to anchor. Maybe I'm wrong. This is ancient on websites and needs no programming or javascript.
Some physical ereaders support some of this, especially kepub format on Kobo.

2. epub3 for Interactive multimedia
Let's make it be JUST like a web page, but paginated. So Javascript, transparency, layers, audio, video. Yes, there are some apps that support this. It's not really a book but an App done like a website using epub3 as the framework. The user has to find a compatible iOS or Android app (it won't work sensibly even on an Android based eink ereader that has audio, colour or mono). Well, it's better than using Adobe Flash?
There is a steep learning curve writing iOS and Android apps, but there are free frameworks and you don't have to use the 3D animation features. The less like an ebook and the more like a Flash Game or Multimedia feature your epub3 is, the likelihood is that doing it as an app in Apple Store, Fire Store and playstore will work better. The user then doesn't have to install the epub3 app needed. Yes, this is part opinion, but I've done an Android app, PC game engine from scratch for DOS, Multimedia titles for PC etc, Flash games and interactive websites (server side Java, Cold Fusion, Stored Procedures with client side Javascript) . I can't see the point of epub3 for this.
Most non-game Interactive and Multimedia content has gone from PC/MAC CD/DVD applications to iOS and Android applications or Web sites.
Many free / trivial /casual games are on Android/iOS. The largest catalogue of paid games including ported old ones is now on the Nintendo Switch. The main barrier to game production is no longer clever programming but the artwork, video & audio. You still need the that for an epub3 interactive/multimedia title. After Nintendo, Xbox & Playstation the PC/Mac games are a niche and the iOS/Android cheaper or free more casual games. Though a 99c Solitaire on the Switch is much better than a free Android one.
It's also confusing to users to sell an interactive/multimedia title as a book (assuming that it can be sold on any online bookstore other than Google's <1% sales Playbooks. I can't see how it can work on Amazon).


3. epub3 for Print Replica, a duplication of PDFs.

PDFs are universal. Mysteriously even the 160 x 160 pixel Palm models had a PDF reader. They are not ebooks, but electronic representation of a paper book, more so than an MS Word or LO Writer document. Certain features to use them as electronic forms online are a mistake compared to a webpage.

Amazon has their own versions of PDF for DRM (one is essentially a PDF with Amazon DRM). Long ago Amazon sold ebooks with Adobe DRM. You have to pay Adobe a royalty. DRM on PDFs is hopelessly broken years ago. At the simplest, if you can print, you print it to a PDF printer. Amazon with over 90% of English Language market world wide pays no-one for DRM now. Scribe users are locked into Amazon Fixed layout/Print Replica KFX converted from PDFs. They don't and won't use epub3 unless forced to by law.

Text books, journals and papers have typically been Amazon "Print Replica" or PDFs and consumed on laptops or larger tablets (10" or more). Hardly anyone is using epub3 Print Replica / Fixed layout for retail selling. I can't see that changing.


Finally
Most ereaders that do epub (all except Kindles now) don't state what epub3 features (if any) are supported.

Most apps for iOS or Android tell you less. I've tested many popular Android epub apps and found many hardly support CSS in epub2 at all, or ignore embedded fonts and even ignore installed fonts.

KISS!
Keep It Simple Stupid!
Epub2 is a subset of web HTML and CSS. Not everything works on everything. If it's fiction or proofed OCR of PD, don't try and replicate fancy print books or nuances of a particular Style Guide. Do up a simple style guide. Things like drop caps and small caps and text flowing around images do look pretty, but they break and even if perfect reduce reading immersion / ability for many people.

I'll not argue about the value of semantic markup on basic epub3. That's a separate discussion and certainly can be good for screen readers. It should have no visual difference compared to epub2.

Last edited by Quoth; 12-02-2023 at 07:01 AM.
Quoth is offline   Reply With Quote