acabal

Once you're very familiar with the process, you could get a draft of a basic prose novel ready for proofreading in a few hours. Then it has to be proofread and completed.

Beginners, and people working on more advanced books, can take much, much, much longer.

Each repo is a history of the ebook including editorial changes, typos fixes, and the like. Having a single repo containing thousands of ebooks and their histories would be pretty annoying to browse.

Spelling varies widely across the eras our ebooks were published in. Therefore we attempt to standardize spelling to what a modern reader might be familiar with. We only make sound-alike changes, like to-morrow -> tomorrow.

This is a common practice that editors and publishers have quietly engaged in for centuries. For example, today you are not reading Shakespeare in the way it was spelled in its first printing.

That's fine! Our editions didn't erase any of the other editions you can find online and in print. You're more than welcome to select any edition that fits your reading preferences.

In addition to what Robin mentioned below, some of these placeholders are for books on our Wanted list. I also think it's useful to show readers that particular books are looking for volunteers to produce, and also to show that some books they might want are locked away by copyright for possibly decades. In that sense it's partly a political message.

We don't have a list of authors yet, but that's a good idea to add!

The manual has some known issues on mobile, I believe there's a GitHub issue open about it. It's low priority because the manual is rarely read on mobile. PRs welcomed!

Lots of people have tried similar projects in other languages but as far as I know none have persevered.

Personally I think it's important to have one person in charge who is able to approve of the quality of all the project's output; for now, at SE, that person is me and I'm only an expert in English.

It makes a lot of sense when you recall that HTML and its ancestors were designed to mark up and format documents, i.e. books. One of the most fundamental elements is <p>, which stands for... paragraph.

Each renderer differs in capabilities, and most are stuck in a subset of early-2000s capabilities, so designing an ebook is very much like designing for the 90s era web. Lots of hacks are required to get the same file to look good on many different renderers, and achieving that is one of the goals of Standard Ebooks.

TEI is something like that, but the amount of effort required to mark a book up like that would be astronomical.

Standard Ebooks only works on English-language books, as typography varies between languages and we're only experts in English.

Yes, we have complete feeds available for our Patrons: https://standardebooks.org/feeds

I read on an old Kobo, using Kepub files. Their Kepub renderer is quite good.

I think Kindle's renderer hasn't changed significantly for many years, and it had always been pretty bad. I always say that Kindle seems to have been created by people who hate books.

The best renderer around is iBooks on an iPad, which as far as I can tell uses an up-to-date Webkit.

You can also join our Patrons Circle to have this book added to our Wanted Ebooks list, which is a list of suggestions for our volunteers to work on: https://standardebooks.org/donate#patrons-circle

Editor-in-chief here, happy to answer any questions, as always. We also recently celebrated Public Domain Day with an especially notable crop of books, including The Sound and the Fury, All Quiet on the Western Front, John Steinbeck's first novel, some Hemingway, Gandhi, two Dashiell Hammett novels, and more: https://standardebooks.org/blog/public-domain-day-2025

We use the Flesch-Kincaid algorithm to calculate reading ease. For most books it works pretty well, but for avant-garde prose like The Sound and the Fury it fails pretty badly. It also considers Ulysses to be "fairly easy"!

Some placeholders like this one exist because they are part of other collections for which we have more items. So when the reader is viewing the other collection, they can see which items we have and which we don't.

I'm the editor in chief of Standard Ebooks and currently I read on an older Kobo eink reader, the Aura One.

When using their Kepub format, Kobo has the best eink renderer on the market. I believe you can also install Koreader on them.

Editor in chief here, happy to answer any questions!

Hi HN, editor-in-chief of Standard Ebooks here! As always I'm happy to answer questions about the project and discuss ebooks and literature.

Some time ago I read You Can't Win[1], a 1926 memoir by a hobo-by-choice named Jack Black. He describes his life as a hobo in various cities (including SF!), and the picture he paints of the turn-of-the-century will be eerily familiar to anyone living in a major US city today: huge numbers of homeless hopelessly addicted to wine and opium (called "hop") that was cheap and easily accessible in streets and flophouses; tent cities lining the outskirts of town; entire communities of people living in that fashion and outright refusing to re-enter society.

The big difference between now and the turn of the 20th century is that back then, the law had little to no tolerance for public vagrancy. Jack Black describes dodging sheriffs, being locked up for the crimes of vagrancy and burglary, spending long stretches of time in prison and emerging completely unreformed, immediately returning to his life of encampment and crime. Even though ultimately his behavior didn't change, the law made him spend significant lengths of time removed from society.

I don't know what the lesson is here, if there is one. While a century ago their approach also didn't solve the problem, it did result in more livable cities for everyone else in the meantime. Perhaps one takeaway here is that it the problem isn't truly "solvable" given how we have structured our markets-based society.

[1] https://standardebooks.org/ebooks/jack-black/you-cant-win

Getters aren't for everything. But for a basic CRUD case like above, they're a nice way of having a clean OOP contract by demarcating a clear difference between properties, which are pieces data attached to the object that the caller can read and write, and methods, which are the caller can change the object's or app's state, or perform actions with possible side-effects.

Very often for a typical CRUD app, I as the caller don't really care how we got the `LastForumsPost`. It's just an object mapping that comes from some data source like the database. And if I do care, I could get it outside of the object, and set it myself.

