Archives for category: Uncategorized

Thanks to everyone for the enthusiastic feedback on the widget. We’ve made a few minor fixes here and there but I wanted to announce one important enhancement we just pushed. Now the script tag you embed in your site has an additional attribute called “ownwin.” This attribute is set to false by default, but if you want the reader to pop in its own tab instead of in the same window, just set this attribute to “true” instead. So the tag will then look like:

<script src="..." ownwin="true"></script>

This addresses some situations where sites are using framed content which won’t allow the reader to overlay properly. Thanks again for the feedback. Continue to let us know about layout issues, as we can’t predict or simulate the many environments this thing might be exposed to.

We think this is so punk rock! Embed the book AND the community from BookGlutton’s Unbound Reader directly into your site using BG’s new widget. “Embed the community,” you may find yourself asking, “Across domains?” Yep, chat with anyone reading the same book from any website. How cool is that? Officially the widget is called the “Book Launcher,” because you click on it to launch the book from your site (duh), but around the office we just call it THE PUNK ROCK WIDGET. Here it is in action:

You can log in from inside the widget to access your bookclubs or to mark your place, browse the catalog, switch books, and all manner of reading tasks. You really don’t need to visit the BookGlutton site any more (we’ll miss you), except to manage friends and reading groups. And the magic of technology makes the content as secure as it is on BookGlutton’s site, so we’re hoping publishers will recognize the opportunity to bring you even more content.

Here’s a youtube video that outlines 8 minutes of widget goodness:

The deal is that you can grab this code from inside the widget itself. Or, if you find a book on BookGlutton you can get the code from that book’s detail page. And it’s free, so what are you waiting for?

You can read the press release here.

The May/June issue of Writer’s Digest has honored us in its new List of 101 Best Websites for Writers! This is great news – last year there were over 2100 entries to consider, so we know we’re in good company. BookGlutton is listed in the writing community section. The article isn’t currently online, but you can find it by heading to your nearest local bookstore and grabbing a copy. Heck, grab two. We did.


Read it online here.

Just an update on a side effect of some of the changes we’ve made: some books may take a long time to load and/or paginate. You will know you’re seeing the problem if you open a book and each section appears to require pagination of the entire book. This is due to a problem we’ve just found and should be working on today. Please be patient while we get a fix in, and don’t let this stop you from reading.

We appreciate the enthusiasm we’ve seen for the simple HTML to EPUB converter we launched last year. To date, the conversions measure in the tens of thousands. And since this uses our core EPUB class to do its work, we will continue to maintain and upgrade it.

The latest improvement is somewhat experimental. Now, by default, the converter splits HTML documents into separate documents. We’re curious to see how this fares. It could raise issues with linking in those documents, but it was needed to address the issue of making EPUB files more friendly with slow processors/connection speeds. If enough of a fuss is put up, we’ll put in an option to revert to the old way of linking to fragments in a single doc.

Among other changes we made, some validation errors have been fixed, all HTML is now processed according to an element whitelist, remote images are supported (use absolute URLS), and various other bugs have been fixed (most notably one that was causing invalid IDs).

Despite all the improvements, we were dismayed to see that converted files have the invariable behavior of crashing Digital Editions, hard. It appears to happen when choosing any section other than the cover. I’ve run them through validation several times, pored over the package files with my own eyeballs and while there are some XHTML namespace issues reported by epubcheck, I can’t find anything serious enough to merit crashing the app as hard as it does. We’re small and have other pressing issues, so we’ve run out of time to troubleshoot it for now. It stands as is. That said, I will happily fix the problem if someone brainy can identify it.

Check out BookGlutton’s new Facebook app! We know there are a lot of ways to organize what you’re reading on Facebook. But how many ways are there to have a robot deliver vintage science-fiction first lines? Just one. BG’s app let’s you flip through a collection of space-related first lines and send them on to your friends.

Send someone a Futuristic First Line using BG’s Future First Lines. Vintage robot included. Find it on Facebook.

