platypope.org / blog / syndicate

Confuse the customer... and win?

2010-02-04T13:52:15-05:00

With Amazon.com not selling Macmillian books at the moment, now might seem like a good time to go to the source and buy ebooks directly from Macmillian. And they even have multiple formats available!: the "Adobe Digital Edition" format and the "Adobe eReader" format.

Wait, what?

According to their Ebooks information and help page, "Adobe eReader" books enable you "to read high-fidelity ebooks alongside other PDF files. Only this reader software displays ebooks with the pictures, graphics, and rich fonts you've come to expect from printed books." While "Adobe Digital Editions" is "Adobe's reader designed for eBooks" and "uses a format based on the Open Publishing Standard with the extension .epub," but "ADE will also display your PDF files in a double-page, single page, or fit-to-width view — or you can specify your own custom fit." Both formats have software download links, which both redirect to Adobe's current Digital Editions page.

So. Er. I think "Adobe eReader" is PDF and "Adobe Digital Editions" is EPUB. Format proliferation is bad enough without making format identification more difficult than necessary.

Creative Reformation

2010-02-03T21:47:19-05:00

Faruk Ates responds to Mark Pilgrim's Tinker's Sunset by trivializing tinkering and claiming that the ease-to-use devices like the iPad are fostering a Creative Revolution:

The simple matter is that these guys are old, and they grew up in an age where tinkering was the only possible course of action if you wanted to use the latest and greatest technology to its fullest potential. The Mac, in 1984, shifted that paradigm of creativity and creation towards average consumers a little. The iPhone and iPad are shifting it even further towards consumers, away from the tinkerers of old, the small little "elite" that excludes the vast majority of people.

He may be right about fostering creativity, but he's missing the point. Making the iPad accessible to non-tinkers and making it untinkerable are completely orthogonal.

Imagine that the iPad worked exacly as Apple has already presented, but it also had a "tinker" switch. When on, this switch allowed users to run applications not signed by Apple, with appropriately dire warnings. Problem solved, without impacting typical user experience.

"Tinkering" is easy to trivialize, but doing so ignores what its prevention represents technically. What we're talking about on the iPad is an impenetrable cryptographic shield which gives Apple absolute control over what code is allowed to run. Apple, not users, determines what applications are appropriate. Apple is free to censor not only content which fails to meet their technical standards, but also content which conflicts with their business interests or they deem to be "obscene." No matter how light the shackles, on the iPad (and iPhone) you are not free.

