contact9879

Signal isn't in a Windows app store to be kicked out of, though

it is absolutely insane that we're forced to DRM our own applications to protect ourselves from our own computers

This is a revision of a paper that first appeared as an eprint back in September when PQ3 was announced.

https://eprint.iacr.org/2024/1395

I've been using a tangential but still pdf tool, pdfux.com since it was posted here on hn

Thanks for this! I'll definitely add it to my bookmarks

sure, but html isn't only used in a browser context. I have a severely under-powered ereader that I use to read epubs (html). It already takes ten seconds to paginate on first open and font size changes. I can't imagine how long it would take to non-naively wrap lines

Quick example would be https://standardebooks.org/ebooks/mark-twain/the-innocents-a...

Try zooming in and out with text-wrap: pretty vs text-wrap: wrap

the distributed proofreaders process does include a mandatory spellcheck

The work done by Distributed Proofreaders is pretty amazing. I try to contribute my 35 pages as often as I can. The backlog there is pretty insane even while finishing upwards of 150 ebooks per month

it truly is an "online hobby that feels constructive". you get these tiny glimpses into our shared literary/cultural history while knowing that the work you're doing is for the benefit of all (benefit of the public domain)

I can't really answer that because I haven't actually tried to use an LLM on any part of the process. The vast majority of the process is semantic markup using (x)html and proofreading. The markup process could, I guess, use an LLM, but most of it is already automated using regex and linting.

Standard Ebooks grew out of a pay-what-you-want experiment that Alex did ~10 years ago

well, that would be up to Alex. but as that would require a pretty substantial organizational and responsibility shift, I imagine, no, he would not.

As it is now, Alex is editorially responsible for all output of Standard Ebooks. Changing that would require someone with the time and experience willing to take on all the responsibilities that Alex currently has for each of those other languages.

I think it's important to note that in the past, typesetters and printers had a much more editorial role than the process today. Authors would submit handwritten manuscripts and the typesetters in many cases would have to fix the author's mistakes, spelling, etc. to conform the manuscripts to printing standards with the author having limited communication or ability to proof the final plates

Today, it's much easier for authors to have a greater say in the final presentation due to the digital composition process

there is quite a lot of automated changes using standard ebooks open source tools package

the vast majority of textual tooling is regex-galore, but there is also automated epub tooling in there too

i also don't think it needs debating. my point was that the issue, the too narrow leading in the online view, is just not going to be fixed unless someone points it out to someone that can fix it. if that's you, great! you can submit a PR to the git repo. or, if don't have the time or want to have to go find where the line height is defined, submitting a comment to the mailing list or noting it on the issue tracker will let a volunteer fix it

from my own experience, Alex is very amenable to improvements. the online view of the ebooks is just not used by probably anyone to actually read the books (just use an ereader app or device its a way better experience anyway) and because of that no one has cared to point it out until now

it varies widely depending on the length and type of book and how much free time the volunteer has to devote to it

Anywhere between 1 week for the simplest (straight narrative, not too much verse or endnotes) and ~1 year (thousands of endnotes, pages of verse, drama, in-line references to book titles, use of technical terms, etc)

while I don't disagree, ¿por que no los dos?

presumably, which is why i encouraged submitting a note to the mailing list or the standardebooks/web repo on github

Yes, you signal your intent on the mailing list subject to approval by the editor-in-chief

To me, that niche is already covered by Wikisource. Standard Ebooks as a project is very strict about conforming to its editorial and quality standards. On boarding more languages would require volunteer editorial experts in those languages.

Besides, projects in other languages can absolutely build upon Standard Ebooks work, but to expect Standard Ebooks itself to support other languages is just too outside the scope and expertise of the volunteers available.

No, LLMs are not used (nor would they be allowed). As for whether you would consider OCR to be AI, then... possibly?

its never too late to expand your "stuff I really like" further into the public domain!

there are whole generations of wonderful and insightful works that essentially disappeared from present consciousness for no reason other than for being old

since ebooks are primarily (only?) text you don't have to worry about UI elements and such which simplifies a lot of the css

footnotes aren't really a thing with ebooks (at least as far as displaying the note on the page with the text). Because it is just a html renderer, footnotes are presented as mutual <a> elements located in the endnotes at the end of the book

the only issues i've found with koreader is its default margin size and its display of standard ebooks' titlepages but (I believe) these can be fixed with a fairly simple user tweaks css

this also somewhat surprised me at first but I think it's obvious in hindsight, though they don't have to be a full-blown web browser (you can go read the epub specs at W3C to see what's supported)

as for (2) I'm not sure why you think it would make it less easier? being html, text reflows automatically based on screen size, font size, line height, etc

the online view is not the primary way readers are expected to read the ebooks. downloading the epub and reading on an ereader (edit: where line height and font size are customizable) is the expected and best supported method

however, contributions are very welcome and everything is hosted on GitHub if you'd like to suggest improvements; or send your thoughts on the mailing list

if you're reading a style manual it might :)

but no, the manual itself is not really mobile-friendly. you can check what an actual ebook would look like though:

https://standardebooks.org/ebooks/louis-couperus/the-tour/al...

That's an en-dash

and for those who already saw this first post, part 2 was published today: https://blog.cryptographyengineering.com/2025/02/06/how-to-p...

the link posted by tromp is to the readme from 3 years ago. you should read the latest readme before making assumptions about the quality of arti today

I used Fedora Linux from 28 until I got a M1 MacBook 3 years ago. I think I'll use this occasion to seriously try out Fedora Asahi Remix!