Does Sigil need an epub e-reader component?

KevinH · 09-01-2019, 12:03 PM

Does Sigil need its own e-reader component for reading/final layout checks?

Given Sigil and PageEdit both use QtWebengine (Chrome based) and the existence of projects like Readium Cloud Reader and futurepresses epub.js and epub.js-reader, I think it would be relatively painless to combine QtWebEngine with these pure javascript solutions to create a standalone desktop epub3 compliant e-reader with pagination, dual page spreads, and etc specifically for Desktop Windows, MacOS, and Linux.

Would this be of any value to Sigil epub devs? Or would it create just one more reading system to worry about?

I ask because both Readium and futurepress approaches work well with current browsers if local file restrictions and cross-site scripting restrictions are lifted. These restrictions are something we control in QtWebEngine.

And Chrome's removing/restricting extensions means that Chrome based versions of Readium via extensions may be an issue in the future.

In addition, if we build the app ourselves to work with local files, we can be assured that no geo, or tracking data is ever used or even generated.

I am personally getting quite tired of how much Mac Desktop app store code includes tracking modules (which they claim is specifically meant for program improvements). Many open source projects are being repackaged with tracking libraries in these app store versions. They are supposed to be safe according to the app store but I simply do not trust them in any way.

General thoughts? Useful or simply wasteful duplication?

KevinH

theducks · 09-01-2019, 12:31 PM

I've always wished for a more (selectable) device accurate emulation (plugin, so the main Dev's are not burdened) in the preview.

Having a forgiving

, WEB render does not help avoid device (EPUBx) limitations without resorting to saving and loading into the Target Device (viewer).
I am

that improving has become the mantra for incessant tracking. So go for any solution that thwarts the Big Brother mentality of industry.

JSWolf · 09-01-2019, 01:28 PM

Would this reader be strict and not so forgiving so we see how things actually look and not the way they look when the reading softare is forgiving? If it's going to be strict, then I'm all for it.

Turtle91 · 09-01-2019, 01:30 PM

+1 for the (selectable) device accurate emulation.

I'm not sure a standalone reader would do much more than can be done with PageEdit??? However, would a standalone ereader be easily portable as an iOS/android app?
My use would be to make basic corrections (spelling, punctuation, etc) as I'm proofreading on my phone. Or, at least mark the errors on the device, and import the error list back to sigil.

KevinH · 09-01-2019, 02:42 PM

FYI: Being able to emulate older (broken?) e-readers would simply be too hard to do. The bugs and omissions can be processor, model, and of course e-reader firmware specific.

The future of all reading apps (and according to google, most future apps of any kind on many platforms) is really browser engine based SDKs on both Desktops and of mobile devises.

The problem is the competing browser engines out there still leave open variation in e-readers.

Firefox/Mozilla has their own engine. On mobile, Apple forces the developer to use its Webkit based Safari engine (forces all browser and web apps to use it), and therefore, of course, Apple prohibits use of Chrome's WebEngine variant for mobile.

So no QtWebEngine based e-reader can be used for iOS. So Firefox, Opera, Chrome, etc on iOS is really being done on Webkit.

And it looks like future epub specs will be html, css, accessibility, json, and browser based if you look at what is being pushed out there as the epub next gen.

So I was less worried about legacy e-readers and more focused on more modern e-readers based on browser engines that can support javascript.

Perhaps there is no need for an opensource Desktop epub3 e-reader without a cloud interface and its associated tracking.

Perhaps just adding the ability for PageEdit in Preview mode to show the epub in a paginated fashion (one page or two page spreads), and a formatted Table of Contents extracted from the nav would be enough.

Doitsu · 09-01-2019, 04:59 PM

Quote:

Originally Posted by KevinH

Perhaps just adding the ability for PageEdit in Preview mode to show the epub in a paginated fashion (one page or two page spreads) [...]

If you decide to implement this feature, it'd be nice if you also added a page number display option for epub3 books with page lists. You could either mimic the Apple Books printed page number display option, or implement one of the three page number display modes available in Azardi (see screenshots; page_num2.png shows the actual location of the page target marker).

This feature would be very helpful, because ADE 4.x still doesn't display page numbers in epub3 books.

KevinH · 09-01-2019, 06:43 PM

