Quickly-running plugins. I haven't used them, but it seems like a important aspect of the editor. Here's the plugin preferences window: https://i.imgur.com/HAtJ5ej.png
"When I said I couldn’t work as the sole developer of Sigil people went overboard and acted like the sky was falling. Kovid Goyal from calibre stepped in to create Sigil’s Spiritual Successor which is an EPUB editor as part of calibre."
There's far too many developers that seem entire unaware of the very basics of marketing or how to connect with a target audience that's not other developers.
Developers want screenshots. The only people who don't need a screenshot are the project contributors.
It's kinda funny how we will spend years collaborating on some project yet not think to spend 30 seconds checking a screenshot into the readme for a project that we supposedly want others to find and use. It's like self-sabotage.
I think it's because there's 10 things to work on at any time and adding a screenshot can be useful but the documentation will constantly change as the project is updated.
Then you finally feel like you're done but now there's 100 different things that you have to document and you get overwhelmed.
Personally, not sure I would trust my project, and my time and effort to software written by someone who won't see the value of adding a screenshot to their software's site.
It was started in 2009, and for some reason.. no screenshots.
I also went to the web site looking for screenshots, but the "home" page is a detailed changelog. Oh, there's an "About" page, screenshots are probably there-- no, that's a life story of the project.
Neither of these are interesting for the (presumptive) target audience of "people who want to edit epub files".
these situations are so frustrating it almost feels like it was their malicious intent to cause you mental anguish sometimes. "hey, check out this gui tool that you need! not gonna show you what it's like though ;) you just gotta download it and set it up."
While I'm not one to get overly angry about it, cause it just kinda happens with a lot of projects as well as with a lot of Linux apps, no screenshots on the distro repo GUI app for a lot of software I tend to agree. It would make a nice contribution to their GitHub, but their homepage should feature a screenshot or two on the side or somewhere immediately visible to someone visiting their website, or at the very minimal a 'Gallery' page.
I haven't played much with any of this stuff, but one thing that I'm curious about is what is the advantage of having a container format like this, rather than just having a single giant HTML file (with embedded CSS & data: uri images)?
For editing this would be ridiculous, but for transport and presentation it seems much more compact and useful. It is easy to target as an output format for a variety of tools, without understanding a bunch of quirks of the format. It would be easier to render, since the application has to make all the decisions about where to place content and support reflowing anyway.
An .epub is already what you describe; it's a .zip of .xhtml, images, and supporting files you edit directly seen in the sidepanel: https://i.imgur.com/tdCGcqS.png
An ebook editor just entails helping you edit those .xhtml files in a slightly more domain specific way, generating a few extra files (like table of contents), and producing the distributable zip.
Though I may have misunderstood which "container format" you were referring to.
No, what I'm describing is a single .html (or .xhtml file, if you like), compressed and sent on its way. Editing it as a series of xhtml, css, img, and manifest files makes perfect sense -- it allows a human to craft a book using the level of tooling that makes the most sense for them (from a word document to raw html to markdown to more sophisticated tools) but all of those tools can then retarget to a monolith that is easy to define and consume.
They do; probably xhtml/XML is not really an ideal format because it isn't easily linearalizable, but if ereaders are using a reduced set of the functionality, then they can probably safely assume that they can just split the file at a <p> or <mpb:chapter> tag without loss of fidelity, and just consider that all style-related content needs to occur in <head>.
My comment below has some remarks on pagination and reflowing that mean that a reflowable HTML file capable of being rendered by an ereader is likely subject to certain restrictions on the content to make it work. There would probably have to be a one-time indexing job (noting paragraph and chapter breaks to allow random-ish access into the file) but I think that's not crazy even for a very large document.
For long books or books containing large images or videos, that giant HTML file would be so gigantic that many e-readers would be slow at loading them or even fall over (the average e-reader doesn’t have a fast CPU or loads of memory).
I also expect data URIs for images would make the HTML file, even if gzipped, larger than the equivalent ePub.
HTML also isn’t good at doing the book-like things such as pagination, tables of content and on-page footnotes.
Videos? I guess for some applications. Either way, the giant HTML file is nasty, yes, but the epub would be the same size [1]. It would be harder to process, though, because even XHTML has a nesting structure that doesn't lend itself to decomposition easily.
For the most part ebooks are reflowable, so pagination only matters in the sense of manual page breaks, and HTML has to be extended to handle that even for epub. Similarly on-page footnotes (<aside> in iBook epub and <a href><sup> for Kindle) need to be handled now in HTML extensions.
Tables of contents and indexing content is a little harder, but if the format were well-defined (something like <chapter> tags, or just using <h1> as semantic tags) then it would be easy to generate as well. Or it could just be done using a bunch of <a href> in an explicit TOC -- easy enough for a compiler to handle.
Metadata is in theory more difficult, for things like author, etc., but defining tags in the <head> of the document would be just as easy as the manifest definitions that readers have to deal with now.
[1] gzipping random data base64 encoded is ~3% increase in file size.
What's the best eBook reader? I'm getting fed up with Amazon, and I'd like to have some kind of clone of the Kindle. Key thing is SaaS -- I'd like my reading positions, notes, etc. to sync between machines and available through a web interface.
Glad to pay a modest amount for hosting on AWS or similar, if I'm in control of my data. Not so glad to do another corporate lock-in.
Calibre is usually the go-to open source ebook reader. I don't know about SaaS but it does include a server so if you keep you ebooks centrally located and acess them from there, your bookmarks and notes would be preserved.
Sorry for OT, but there are no PMs on hacker news. I found your comment about CO2 sensors for Raspberry PI from last year [0]. Have you finished this project? If yes, could you share a few details?
For my first Rasberry PI project, I am considering buying Enviro for Raspberry Pi + Air Quality. I would like to add an affordable CO2 sensor that would require minimal config and no soldering. Pimoroni folks told me MH-Z19 would not work because of the number of pins. Would you have any suggestions on what sensor to choose and how to make it work with Enviro / Raspberry PI?
Is it more than just an ePub reader? You really feel it’s justified to spin-up an electorn app (!!!) to read an ePub? I use Emacs’ nov.el or Foliate which are not only low on resources but also instantaneous to open files.
I don't like it either, but the only way it is technically feasible to support the full potential styling/markup of an EPUB is to use a browser engine, and therefore electron is a logical choice. Can your specialized EPUB reader support MathML? Or vertical-ttb text?
Just this. Epub depends on the same tech stack as the web. So, either you use an engine that supports that in full, or you are going to be missing pieces of the standard. Which means that most other reading software opts for missing pieces of the standard.
An .epub is literally a zip of xhtml, css, and images.
If you want to build a good ereader, you either use a web browser or you reimplement one. And you have to support things like https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens, rtl, mathml, and—well—the rest of the nontrivial stack.
I have a bad news for you, recently I was interested in how could I write a good QML/Kirigami based ebook reader and looked at all the existing Linux epub reader and each one was using a webview for the epub rendering. But they usually try to integrate better with the rest of the app and your DE so you just don't see it.
EDIT: the only epub reader I know that doesn't use a webview is Okular and the rendering using QTextDocument basic html support is horrible.
It's irrelevant to me whether or not it's an electron app. I'm not running a Pentium 486 system. I've got more RAM than I know what to do with...I'll run a half-dozen instances of Thorium if I wanted to...no worries.
It’s not just resources. It’s usability. Electron apps look and feel out of place to me. I would personally never use one let alone for reading an ePub. I get the point about perfect rendering, but that’s a specific problem I’m personally not worried about.
Sigil has been around for a while. I used it a few years ago to typeset a sci-fi novel I published through Amazon KDP. Unfortunately it was not as easy for me to use as Apple Pages, which supports saving to ebook directly.
I've used it in the past, and it is quite decent.
Reminds me of a similar looking UI contraption I saw recently: https://staticdelivery.nexusmods.com/mods/1704/images/921/92... (the multicolored database icons at the top)
It appears to be largely equivalent to the Calibre editor.
https://sigil-ebook.com/about/
It's kinda funny how we will spend years collaborating on some project yet not think to spend 30 seconds checking a screenshot into the readme for a project that we supposedly want others to find and use. It's like self-sabotage.
Then you finally feel like you're done but now there's 100 different things that you have to document and you get overwhelmed.
It was started in 2009, and for some reason.. no screenshots.
For me, that breaks trust.
Neither of these are interesting for the (presumptive) target audience of "people who want to edit epub files".
https://duckduckgo.com/?q=sigil+ebook+screenshot&ia=images&i...
For editing this would be ridiculous, but for transport and presentation it seems much more compact and useful. It is easy to target as an output format for a variety of tools, without understanding a bunch of quirks of the format. It would be easier to render, since the application has to make all the decisions about where to place content and support reflowing anyway.
An ebook editor just entails helping you edit those .xhtml files in a slightly more domain specific way, generating a few extra files (like table of contents), and producing the distributable zip.
Though I may have misunderstood which "container format" you were referring to.
My comment below has some remarks on pagination and reflowing that mean that a reflowable HTML file capable of being rendered by an ereader is likely subject to certain restrictions on the content to make it work. There would probably have to be a one-time indexing job (noting paragraph and chapter breaks to allow random-ish access into the file) but I think that's not crazy even for a very large document.
I also expect data URIs for images would make the HTML file, even if gzipped, larger than the equivalent ePub.
HTML also isn’t good at doing the book-like things such as pagination, tables of content and on-page footnotes.
For the most part ebooks are reflowable, so pagination only matters in the sense of manual page breaks, and HTML has to be extended to handle that even for epub. Similarly on-page footnotes (<aside> in iBook epub and <a href><sup> for Kindle) need to be handled now in HTML extensions.
Tables of contents and indexing content is a little harder, but if the format were well-defined (something like <chapter> tags, or just using <h1> as semantic tags) then it would be easy to generate as well. Or it could just be done using a bunch of <a href> in an explicit TOC -- easy enough for a compiler to handle.
Metadata is in theory more difficult, for things like author, etc., but defining tags in the <head> of the document would be just as easy as the manifest definitions that readers have to deal with now.
[1] gzipping random data base64 encoded is ~3% increase in file size.
Writing it in sections and assembling the sections for rendering allows me to also export for multiple targets, and multiple versions.
Think "build" for books.
Glad to pay a modest amount for hosting on AWS or similar, if I'm in control of my data. Not so glad to do another corporate lock-in.
https://calibre-ebook.com/about
Sorry for OT, but there are no PMs on hacker news. I found your comment about CO2 sensors for Raspberry PI from last year [0]. Have you finished this project? If yes, could you share a few details?
For my first Rasberry PI project, I am considering buying Enviro for Raspberry Pi + Air Quality. I would like to add an affordable CO2 sensor that would require minimal config and no soldering. Pimoroni folks told me MH-Z19 would not work because of the number of pins. Would you have any suggestions on what sensor to choose and how to make it work with Enviro / Raspberry PI?
0. https://news.ycombinator.com/item?id=20185649
https://www.edrlab.org/software/thorium-reader/ https://github.com/edrlab/thorium-reader
Not saying there shouldn't be an app for those who want it.
If you want to build a good ereader, you either use a web browser or you reimplement one. And you have to support things like https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens, rtl, mathml, and—well—the rest of the nontrivial stack.
EDIT: the only epub reader I know that doesn't use a webview is Okular and the rendering using QTextDocument basic html support is horrible.
Your options are A) web view, B) crappy RSS reader.