On the flip side, like Pilgrim I do see "tinkering" as valuable in itself. Software stacks more than any other engineered systems are inherently knowable, and one can learn from them. Fully free systems (in Stallman's sense) are the most knowable and most instructive by virtue of the source code for every component being there for the asking. With a cryptographically shielded platform like the iPad this is impossible, and the system is unknowable and there is nothing to be learned even for the "elite."

The vicious cycle of piracy?

2010-02-03T21:23:28-05:00

A few years ago I discovered that Wizards of the Coast had started selling PDF versions of pretty much the entire catalog of TSR-published original D&D, AD&D, and AD&D 2nd Ed material, all at quite reasonable prices. I've been fond of the Planescape setting ever since I was first introduced to it, and I impulsively bought the majority of the AD&D 2nd Ed Planescape manuals. You known, in case I ever get suddenly transported back to the 90's or something. I later lost those precious, fully-paid-for bits in a hard drive crash, and didn't bother redownloading them again because of reasons which seemed reasonable at the time. I mean, the vendor I bought them from will surely let them download them again whenever I decide to. What could possibly go wrong?

Fast forward to the present. Finally setting up a reasonable backup scheme jogged my memory of previously lost bits, and I decided to try downloading new copies of those RPG manuals. And... the vendor still exists... I'm able to log in... they have my complete order history... they have download links!... and — no. Apparently WotC pulled the plug, stopping all e-book sale of their both current and out-of-print material, including re-downloads of already-sold titles.

Of course, a quick search turned up Rapidshare-hosted copies of all the books I'd purchased, which I felt no scruples about downloading. But chicken or egg — are the books so easily available because WotC removed them from legitimate channels? Or was the pull in the first place a response to widespread piracy? Either way, I don't see how WotC is benefiting.

Solving puzzles with (computer) science

2010-01-07T14:01:02-05:00

For Christmas my girlfriend gave me a series of increasingly difficult wooden-block puzzles, yielding up each one only as I solved the previous. She'd show me the assembled puzzle — to mock me, I assume — then dump it disassembled into my lap1. The first one was a quickly-solved freebie, but the remaining three were pretty difficult. Difficult enough even that I decided to let computers do the boring work and wrote programs to solve them. Ah, the joys of being a software engineer!

And if you think this is "cheating," I feel the final results from my "bonus round" (at the end of this post) validate the approach.

Round 1 was the King Snake. This puzzle is a 4x4x4 cube composed of 64 linearly connected unit-cubes. The strand of unit-cubes is divided into 46 segments of 2-4 cubes each. Each segment shares a joint cube with its previous segment and freely rotates to form any right angle with that segment. A naive estimation of the problem space is greater than 1e27 (4 right-angles to the power of 46 segments). However, most moves eliminate 25-75% of the remaining problem space by either running into already-filled space or leaving the allowed 4x4x4 grid. Counting on the constraints quickly reducing the problem space, I initially solved this one with a pretty naive depth-first search written in Python.

The Python program took about 5 hours to run, and was designed to find only one solution. But hey! — it worked and found a solution. I later revisited this puzzle with what I learned from solving the others, but I'll get to that at the end.

Round 2 was the Shipper's Dilemma Z. This puzzle is a 5x5x5 cube composed of 25 identical, 5-unit-cube, vaguely Z-shaped pieces. For this one I did some research, hoping something about tessellation would help. Alas, even though the pieces are all identical, it appears that this is still an (NP-complete) packing problem. There are 960 positions a piece could occupy within the space, which for 25 pieces yields a naive complexity estimate of greater than 1e492. Ouch. It seemed much less likely in this case that the basic problem constraints would help much, as a naive depth-first search would prune only a few possibilities with each move. I wrote a simple first-try in Python anyway. It got absolutely nowhere, which led me to decide to try something different, something "clever." And thus down a rabbit-hole I went.

I'll leave out most of the details, but I wasted a lot of holiday time trying to solve this puzzle with something akin to dynamic programming. I'd build groups of 3 pieces "attached" to a vertex, combine those into groups of 6 pieces attached to a quadrant, combine those into group of 12 attached to a side, then combine those into groups of 24 which (for solutions) would (theoretically) form the full cube with one piece-shaped hole somewhere in the middle. It was a terrible, terrible idea. The computational complexity of each step varied wildly as I changed my methods for forming groups and what assumptions I made about the properties of solution-participating groups. At one point the execution-time was lagging just enough that I re-wrote the solution-grinding code in C. Later the complexity was just where it wasn't feasible to run at home, but I could run it on Amazon's Elastic MapReduce. I did learn how to use Hadoop, EC2, and EMR, but — long story short — none of it yielded a solution. I eventually climbed out of the rabbit-hole and went back to a depth-first search, but this time with a much better conceptualization of the problem.

Fast C primitives help3, but the only real way to solve a problem of this sort is by exponentially reducing the search space. The first step is to avoid working on any "unsolvable" states. Many patterns of piece-placement leave gaps which no subsequent piece can fill. I test for this by filling in a copy of the board state with all the pieces which could fit, even if those pieces themselves overlap. If the cube isn't completely filled, then the initial board state cannot lead to a solution.

Another obvious step for any sort of space-pattern problem is to eliminate all rotations and reflections which result in other states in the same symmetry group. For a cubical puzzle like this one, eliminating symmetries reduces the state-space by a factor of 48. In this case, I did so by initially calculating all symmetrically unique states which have 8 pieces placed, one in each corner. This also has the nice side-effect of splitting the search-space into parallelizable segments, although that turned out to be unnecessary.

The final step necessary to explore all the "interesting" states in a reasonable amount of time is to eliminate the exploration of duplicate states. Just naively iterating over piece combinations will result in trying both piece A then B and piece B then A, even though they result in exploring the same board states. I iterated over a couple approaches to this, but eventually hit upon simply ensuring that each position in the puzzle is filled in a fixed sequence. This minimizes the number of options available for each placement and doesn't require any explicit book-keeping to short-circuit previously-explored board states.

Final running-time: 2.5 minutes to generate all four solutions.

Round 3 was the RAMU OCTAHEDRON 4. This one is kind of a irregular decahedron5 represented as a 5x5x5 cube with the 4 unit-cubes at each vertex removed. It splits into 8 very irregularly-shaped pieces. There are also two small wooden spheres which occupy unfilled space within the cube and "lock" it by preventing motion of the "key" piece unless the spheres are shifted into particular positions. The site calls the Ramu Octahedron their "most difficult puzzle" and claims that only one person has solved it without reference to the solution. The difficulties of this puzzle are three-fold: the irregularity of the pieces makes conceptualizing their spatial placement difficult; many of the pieces can only be placed by combinations of separate "insertion" then "locking" motions; and once the puzzle is assembled, one must determine how to maneuver the spheres within the unfilled internal space to allow re-disassembly.

Fortunately the piece-irregularity holds little difficulty for a computer. After laboriously entering the shapes of each piece, I was able to re-use code I'd written for the previous puzzle to generate all the interesting piece rotations and translations6 and their various combinations. Once that gave me the solution spatial arrangement, it required a bit of trial-and-error to figure out a working piece order and insert/lock sequences, but I was able to manage it by hand. Figuring out the necessary unlocking rotations was also easy enough, at least after I added a map of the unfilled internal space to the solution.

Final running-time: 1 second to generate the single solution.

Bonus round, back to the King Snake. I decided to come back to this puzzle with what I'd learned from solving the others and try to generate all its solutions in a reasonable amount of time. I didn't have any new ideas about how to frame the puzzle, but I did have some new implementation tools: pre-generating and indexing by position all legal piece arrangements, and representing puzzle states as bit-fields. These two together allow for a blazing-fast solution.

Final running-time: 30 seconds to generate all four solutions 7.

If you own this puzzle, you may at this point be thinking "Wait, what?" The marketing copy and provided instructions for the King Snake claim there are only two solutions. But nope, four. The two extras solutions are very similar to each other, but are quite distinct from the two "official" solutions, and none are simply symmetries of the others.

"Cheating" — hah!

Puzzle-solving code available for your edification.

1 Best Christmas present ever, seriously.

2 For comparison, chess apparently has between 1e43 and 1e50 legal board states.

3 Most actions on a the puzzle-state are just a few bitwise operations.

4 Which I really like putting in all caps, for some reason.

5 Yeah, the name confuses me too.

6 But not reflections, what with three dimensional limitation and all.

7 FYI, I number from the opposite end than the provided solutions.

Language Implementation Patterns

2009-10-05T16:01:55-04:00

Possible lesson: don't get upset with a book for not being a completely different book the author hasn't written yet, but will later.

I few months ago I bought The Definitive ANTLR Reference by Terence Parr1. The book's subtitle is "Building Domain-Specific Languages," so I was rather disappointed when I found out that it has absolutely no information on building domain-specific languages — or any other applications — using ANTLR. It's a great ANTLR reference, but doesn't have any examples of using ANTLR to do anything other than just parse (and emit and handle parsing errors). Without any practical examples, it took bit of head-scratching on my part to realize how to even e.g. make my Z-code assembler available to my ANTLR-generate AST walker.

But today I learned that Terence Parr has also written another book titled Language Implementation Patterns. I haven't had a chance to read much of it yet, but it looks like exactly what I wanted in the first place — a guide to actually writing various sorts of applications which involve parsing languages, mostly using ANTLR-generated parsers. This book has the oddly-similar subtitle "Create Your Own Domain-Specific and General Programming Languages," but which seems rather more apt here. In any case, I'm looking forward to it.

And on a side note, Parr's publisher, the Pragmatic Bookshelf, kicks ass. Their e-book deployment is even better than O'Reilly's. While both provide PDF, Mobipocket, and EPUB versions for perpetual re-download, the PragProgs also (a) offer almost their entire catalog as e-books, and (b) make e-book editions available as "beta books" several months prior to the print release date. In fact, Language Implementation Patterns is currently only available in an e-book beta version. But available it is, for delicious pre-final-draft reading by the adventurous.

1 Primary author of ANTLR, so you can see the draw.

Testing

2009-10-01T08:35:35-04:00

I have to admit there are times when running Debian testing bites me. Like today, when I had to reboot my computer, and when it comes back up, all my X keycodes had changed — scrambling my custom key mappings across random other keys — and tapping on my touchpad no longer worked1. Le sigh.

Update: Ah, and now it works, via TapButton1. Just not when I set it in my xorg.conf, only by synclient. So now I just need to never reboot again.

1 TapButton1 had become "0". I reset it to "1", but that doesn't seem to have improved matters. At least I have buttons I can click in the meantime.

ZmForth!

2009-09-29T08:31:30-04:00

Some time ago I decide to fix one of the holes in my software engineering knowledge and learn about writing compilers. My undergraduate curriculum provided an overview of parsing and some general programming language design issues, but nothing at all on code generation or optimization. I bought a few books on compilers, started familiarizing myself with ANTLR, then became completely and utterly side-tracked by the programming language Forth.

Forth is a strange little language. Chance are that unless you're an astronomer or have mucked around with Sun's OpenBoot, you've never even heard of it; or if you have heard of it, you've never used it. Forth saw its heyday during the 80's and has largely faded away with the 8- and 16-bit processors to which it was most suited. But boy was it suited to those processors — if I ever needed to develop code to run on a 16-bit processor with less than 128k of RAM, Forth is probably the language I'd turn to.

Forth's key property is that it's a purely stack-based language. Forth functions — or "words," as Forth calls them — do not take arguments explicitly, but instead implicitly via a system-wide parameter stack. There aren't any local variables — instead the language provides a rich set of stack-manipulation primitives like DUP1, SWAP2, and ROT3 to facilitate juggling the top handful of stack items to provide the correct parameters to each function call. Even control structures are implemented with Forth-level function calls!4 This means that a Forth program consists of nothing more than a list of functions to call in sequence, a feature which the language exploits in two ways.

First, to simplify syntax. Just as a Forth program abstractly consists of nothing more than a list of function "words," the source code of a Forth program consists of just lists of those words' human-readable names separated by spaces. Adding the ability to switch the Forth system between executing each word as parsed and appending it into a new definition allows the system to act as both interpreter and compiler in one. That's a full interactive interpreter and compiler in under 8k.

Second, to simplify implementation. There are "traditional" optimizing compilers for Forth, but that isn't the most common or most obvious approach to Forth compilation, especially in-target. More frequently, Forth systems will use an approach known as "threaded code." This has nothing to do with multithreaded execution, but instead refers to the technique of generating code which consists of only of calls to other functions. The more specific techniques of so-called "direct" and "indirect" threaded code drop even the calls themselves5 and instead encode only the function addresses. A list of address can't be executed directly, so this necessitates an "inner interpreter" to load and call each in sequence, but this interpreter need only be a few machine instructions long, and on some architectures imposes no additional overhead over directly-expressed function calls. In a Forth system using this approach, compiling a function call into a new definition literally consists of just appending the address of the function to call to the end of the definition in progress. It just can't get any simpler than that.

And because it's all so simple, you can implement it yourself! Or rather, I can lose the thin thread of sanity and decide to implement one myself. There are existing F/OSS Forth systems out there for pretty much every environment under the sun, which provide plenty of examples to turn to for inspiration, but also mean that the whole Forth thing is pretty well done. This needn't be a hindrance to implementation-as-a-learning-exercise, but I wanted to contribute something new. I happened to think of the Z-machine, and lo-and-behold, although there is a Z-machine scheme implementation, there was no Z-machine Forth.

Until now! Ladies and gentlemen, I present to you ZmForth!, an ANS Forth implementation for the Z-machine. It passes the woefully incomplete ANS Forth test suite I found and runs existing Forth programs that don't depend on file I/O. It plays Tetris, performs 32-bit arithmetic and unsigned comparisons, and provides exceptions, a compiler, and a de-compiler. All of this in a 16-bit virtual machine with only 64k of addressable memory. The whole project was one giant rabbit hole, but I had to write my own Z-code assembler to provide the directives I wanted, which is at least in the direction of what I initially planned to work on.

I had a good time working it, and I hope someone else may be at least half as entertained by it as I was.

1 Duplicate the stop stack item.

2 Swap the top two stack items.

3 Rotate the third stack item to the top.

4 In fact, in my system all the control structures are implemented in Forth.

5 The call instructions, that is.

An example of why Ruby is no longer my LoC

2009-07-10T18:41:22-04:00

The Numeric#zero? method returns true if the number is 0 and false if it is not. The Numeric#nonzero? method returns nil if the number is 0 and the number itself if it is not.

Creator vs. reader and the Adobe EPUB monopoly

2009-07-02T14:32:50-04:00

I've been doing a fair bit more reading on my Android phone, although recently I've switched from FBReaderJ to Aldiko. Each new release of FBReaderJ has gotten better, but Aldiko includes an actual CSS-based renderer1 and presently provides a much smoother reading experience2. I feel a little guilty using a piece of commercial software when a free-as-in-freedom solution exists, but not yet guilty enough to try hacking on FBReaderJ.

Guilt aside, reading more on a smaller screen has had me thinking again about the tension between book creator and reader in e-book formatting and layout. EPUB on the mobile phone highlights this tension more than e-ink devices if for no other reason than that a phone screen even less resembles a book page than an e-ink screen does. One conclusion I've come to is that it's somewhat unfortunate that Adobe has thus far been the biggest contributor to EPUB as a commercial e-book format.

On the one hand, someone had to do it, and it's good that someone has done it. Even the DRM thing, to some degree — most publishers aren't ready to do without it, and at least Adobe had the good grace to use an easily circumventable system. The major concern I have is with some aspects of the apparent mindset behind Adobe Digital Editions.

At present, Digital Editions is the EPUB viewer to beat — I have no idea what the actual usage figures look like, but it's the only viewer one can legally use for all those commercially-sold Adobe-DRMed EPUB books, so one has to imagine that DE commands the lion's share of the market. Adobe represents Digital Editions as being more than just an EPUB viewer. The advertising copy on the DE web site touts it as "offer[ing] an engaging way to view and manage eBooks and other digital publications." To this end, DE supports not only EPUB, but also the document format much more central to Adobe's business — PDF. And because PDF is so much more important to Adobe, DE caters to PDF at the expense of EPUB.

It's no surprise to the average e-book enthusiast that PDF's fixed-page nature makes it a poor e-book format. The most obvious reason is that PDF files can't be cleanly reflowed to alternative page sizes. A perhaps less obvious corollary is that PDF leaves little room for user control of basic formatting parameters such as font size, line height, text alignment, and paragraph marking. But via one or more chains of causality, because PDF rendering does not allow user-control of these properties, Adobe DE doesn't allow setting them for EPUB either. This yields an EPUB viewer where the reader has control over only the font size and page size. And even then only partial control! — DE will not rescale any size a book specifies as an absolute size, and DE allows books to provide "page template" files which control how the available screen area is divided into text regions and body columns.

The most generous interpretation of this decision is interface consistency. As long as Adobe is attempting to present PDF as an e-book format and provide a viewer which handles "digital publications" regardless of format, it only complicates that viewer's interface to provide options which apply to some formats but not others. Somewhat less charitably, Adobe's focus on PDF may have led to an unconscious bias toward creator control of document formatting, to the extent of perhaps not even considering placing control beyond font size (a.k.a. "zoom") in the readers' hands. And way over on the conspiracy-theory side of the fence, perhaps it represents a conscious decision on the part of Adobe to limit the usefulness (and adoption) of EPUB by making it only a small improvement over PDF even for the documents most suited to reflowable formatting.

So for whatever reason, the most popular EPUB viewer on the market has limitations which severely restrict the usefulness of the format. But EPUB is an open standard, which means other, better viewers are free to compete with Digital Editions and supplant it, right? Except they aren't really, because of DRM.

As I mentioned above, it seems that most publishers are not yet ready to do without DRM, despite the lesson of the music industry. The overwhelming majority of commercially-sold books are encumbered with DRM, and all of the DRM-encumbered EPUB books sold use Adobe's ADEPT DRM. It would be technically possible for a competitor to begin offering a different EPUB DRM scheme, but I can only imagine the degree of confusion mutually incompatible "EPUB" books would cause among average consumers. So any successful EPUB viewer device or application needs to license the ADEPT DRM technology from Adobe.

To facilitate this, Adobe has begun offering the "Adobe Reader Mobile 9 SDK." The SDK is available by license agreement only4, so we can but speculate from the marketing copy on the capabilities and interfaces it provides. The "features" list in the SDK FAQ focuses entirely on features of the "Reader Mobile document rendering engine," suggesting that SDK primarily/only provides a rendering engine. If this is the case, then Adobe is not expecting — or potentially allowing — other vendors to write competing ADEPT-compatible EPUB renderers. Instead, all the available and announced EPUB reader apps/devices using the Adobe SDK5 will simply repackage the Adobe renderer and the paucity of options for user control it provides.

One example in support of this theory is Amazon's PDF support in the Kindle DX. Although not widely advertised, Amazon is apparently using the Adobe SDK, just integrating only the PDF renderer. Notably missing in the DX's PDF support vs. all the Kindles' Mobipocket support is the ability to add annotations to documents. It seems to me that this would be a "must have" feature, not only for parity with Mobipocket support, but also for the target market as a device for textbooks and technical documents. To me the most obvious explanation for this feature's lack is that there isn't an easy way to add it while still using the SDK to allow rendering of DRMed PDFs. There are plenty F/OSS PDF renderers to which Amazon could have (comparatively) easily added annotation support, which suggests that the Adobe SDK's DRM support is an implicit part of the included renderer, and that SDK licensees cannot use the SDK to read DRMed documents independently of the renderer.

Another interesting angle is to compare the Adobe approach with how other book formats/viewers handle the creator-reader tension.

The desktop version of MSReader allows setting only the font size, but a significant number of users seem to regard it as still the best desktop e-book viewer available. A major component of this seems to be very well-chosen defaults for properties like line-height, and the infrequency with which books alter those properties. I have seen much more mixed reactions to the Mobile version, perhaps because on the smaller screens of mobile devices tuning the line-height, margins, etc to an individually comfortable size is much more important. Perhaps a commenter could fill me in?

The various Mobipocket viewers support differing assortments of user-controlled properties. Most support setting font-size, line-height, and paragraph alignment. Interestingly, Mobipocket's treatment of these properties demonstrates all three possible resolutions of the creator-reader formatting tension. Line-height may be set by the reader, but not by the book creator — the format simply provides no way to specify it. The font-size may be set by the book creator, but only in terms of a size relative to the reader-selected base size. And paragraph alignment may be specified by either the book creator or reader, but the creator's setting overrides the reader's when specified.

Correspondingly, paragraph alignment is the subject of one of Mobipocket's most forceful formatting recommendations: "alignment must NOT be set if it is not strictly needed." In contrast, the EPUB specification documents contain little resembling formatting guidelines (beyond an admonition against using absolute positioning). The one purely formatting recommendation in Adobe's "EPUB Best Practices Guide" is "use spacing that looks more like a book," suggesting including CSS rules to eliminate default space around block-level elements. It does contain some sensible recommendations e.g. against using
tags in most contexts, but otherwise the "Guide" documents Adobe's EPUB extensions and DE's quirks more than actual "best practices." Which means that EPUB combines the most extensive e-book formatting capabilities with the fewest guidelines for producing actually readable books. And this is something of a challenge for authors of EPUB viewers.

Coming full circle to the beginning of this post, the Aldiko EPUB viewer does allow the user to set some basic formatting properties, including margins, font, font-size, and line-height6. The first three work seamlessly, but line-height somewhat less so. Aldiko handles books which don't specify their own line-height fine, but any book-specified line-height "wins." Which isn't intended as a slight on Aldiko — this is a difficult problem to solve.

Something like page margin can really only be set via CSS in one "most sensible" way7, and thus is easy to override coherently and consistently in a viewer. Font-size is potentially trickier, but the most obvious ways of specifying font sizes (relative sizes and the CSS named absolute sizes) make a simple solution fairly straightforward. Properties like 'line-height' unfortunately lack such a solution — all the allowed relative values for the CSS 'line-height' property are interpreted as relative to the 'font-size', not the 'line-height' of the parent element. This means that the font-size solution of "change the base and respect subsequent relative changes" doesn't work for line-height. Without doing some sort of layout analysis, all a viewer can do is either ignore all book-specified line-heights or respect all book-specified line heights.

Solution? I'm not sure. One possible solution would be for book producers and viewer author to agree on guidelines which allow viewers to consistently override some set of formatting properties. Most of these could be fairly simple, like Mobipocket's "alignment must not be set" rule. Another solution would be for e-book reader apps to do some sort of pre-rendering layout analysis which allows them to produce automatically produce a per-book user stylesheet. I like hands-off technological solutions, but I'm not sure how feasible that will be on mobile devices.

Other ideas?

1 To my surprise, a good enough one to handle the 'max-width' property on images.

2 Quite literally, in the case of the page-turn animation.

4 Probably to stop people from reverse-engineering the DRM system.

5 The ones I'm currently aware of: the Sony Reader, Lexcycle Stanza, the Bookeen Cybook, and the Elonex ebook.

6 Not paragraph alignment yet, but via e-mail the author has said it'll probably be added soon.

7 One could set left and right margins on every block level element, but hopefully no one actually does that.

Thoughtcrime Experiments EPUB edition

2009-05-01T00:53:14-04:00

This past weekend Leonard Richardson (of BeautifulSoup fame) and Sumana Harihareswara released Thoughtcrime Experiments, a 100% independent, CC BY-NC-SA 3.0 licensed F/SF anthology. It's pretty rockin', in both concept and execution.

Ararche Jerico beat me to it by a couple days with his e-book editions of Thoughtcrime Experiments, but what I lack in speed, I make up in obsessive-compulsive attention to trivial details. Thus I present to you the Thoughtcrime Experiments EPUB pedant edition. To what sorts of trivial details does this edition attend? Glad you asked!:

Book-optimized stylesheet. I created a new stylesheet for the book from scratch, roughly following the design of the Thoughtcrime Experiments PDF/print edition. Beyond just looking more "book-like" (paragraphs marked by indentation rather than vertical whitespace, etc), I've also ensured that all body text maintains vertical rhythm, lines appearing at the same positions even following headings, breaks, and so on.
High-quality art. Includes higher-quality version of the artwork than used for the Web edition, providing some degree of future-proofing for larger e-book reading displays. I've also taken pains to display the art nicely, despite the best efforts of the CSS standard to the contrary.
A beautiful, fully-scalable SVG cover. Ok, the SVG cover actually looks like crap / doesn't display at all in everything but AdobeDE. But it looks quite nice there, thank you very much.
Hand-corrected HTML->XHTML conversion. The source HTML had a handful of missing-tag etc. issues. I individually validated each file and hand-corrected it, ensuring perfect markup.
Fully normalized punctuation. The source HTML contained some variation in punctuation conventions and handful of punctuation errors (a missing opening quotation mark, two hyphens instead of an emdash, etc). I've corrected the errors and normalized to a single set of conventions.
Squeaky-clean metadata. Not only passes epubcheck 1, but does so with panache! Includes all required metadata, identifies each contributor with a separate metadata entry, and includes a metadata table of contents which mimics the structure of the PDF/print edition TOC.
Embeds a font. This is a bit of a pet peeve of mine, but the OPS spec doesn't actually require that EPUB reader systems provide a default set of glyphs for any particular set of Unicode characters in any particular typeface. This means that embedding a font is the only option if you want to be certain all the characters in your book will display properly. I chose TeX Gyre Pagella because it's (a) free-as-in-freedom and (b) looks nice and sassy2 at 10 points.

Enjoy!

1 Actually not completely true at the time of writing, due to what appears to be a bug in NCX validation.

2 By which I mean "legible."