It's a matter of OOP modeling. Object methods are better reserved for performing actions with side effects, or complex logic or calculations, and not for getting state or simply setting public properties; and as a caller, I don't really care about the implementation details of (in my above example) getting the last forums post, I just care that it's a property I can access. (Maybe it came from a cache and not the database? Maybe it was set earlier in the script? I don't care.)

Putting it behind a getter doesn't "hide" control flow. It just makes for a cleaner interface from the caller's perspective.

FWIW, I almost never use setters. Getters are are much more useful, especially for lazy-loading basic properties.

They are very useful when modeling CRUD-dy objects, because you can lazy-load infrequently-accessed child object using getters.

It makes for a cleaner OOP-y interface in which the caller only cares about actually exposed properties and not methods to get and manipulate hidden properties.

IMHO using properties directly is a much more natural way to talk about objects, than having a bunch of methods to get properties. Getters and setters also help ensure that methods are only for changing an object's state, not getting an object's state. For example:

  class User{
      public ForumsPost $LastForumsPost{
          get{
              if(!isset($this->LastForumsPost)){
                  $this->LastForumsPost = <get from database...>;
              }

              // Return the cached property so we don't keep hitting the database.
              return $this->LastForumsPost;
          }
      }
  }

  print($user->LastForumsPost->Title);
  print($user->LastForumsPost->PostId);

  // instead of...

  print(($user->GetLastForumsPost())->Title);
  print(($user->GetLastForumsPost())->PostId);

I'm most excited for property hooks. Having getters and setters as part of the language syntax was something I dearly missed from my C# days, nearly two decades ago.

In my projects I sometimes emulate getters and setters using `__get()` and `__set()` but that's heavy-handed and requires lots of PHPDoc annotation for type checking. Property hooks look awesome!

If you think it's bad that `break-*` isn't supported in Firefox or Chrome, wait till you see what your ebook looks like in Kindle, or worse, ADE-based readers, of which there are still many in use!

Kindle, the reading device with by far the largest market share, is basically the IE6 of ereaders - too big to ignore, and at the same time dragging down the entire ebook ecosystem with its crappy renderer. Amazon has shown little interest in improving it for over a decade now, while simultaneously fragmenting its own ecosystem with a variety of different proprietary formats that support different CSS and features.

ADE, while less common in new devices, is still very common in much older devices - B&N's eink Nooks were based on ADE at least as late as a few years ago. (Perhaps they still are?) ADE is closer to IE5 in terms of CSS support!

At Standard Ebooks we're often hamstrung in our attempts to make beautiful ebooks by these big players refusing to improve their renderers. We're forced to dumb down our CSS and use outdated techniques (like occasionally having to use tables for layout!) because ebook renderers are so bad.

iBooks is the top tier renderer, because as far as I can tell it's basically a wrapper for an up-to-date Webkit; next is Kobo - also Webkit-based - along with other Webkit-based indie apps. The rest of the big players are far, far, far distant.

It's available as a free ebook at Standard Ebooks: https://standardebooks.org/ebooks/ernest-shackleton/south

(The name of the book is South!, the subtitle is "The Endurance Expedition.")

The more important point the comment you're replying to makes is not "what if people could diet and exercise" - i.e. accept the modern American lifestyle as given, plus force yourself to go to the gym and eat chicken and broccoli - but rather that the modern American lifestyle in fundamentally structured to lead to people being overweight.

Instead of being forced to drive everywhere for the most basic possible human needs - like getting groceries, going to the doctor, or dropping kids off at school - as is the case in 90% of America - what if you could walk to those places instead? You would get exercise as part of your every day life, with no extra effort!

What if instead of corn syrup being so heavily subsidized, we could use more filling sweeteners in a lower amount instead? What if people lived closer to agriculture, instead of in faraway suburban tract housing only accessible by car, so they had easier access to fresh meat and vegetables, instead of ultraprocessed package food?

These dreams are not "diet and exercise", they are a fundamental reshaping of American lifestyle that would directly lead to weight loss. We know this, because America used to look like this before, say, 1940. In old photos you see people in huge crowds in streets as they walked to their everyday errands, and menus and recipes of the era are mostly minimally processed food that is mostly local. Americans of the past were not overweight, because the way society arranged its physical existence didn't permit it!

Pale Fire has been my favorite book for a long, long time, ever since I read it as part of a course in university. After all these years I haven't read a better, more intricately-constructed book.

It was suggested to me to read the intro first, then skip the poem and read the endnotes start to finish, then to go back and read the poem. The index is part of the fiction and must also be read.

I think the keys to really enjoying Pale Fire are 1) to realize that while the subject matter is ostensibly serious, Kinbote is really a comic figure, and you're meant to be laughing a lot of the time; and 2) the great puzzles to unravel are who is John Shade, who is Charles Kinbote, are any of them even real, and who wrote the poem? The book is so beautifully written that it can be argued that none of those questions have definitive answers - and thinking about them, and how Nabokov threads clues and possibilities throughout the novel, without any of them seeming to be contradictory, is the pleasure.

You are correct that we usually do that, however for Ulysses we made an exception and transcribed the print exactly, so there are no changes from the print edition. (Except for whatever pre-1929 corrections we brought in based on our research.)