Comment by bookworm_ | Hacker News Reader

Comment by bookworm_ | Hacker News Reader

Parent Full thread

Should be a format that can be grep'd, made into PostScript, DejaVu, etc. Versatile. ASCII works well for that. Open, non-proprietary format.

Not only that, working with raw text is so much faster than anything else. less(1) is the most responsive "ebook reader" I've ever used. It never chokes on huge files. less -n

Ever try reading 100 or more PDF's in one sitting?

But with 100 ASCII docs, it's possible to skim them fast using less, or mine some text with some UNIX utility.

I like what this judge said. Digitizing books not just about putting the book on a "paper-like" screen with beautiful fonts, it's about enabling new utility. Working with the text.

> Should be a format that can be grep'd, made into PostScript, DejaVu, etc. Versatile. ASCII works well for that. Open, non-proprietary format.

Org Mode.

http://orgmode.org/

I'm in for plaintext, but ASCII is ill suited for most languages.

  > It never chokes on huge files

You've never tried to reach the end of a 200MB log file with a cold cache... :P

It can handle files that big no problem. Use the -n switch to supress page numbering.

But with a 200MB file, chances are you will only want to view part of it. Unless you have superhuman reading powers. ;)

Dissect the part you want with some filter (sed, awk, tail, whatever) and feed the result to less.

epub is xhtml+ wrapper

If you're targeting grep as a tool to operate on your data, then HTML isn't the best 'raw' format as grep isn't HTML-aware. It can't ignore markup, or translate encoded values (e.g. & => &).

But ePub as a format is open and well understood, and there are XHTML parsers in every language you might care about.

I thought we were talking about viewing ebooks.

Reply on news.ycombinator.com