Mimicry is an accusation that’s freely bandied by print aficionados who feel that digital reading suffers from too many book-like interfaces. It’s an easy attack, and one without much tooth. For what is anything on the screen but mimicry? And for that matter, how is a printed page not a form of mimicry as well? By the same logic, one would have to argue, for example, that photographs are inherently superior to illustrations.

It would be a big mistake to think that all the lessons we’ve learned in the evolution of the printed book will apply to digital transformations. But it would also be a mistake to throw them out. Let’s run through some of the big ideas in book technology over the last several hundred years:

  • Binding. Wonderful concept, and pretty hard to beat when it’s done properly. But our classics, cultural landmarks and histories are worth preserving for much longer than the life of paper and glue allow. So binding needs to be virtualized into a standard container format. Unless, of course, publishers are busily co-opting new indestructible materials with which to bind their books . . .
  • Scrolling. Scrolls were a nice way to contain text: portable, extremely lightweight, self-protecting. However, pages have proved themselves. The kind of scrolling we’ve gotten used to in computer interfaces was a compromise from the very beginning. It’s not the best way to read.
  • Typography. If there is any aspect of printed books which truly needs to be imported wholesale into our aesthetic and functional notions of digital books, it’s the art of typography. Why shouldn’t a digital book do it’s best to¬† imitate the best of print design? Kerning, leading, ligatures, orphan control, and other complex details of presentation need to be smoothly integrated with the searchable, reflowable texts that screen interfaces offer.
  • Footnotes. These have been black sheep ever since they were birthed by academic fervor. Putting them inline in text destroys flow, marginizing them fouls necessary breathing room, putting them at the end of a section is incredibly inconvenient, and efforts to place them in footers fall apart when text is reflowable. If anything can be thrown out, it’s preconceived notions about footnotes. There are myriad ways to handle them in digital texts, and almost all of them are better than print.
  • Covers. Who hates covers? No one. But no one’s figured out how they fit into digital texts. The physical requirements no longer exist, the pragmatic needs are addressed by metadata, and the marketing aspect just doesn’t quite translate (full bleed four-color process reduced to a jpeg thumbnail?)
  • Spines. Really, historically speaking, just the inferior alternative to covers, designed specifically for physical constraints which don’t exist on the computer. Sorry, Shelfari, spines are one of the first casualties of digital transformations, and rightly so. No need for any more bookshelf metaphors.
  • Table of contents. Doesn’t need to appear as a page in the book anymore. Bad imitation would reproduce it there, as many Gutenberg titles do. The table of contents is a form of navigation, and thus is metadata. This is not to say it can’t be nicely presented, just that it’s less essential to what a book is than we previously thought.
  • Indexes and glossaries. What a wonderful invention, eh? Wouldn’t it be nice to jump to a spot in the book where a topic appears? Or flip to a section that defines key terms? Unfortunately, these are two concepts that are ready to seriously evolve, and no one should consider borrowing them as is. Hyperlinks, search, crowdsourcing, shared notes, author commentary, call the future of this what you will, it is, again, about metadata. Going forward, the accusation of outright mimicry will be reversed: this time leveled at print for trying to imitate what computers already do so well.
  • Double-sided pages. Nice to trees, very economical, and reduces page turns. Dependent on physical rotation of the book object, or a good solid wood table at the proper height. Not necessary on a screen.
  • Facing pages. Pages don’t read each other, unfortunately. A page ideally should always face the reader. Also, we only read one at a time. That said, while it will one day seem archaic to be holding a portion of unread pages in one hand and a portion of read pages in the other, the tactile feedback of the fatness of either portion must be respected in some digital equivalent. At BookGlutton, we have a fat little progress bar underneath the text. It’s fun in a tactile way to scrub along it, like feeling the edges of the pages you’ve been to, or the pages you’ve yet to discover. The filled portion increases as you fill yourself up with the book. Tasty.
  • Margins. Though they’ve seen some shrinkage, it’s not because they’re less necessary. Space around text makes it easier to read. Many screens seem to ignore this, and they shouldn’t. Here at BG, we’d like to see margins get bigger than they are in most printed books.