In all these cases print layout page numbers are being displayed, correct? What happens when a print page boundary does not happen at a heading or chapter boundary? Where is the page number placed and how is the boundary indicated.

BetterRed · 09-01-2019, 06:55 PM

If you didn't do this, what would you do instead. Spend more time at the beach, go skiing, etc are a valid answers

Speaking for myself, if I wanted something better than Preview/Page Edit, I would use the calibre ebook-viewer. And I'd rather have multi-lingual spell checking, and/or a user defined folder structure than a viewer.

Added: I don't worry too much about tracking, I know the 5-eyes have my number.

BR

KevinH · 09-01-2019, 07:13 PM

FWIW, a user defined folder structure is our next Sigil project (in other words stop moving everything to fit our structure). We will branch to start work on it immediately after the next release.

As for multi-lingual spell checking, that is actually not hard if it is done by a spellcheck modal dialog and not trying to do it while typing. The "do it while typing" is in fact very hard to do as the tag that indicates the language may be far away from the text being checked. The modal dialog spell checker might be a good project for a plugin developer.

Doitsu · 09-02-2019, 01:18 AM

Quote:

Originally Posted by KevinH

In all these cases print layout page numbers are being displayed, correct?

Azardi displays print layout page numbers defined by page target markers (it doesn't appear to use the page list):

Code:

<span epub:type="pagebreak" id="page26" title="26">26</span>

Quote:

Originally Posted by KevinH

What happens when a print page boundary does not happen at a heading or chapter boundary?Where is the page number placed and how is the boundary indicated.

That depends on the page number mode. Since Azardi offers a free macOS version, you might want to download it and test it for yourself. (Azardi is Freeware, but not Open Source.)

You can download the small Public Domain MR epub3 book with page numbers that I used for my tests here.

You could also open the book with the iOS Apple Books app. (You'll need to tap the TOC icon and then tap the Tap to show printed page numbers option at the bottom of the screen.)

I actually like the Apple Books page number display best.

democrite · 09-02-2019, 02:19 AM

I too like best the page number display of Apple Books for iOS. Numbers are shown in the left margin. In cases where there there is a blank page before a new chapter or section, publishers will tend to put that blank page # either at end of that section at the end of the last XHTML element, or sometimes together along with the next page number in the next header. Showing in margins seems like it'd work best overall. When UX controls (back, TOC, search, font/display change, bookmark) are hidden, page number is shown in the footer.

I like the idea of a Sigil standalone reader. Last time I tried them, the majority on macOS were clunky, had a slow UX, the UX was not particularly attractive, and so forth. I use either ADE or the calibre reader; calibre being not particularly feature rich. It would be terrific if a reader had some features such as cache (so re-opening a book was nearly instant) and a control such as sidebar to show search results one could navigate (like most PDF readers). Vertical scroll mode (like Books for iOS) or how PDFs can display on many apps would be nice though perhaps difficult to implement. A particularly nice feature of Apple Books is that it parses the entire book into pages, and thus the scroll bar when scrolling shows an overlay with target page number as well as TOC section. Such is terrific and would be if possible wonderful.

Moderator Notice
Oversize inline image moved to Attachment. Please follow the Forum guidlines

Vroni · 09-02-2019, 02:40 AM

A more restrictive preview would be fine. Unf ortunetly, ADE will die soon, at least the 2.x version on a mac as they are 32 bit which reaches its end of life. AD$ in some kind of v4 is a mess and i really would like to get rid of it.

eschwartz · 09-03-2019, 09:01 PM

Something to keep in mind is that calibre's ebook-viewer is in the middle of drastic changes.

It is being ported to use a single codebase across the desktop viewer and the calibre-server browser based reader.
It is being rewritten from scratch using QtWebEngine, instead of the current QtWebkit viewer.
It is gaining new features like annotations.

The ebook-viewer is generally targeted at being a user-friendly, featureful desktop ereader software, and I guess it should do a fairly good job of showing how a modern, compliant ereader functions.
(I mean... we already acknowledge that just as calibre does not show how some ancient boutique ereader software will render your book, Sigil is not going to either, because implementing device quirks is a fruitless, thankless waste of time.)

Does Sigil need to develop its own competitive ereader as well? Maybe it would make sense to recommend calibre for this (and make sure that it is suitable for such use). calibre has always been more of a go-to for reading and organizing ebooks, while Sigil has always been more of a go-to for editing them. Just because calibre grew an editor doesn't mean Sigil *needs* to grow an ereader.

If Sigil did get an ereader, what additional use would one get out of it that calbre's ebook-viewer is not likely to handle? Maybe Kovid could provide some insights into what the upcoming calibre 4.x webengine-based viewer can do for us?

eschwartz · 09-03-2019, 09:06 PM

I haven't been following Kovid's engine branch closely, so I'm not sure what, if anything, is planned or implemented for epub3... that might be an important deciding factor.

KevinH · 09-03-2019, 10:37 PM

Happy to let a new calibre-based viewer take over this role as a modern e-reader with many user features. I just wish Kovid would at least consider separating the huge calibre codebase into separate major components: a ebook database and manager with extended metadata support, ebook editor, massive conversion library from just about any format to any other format, ebook e-reader, news/magazine collator, device interface, etc.

About 5 to 10 years ago, I remember asking him if he would consider doing just that (separating calibre into its major component parts) but he was truly against the idea. I really like calibre and greatly respect Kovid for his amazing ability and productivity, but calibre to me has begun to feel a bit like iTunes with too many moving parts, and classes that are too highly interlaced/integrated making it difficult to separate out for reuse in other projects.

How you ever got him to change his mind and move to python3, is truly amazing. Everyone before you failed to sway his opinion. I am really happy to see that happening.

Perhaps that has changed as its codebase has evolved. Will users just be able to download and install just the new ebook-viewer in a standalone fashion? Or will people still have to install all of calibre?

09-01-2019, 12:03 PM	#1
KevinH Sigil Developer Posts: 8,448 Karma: 5703586 Join Date: Nov 2009 Device: many	Does Sigil need an epub e-reader component? Does Sigil need its own e-reader component for reading/final layout checks? Given Sigil and PageEdit both use QtWebengine (Chrome based) and the existence of projects like Readium Cloud Reader and futurepresses epub.js and epub.js-reader, I think it would be relatively painless to combine QtWebEngine with these pure javascript solutions to create a standalone desktop epub3 compliant e-reader with pagination, dual page spreads, and etc specifically for Desktop Windows, MacOS, and Linux. Would this be of any value to Sigil epub devs? Or would it create just one more reading system to worry about? I ask because both Readium and futurepress approaches work well with current browsers if local file restrictions and cross-site scripting restrictions are lifted. These restrictions are something we control in QtWebEngine. And Chrome's removing/restricting extensions means that Chrome based versions of Readium via extensions may be an issue in the future. In addition, if we build the app ourselves to work with local files, we can be assured that no geo, or tracking data is ever used or even generated. I am personally getting quite tired of how much Mac Desktop app store code includes tracking modules (which they claim is specifically meant for program improvements). Many open source projects are being repackaged with tracking libraries in these app store versions. They are supposed to be safe according to the app store but I simply do not trust them in any way. General thoughts? Useful or simply wasteful duplication? KevinH

09-01-2019, 02:42 PM	#5
KevinH Sigil Developer Posts: 8,448 Karma: 5703586 Join Date: Nov 2009 Device: many	FYI: Being able to emulate older (broken?) e-readers would simply be too hard to do. The bugs and omissions can be processor, model, and of course e-reader firmware specific. The future of all reading apps (and according to google, most future apps of any kind on many platforms) is really browser engine based SDKs on both Desktops and of mobile devises. The problem is the competing browser engines out there still leave open variation in e-readers. Firefox/Mozilla has their own engine. On mobile, Apple forces the developer to use its Webkit based Safari engine (forces all browser and web apps to use it), and therefore, of course, Apple prohibits use of Chrome's WebEngine variant for mobile. So no QtWebEngine based e-reader can be used for iOS. So Firefox, Opera, Chrome, etc on iOS is really being done on Webkit. And it looks like future epub specs will be html, css, accessibility, json, and browser based if you look at what is being pushed out there as the epub next gen. So I was less worried about legacy e-readers and more focused on more modern e-readers based on browser engines that can support javascript. Perhaps there is no need for an opensource Desktop epub3 e-reader without a cloud interface and its associated tracking. Perhaps just adding the ability for PageEdit in Preview mode to show the epub in a paginated fashion (one page or two page spreads), and a formatted Table of Contents extracted from the nav would be enough. Last edited by KevinH; 09-01-2019 at 02:47 PM.

09-01-2019, 06:55 PM	#8
BetterRed null operator (he/him) Posts: 21,611 Karma: 29710338 Join Date: Mar 2012 Location: Sydney Australia Device: none	If you didn't do this, what would you do instead. Spend more time at the beach, go skiing, etc are a valid answers Speaking for myself, if I wanted something better than Preview/Page Edit, I would use the calibre ebook-viewer. And I'd rather have multi-lingual spell checking, and/or a user defined folder structure than a viewer. Added: I don't worry too much about tracking, I know the 5-eyes have my number. BR Last edited by BetterRed; 09-01-2019 at 07:01 PM.

09-02-2019, 02:19 AM	#11
democrite Evangelist Posts: 440 Karma: 77256 Join Date: Sep 2011 Device: none	I too like best the page number display of Apple Books for iOS. Numbers are shown in the left margin. In cases where there there is a blank page before a new chapter or section, publishers will tend to put that blank page # either at end of that section at the end of the last XHTML element, or sometimes together along with the next page number in the next header. Showing in margins seems like it'd work best overall. When UX controls (back, TOC, search, font/display change, bookmark) are hidden, page number is shown in the footer. I like the idea of a Sigil standalone reader. Last time I tried them, the majority on macOS were clunky, had a slow UX, the UX was not particularly attractive, and so forth. I use either ADE or the calibre reader; calibre being not particularly feature rich. It would be terrific if a reader had some features such as cache (so re-opening a book was nearly instant) and a control such as sidebar to show search results one could navigate (like most PDF readers). Vertical scroll mode (like Books for iOS) or how PDFs can display on many apps would be nice though perhaps difficult to implement. A particularly nice feature of Apple Books is that it parses the entire book into pages, and thus the scroll bar when scrolling shows an overlay with target page number as well as TOC section. Such is terrific and would be if possible wonderful. Moderator Notice Oversize inline image moved to Attachment. Please follow the Forum guidlines Attached Thumbnails Last edited by theducks; 09-02-2019 at 07:08 AM. Reason: oversized image

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Kindle Reading Component Update	Blossom	Kindle Fire	36	01-02-2018 12:38 PM
Request for a Sigil (Lite) EPUB Reader	Red Wolf	Sigil	5	05-18-2017 08:06 AM
Help moving my Calibre library and the server component	ReiskaC	Calibre	3	03-31-2014 03:18 AM
Epub crashes on Sigil for Mac, OK on Sigil for PC	crystamichelle	Sigil	6	08-14-2013 02:52 PM
Fix browser crashes by updating android component	vldmr	enTourage eDGe	0	10-31-2011 03:05 PM

09-01-2019, 12:31 PM	#2
theducks Well trained by Cats Posts: 30,889 Karma: 59840450 Join Date: Aug 2009 Location: The Central Coast of California Device: Kobo Libra2,Kobo Aura2v1, K4NT(Fixed: New Bat.), Galaxy Tab A	I've always wished for a more (selectable) device accurate emulation (plugin, so the main Dev's are not burdened) in the preview. Having a forgiving , WEB render does not help avoid device (EPUBx) limitations without resorting to saving and loading into the Target Device (viewer). I am that improving has become the mantra for incessant tracking. So go for any solution that thwarts the Big Brother mentality of industry.

09-01-2019, 01:28 PM	#3
JSWolf Resident Curmudgeon Posts: 79,012 Karma: 144284074 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	Would this reader be strict and not so forgiving so we see how things actually look and not the way they look when the reading softare is forgiving? If it's going to be strict, then I'm all for it.

09-01-2019, 01:30 PM	#4
Turtle91 A Hairy Wizard Posts: 3,300 Karma: 20171571 Join Date: Dec 2012 Location: Charleston, SC today Device: iPhone 15/11/X/6/iPad 1,2,Air & Air Pro/Surface Pro/Kindle PW & Fire	+1 for the (selectable) device accurate emulation. I'm not sure a standalone reader would do much more than can be done with PageEdit??? However, would a standalone ereader be easily portable as an iOS/android app? My use would be to make basic corrections (spelling, punctuation, etc) as I'm proofreading on my phone. Or, at least mark the errors on the device, and import the error list back to sigil.

09-01-2019, 06:43 PM	#7
KevinH Sigil Developer Posts: 8,448 Karma: 5703586 Join Date: Nov 2009 Device: many	In all these cases print layout page numbers are being displayed, correct? What happens when a print page boundary does not happen at a heading or chapter boundary? Where is the page number placed and how is the boundary indicated.

09-01-2019, 07:13 PM	#9
KevinH Sigil Developer Posts: 8,448 Karma: 5703586 Join Date: Nov 2009 Device: many	FWIW, a user defined folder structure is our next Sigil project (in other words stop moving everything to fit our structure). We will branch to start work on it immediately after the next release. As for multi-lingual spell checking, that is actually not hard if it is done by a spellcheck modal dialog and not trying to do it while typing. The "do it while typing" is in fact very hard to do as the tag that indicates the language may be far away from the text being checked. The modal dialog spell checker might be a good project for a plugin developer.

09-02-2019, 02:40 AM	#12
Vroni Banned Posts: 168 Karma: 10010 Join Date: Oct 2018 Device: Tolino/PRS 650/Tablet	A more restrictive preview would be fine. Unf ortunetly, ADE will die soon, at least the 2.x version on a mac as they are 32 bit which reaches its end of life. AD$ in some kind of v4 is a mess and i really would like to get rid of it.

09-03-2019, 09:01 PM	#13
eschwartz Ex-Helpdesk Junkie Posts: 19,421 Karma: 85400180 Join Date: Nov 2012 Location: The Beaten Path, USA, Roundworld, This Side of Infinity Device: Kindle Touch fw5.3.7 (Wifi only)	Something to keep in mind is that calibre's ebook-viewer is in the middle of drastic changes. It is being ported to use a single codebase across the desktop viewer and the calibre-server browser based reader. It is being rewritten from scratch using QtWebEngine, instead of the current QtWebkit viewer. It is gaining new features like annotations. The ebook-viewer is generally targeted at being a user-friendly, featureful desktop ereader software, and I guess it should do a fairly good job of showing how a modern, compliant ereader functions. (I mean... we already acknowledge that just as calibre does not show how some ancient boutique ereader software will render your book, Sigil is not going to either, because implementing device quirks is a fruitless, thankless waste of time.) Does Sigil need to develop its own competitive ereader as well? Maybe it would make sense to recommend calibre for this (and make sure that it is suitable for such use). calibre has always been more of a go-to for reading and organizing ebooks, while Sigil has always been more of a go-to for editing them. Just because calibre grew an editor doesn't mean Sigil needs to grow an ereader. If Sigil did get an ereader, what additional use would one get out of it that calbre's ebook-viewer is not likely to handle? Maybe Kovid could provide some insights into what the upcoming calibre 4.x webengine-based viewer can do for us?

09-03-2019, 09:06 PM	#14
eschwartz Ex-Helpdesk Junkie Posts: 19,421 Karma: 85400180 Join Date: Nov 2012 Location: The Beaten Path, USA, Roundworld, This Side of Infinity Device: Kindle Touch fw5.3.7 (Wifi only)	I haven't been following Kovid's engine branch closely, so I'm not sure what, if anything, is planned or implemented for epub3... that might be an important deciding factor.

09-03-2019, 10:37 PM	#15
KevinH Sigil Developer Posts: 8,448 Karma: 5703586 Join Date: Nov 2009 Device: many	Happy to let a new calibre-based viewer take over this role as a modern e-reader with many user features. I just wish Kovid would at least consider separating the huge calibre codebase into separate major components: a ebook database and manager with extended metadata support, ebook editor, massive conversion library from just about any format to any other format, ebook e-reader, news/magazine collator, device interface, etc. About 5 to 10 years ago, I remember asking him if he would consider doing just that (separating calibre into its major component parts) but he was truly against the idea. I really like calibre and greatly respect Kovid for his amazing ability and productivity, but calibre to me has begun to feel a bit like iTunes with too many moving parts, and classes that are too highly interlaced/integrated making it difficult to separate out for reuse in other projects. How you ever got him to change his mind and move to python3, is truly amazing. Everyone before you failed to sway his opinion. I am really happy to see that happening. Perhaps that has changed as its codebase has evolved. Will users just be able to download and install just the new ebook-viewer in a standalone fashion? Or will people still have to install all of calibre?

Advert

Advert