You can make copy and paste work normally in Apple Books with the solutions on https://apple.stackexchange.com/q/137047 ‘Don't want iBooks to always paste the “Excerpt From” of what I have copied’.
Firefox addon: Download files and read and modify the browser’s download history, Access browser activity during navigation, Access your data for all web sites
Chrome Web Store obscures the full permission list, but the comments for that extension admits: right "read and change all your data on the websites you visit" needed
It's 2021, you should view all browser addons as a threat.
Presumably if Google decided to add EPUB support, Edge would get it back too, but Microsoft hasn't decided that feature is valuable enough to add onto their modifications.
I also think it's particularly sad that Windows 10 had a perfectly good EPUB app, Reader, that Microsoft deprecated aggressively to force everyone to read eBooks in Edge... only to remove eBook support from Edge too.
An ebook, unzip, is rarely bigger than 1Mo, which is lower than what most page are today.
Oh no, we can't have that. Here are some "beautiful, performant and lightweight" Electron ePUB readers/organizers: https://www.electronjs.org/apps?q=epub
Rather than complaining about the Electron apps, write better cross-platform apps that don't use Electron.
I know it's fashionable to dog on Electron, but if it didn't fill a legitimate need, people wouldn't use it.
It's easy to compare an Electron app, that actually exists, with some imaginary native app that doesn't.
It's not so easy to find the budget and personnel to actually build dedicated apps for minority platforms. The choice generally isn't between "bloated Electron app" and "sleek native app". It's between "bloated Electron app" and "no app at all".
I suspect Electron frequently fills a need for the developers, instead of their users. It's easy to deploy, cross-platform and stable, I give you that, but the users pay for it with RAM, disk, CPU and energy.
A single user might not mean much, but multiply that by the millions of Electron programs installed, that's the scale of lost resources that pay for the advantages of Electron.
If there's "no need" for them, why are people using them? How come you get to decide what other people "need"?
> I suspect Electron frequently fills a need for the developers, instead of their users.
It fills the need of the users to have actual apps they can install and run, rather than imaginary ones.
> that's the scale of lost resources that pay for the advantages of Electron.
People don't hand-write programs in assembly language any more, either, even though that means that you can no longer write a word processor that runs in 12K of RAM.
I'm not saying all Electron programs are bad. VSCode, for example, is surprisingly good for many use cases, and being an IDE with many features, its resource usage is pretty justified.
I'm also not buying that people need software that only exists as Electron programs. Check the categories in https://www.electronjs.org/apps, there's even taskbar notifications and app launchers, do those merit running a dedicated browser?
It's not that users need "non-imaginary" software and Electron fills that need, it's that most users don't know about native and web frameworks, and they will install software as long as their computer can run it, even if better alternatives exist right now.
I see this sort of assertion pop up often, but it never is accompanied by specific verifiable examples of what those options are.
Can you point out a single example of said native software that fills that role in every platform? A single one.
(For instance : VLC, Spyder...)
Compared with simple html+javascript running on a webview, Qt is relatively hard to maintain and develop, relies on source code generations and processors to work, prototyping tools are subpar and undermaintained, has no support for centralized theming, it's basic support for component-specific theming is already CSS shoved in a convoluted way, its model/view take is absurd and very poorly engineered, and yeah there's the fact that it forces you to write frontend code in C++. But wait, it's not even C++ because it requires code to be preprocessed to generate boilerplate code.
And let's not pretend that Qt's widgets successor is already a markup+javascript combo that takes the bad parts of javascript and bundles it with the bad parts of a custom markup language.
What is python qt support like for android and so forth by the way?
Calibre seems to use all the memory after some time and then it starts to use swap memory...
Not the fault of the library developer - they’re just trying to help, but it’s like instead of fixing holes in the ship, we build pumps to dump the water out. Too many pumps on the ship and it gets bloated and can’t take any cargo. This is the current web in a nutshell. We need a ship captain that can guide us authoritatively.
I have tried a lot of browser extension based and standalone readers in the past and they all render things differently with different bugs. Something doesn't add up.
So it's not quite just HTML/CSS when packaged up, but it is just HTML/CSS when it comes to the actual text content.
Other than getting the various constituent files zipped up, with their interrelated contents synced, the only other oddity is that the renamed ZIP must always start with an uncompressed 'mimetype' file.
The IDPF maintain the standard. The easy one is v2 (http://idpf.org/epub/201) but that is now deprecated. Unfortunately v3 allows more interactivity and scripting - and we all know how bad the tech industry is at keeping that kind of stuff secure.
It's XHTML to be precise, and that doesn't change no matter what processing is done by readers, it's still (just) XHTML. The format is literally described in the submission :)
> they all render things differently with different bugs
Just like HTML did in the beginning.
> Just like HTML did in the beginning.
ePub wasn't born yesterday. It's revision 3, first released ~2006/7. XHTML was proposed to correct and prevent the kind of problems html4 had because of how it organically grew, specifically relying on its XML root (no pun intended). Epub should definitely not suffer from bugs like HTML had in the pre-XHTML and pre-HTML5 era.
I sometimes have bugs like:
- whole book is black
- some pages can't be loaded/read so I have to skip them
- some toc and back link don't work like they should (probable bad markup)
There's also some readers oddities:
- completely inconsistent line-height
- aligned setting not working at all
etc.
Anyway, there's a reason XHTML2 didn't happen and we got HTML5 instead. Either ePub has some extensions that are not trivial to implement or most readers are buggy. Or both.
The three main components of the ePub (aside from the actual pages) are the TOC, the spine and the manifest. The manifest basically tells you where everything is, the TOC is the table of contents which can link to various pages and the spine gives you the traversal order.
Some mistakes I've seen are using the TOC to traverse the book. Using the spine to traverse the book but not handling hidden pages properly. Not handling two page spread properly.
So yeah the spec is nuanced and it would be easy to make a reader that worked with a lot of books but then had weird issues on another set of books that aren't particularly different. We ended up writing our own parser because we kept finding issues with the main open source ones.
I recall using this repo (https://github.com/IDPF/epub3-samples) to test specific functionality to make sure it was in line with the spec.