Imitation is the sincerest form of flattery. And believe it or not, most people who contemplate reading on the screen want the screen to be somewhat like a book.

That said, let’s definitely have less page-flip effects and jpeg-wood bookshelves.

Editor’s Note: for those readers who can’t suffer jargon, please skip this post. For those who thrive on it, read ahead. We welcome your feedback.

Uncertain DRM is one of the most-cited flaws of the .epub specifications, but it seems like more of a business problem than a technical one. The real technical challenge with using the proposed standards comes from a lack of direction on how exactly we’re supposed to link between books, within books, or within fragments of books. We’re calling this Deep-Linking.

What is clear is that we can use IRIs (Internationalized Resource Identifiers) to link to an OPS structure, specify a path into it and identify a fragment with an ID. That’s great, but I wouldn’t consider it Deep-Linking. The W3C DOM gives us Range specification, Node collections, XPath, CSS selectors and Xpointer. Sounds like plenty of tools. So why not specify one or two in the recommendations?

Relying on unique IDs to point into documents may be the best way to create bookmarks that can reliably return us to the beginning of a chapter, or, say, the third paragraph of that chapter. They work fine if each annotation is associated with an entire paragraph or element, nothing more, nothing less. But if we want a user to be able to specify a sentence, a passage or a word, or a collection of paragraphs, we need something better. And what about specifying a collection of non-sequential paragraphs, such as the first paragraph of each chapter, or the first sentence of each of those paragraphs?

There is no firm imperative or recommendation on one method or another. No URI scheme is mentioned either. A URI scheme would allow deep linking via an epub:// link, a link which actually points to a location inside of a zipped file heirarchy.

The OpenReader Binder spec addresses this issue, the OEBPS does not (thanks, Jon!). OpenReader recommends using IRIs too, and doesn’t end up getting us too much deeper link-wise, but at least it takes a stance.

A URI scheme raises another question: would it be better practice to link through the NCX, or directly into the file structure? Direct URLs are certainly more open and Webby. But linking through the NCX allows a certain measure of content control (more appealing to the DRM crowd, and probably also to e-book authors). For example, the NCX or, more likely, the OPF file could specify rights and/or codec information, but only for the parts to be made openly accessible. Eg:




The thought has obviously occurred to Microsoft, who’s either trying to patent it, or just protecting alternatives to Sun’s Java API. The jar:// scheme that Sun came up with for linking into zip files is used by Firefox quite extensively, though it’s not an IETF standard. A jar-style URL for epubs would look like this (substituting ‘epub’ for ‘jar’ in the scheme identifier):


There is also a scheme for including data directly in a browser. The latest crop of browsers (IE8, Safari 3, Opera, Mozilla) all support it. The problem with it would be the length of the URIs needed to load an entire book. However, a variant of the epub spec could allow data:// URIs in the content.opf, which would allow it to be loaded and parsed by a browser, images and all.

For example, we’d all like to link to parts of a package with something like this:

Perhaps there’s room for several methods of linking. After all, if we’re going to have both .epubs and OPS structures out there, we’ll need alternatives. We’re leaning toward the open, http-based options. Feel free to disagree. Dialog helps.

BookGlutton Cover Page

We thought we’d add a little color and flair to the opening pages of BookGlutton books, so look for this stylish new cover page design in all forthcoming catalog imports. And remember, you can always find out what’s new in the catalog by clicking the Catalog Feed link at the top of any page. We’ve been importing Irish authors as of late, in deference to St. Patty’s Day. Why not read some Joyce or Yeats?

BookGlutton’s Reader: Shared Annotations

Your laptop is in color, so why shouldn’t we be? You probably know we’ve upgraded the Reader to handle images and started importing image-packed books. They’re a mixture of color and black-and-white, depending on the source material. Here’s an example of a children’s story by Charles Dickens.