I'd purchased an eBook and was appalled by how crappy the accessibility was. If you don't know, modern ePub books are just HTML wrapped in a zip file. They have all of the accessibility advantages of the web and should be easy to read no matter if you're sighted or not.

But not this eBook! Part of the story concerned WhatsApp messages sent by the protagonist. Here's one of them:

See that smudge in the middle? The one smaller than a full stop? That's meant to be an emoji. Rather than use an actual emoji, they've stuck in a tiny pixel image which won't scale with text size.

Here is is:

Can't see it? Let me blow it up to a more readable size.

OK, that's annoying for sighted readers, but just about understandable. What about people who are using a screen reader? Luckily, ePubs can use HTML's "alt text" feature which will describe an image which can't be seen.

Curses! That's, perhaps, not too annoying for a decorative image - but later in the book there are pictures of a ransom note. Despite the plot-twisting text in the illustration, the alt text just says "image".

I found the publisher's website and scoffed at their proclaimed accessibility statement. I sent them an email which basically consisted of the above. I realised it was probably futile, but I've got to spend my privilege points somehow.

The next day, they wrote back!

I wanted to reply to let you know we are taking our commitments to accessibility in our ebooks seriously […] I will get our ebook team to check this as a matter of urgency and get back to you with an update.

Fair play. But talk is cheap, would they actually take action? A few days later, they sent a follow-up:

We have checked the file for this title again and found issues with it. We have sent this back to the conversion house to have the file corrected and expect this to be delivered by the end of the week. We would then expect this corrected version to be with Kobo by the end of the following week, i.e. 25th July.

We have also been spot-checking other files to see if there is a wider issue and where necessary will follow the same workflow to ensure fully accessible versions are available as widely as possible.

And, you know what, I think that's totally reasonable. Yeah, they should have caught it before publication - but it is a complex book and they're a small publisher. They took my complaint seriously and actually did something about it.

A week or so rolled by and they sent me this:

Just to update you that we have been back and forth with the conversion house getting this title up to scratch. There were various complicating factors which should now be resolved and an updated file has now been distributed and should be available through your chosen retailer presently. If you have any other queries please do let us know.

I logged on to my eBook provider, clicked "read" and…

It was fixed! All the images had decent alt text as well.

Rather annoyingly, the retailer didn't notify me that there was an update available. I can't blame the publisher for that though.

Still, 3 weeks from report to fix is pretty good I reckon.

When I last contacted a publisher about a mistake in their ebook, it took over 3 months to fix it. Perhaps things are slowly getting better?

Anyway, please complain about poor accessibility. Don't shout into the void of social media - write a polite but insistent email telling (not asking) people to fix their shit. Sometimes, just sometimes, it does work.

Anyway you should read The Mysterious Case of the Alperton Angels by Janice Hallett - it is brilliant and accessible.

At the risk of sounding like an utter corporate stooge, I think it is a relatively inoffensive and technically interesting DRM scheme. Primarily because, once you've downloaded your DRM-infected book, you don't need to rely on an online server to unlock it.

How does it work?

When you buy⁰ a book, your vendor sends you a .lcpl file. This is a plain JSON file which contains some licencing information and a link to download the ePub.

Here's a recent one of mine (truncated for legibility):

{
    "issued": "2025-03-04T12:34:56Z",
    "encryption": {
        "profile": "http://readium.org/lcp/profile-2.0",
        "content_key": {
            "algorithm": "http://www.w3.org/2001/04/xmlenc#aes256-cbc",
            "encrypted_value": "+v0+dDvngHcD...qTZgmdCHmgg=="
        },
        "user_key": {
            "algorithm": "http://www.w3.org/2001/04/xmlenc#sha256",
            "text_hint": "What is your username?",
            "key_check": "mAGgB...buDPQ=="
        }b
    },
    "links": [
        {
            "rel": "publication",
            "href": "https://example.com/96514dea-...-b26601238752",
            "type": "application/epub+zip",
            "title": "96514dea-...-b26601238752.epub",
            "length": 14364567,
            "hash": "be103c0e4d4de...fb3664ecb31be8"
        },
        {
            "rel": "status",
            "href": "https://example.com/api/v1/lcp/license/fdcddcc9-...-f73c9ddd9a9a/status",
            "type": "application/vnd.readium.license.status.v1.0+json"
        }
    ],
    "signature": {
        "certificate": "MIIDLTCC...0faaoCA==",
        "value": "ANQuF1FL.../KD3cMA5LE",
        "algorithm": "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"
    }
}

Here's how the DRM works.

1. Your client downloads the ePub from the links section.
2. An ePub is just a zip file full of HTML files, the client unzips it.
   • The metadata and cover image are not encrypted - so you can always see the title and cover. All the rest - HMTL, images, fonts, etc - are encrypted with AES 256 CBC.
3. The .lcpl file is placed in the META-INF directory and renamed license.lcpl.
4. A new ePub is created by re-zipping the files together.

When your client opens the encrypted ePub, it asks you for a password. If you don't know it, you get the hint given in the LCPL file. In this case, it is my username for the service where I bought the book.

The password is used by Readium's super-secret BLOB to decrypt the file. You can then read the book.

But here's the nifty thing, the encrypted file is readable by any certified app. I used the LCPL to download the book in two different readers. I unzipped both of them and they were bit-for-bit identical. I copied the book from one reader to another, and it was read fine. I built my own by downloading the ePub and manually inserting the licence file - and it was able to be opened by both readers.

Apps and Certification

In order for this to work, the app needs to be certified and to include a binary BLOB which does all the decryption. Readium have a list of readers which are available, and there are plenty for all platforms.

On Linux, I tried Thorium and FBReader. Both were absolutely fine. For my eInk Android, I used FBReader Premium (available for free if you don't have Google Play installed). Again, it was a decent reading experience.

I took the file created by Thorium on Linux, copied it to Android, set the Android offline, typed in my password, and the book opened.

Open Source and DRM

To be fair to Readium, they publish a lot of Open Source code and the specification seems well documented.

But the proprietary BLOB used for the decryption is neither libre -

Thorium Reader supports LCP-protected publications via an additional software component which is not available in this open-source codebase

Nor gratis -

Our pricing is structured into tiers based on a company’s revenue

What's the worst that could happen with this DRM?

Ultimately, our fear of DRM comes down to someone else being able to control how, when, and even if we can read our purchased books. Could that happen here?

I'm going to go with a cautious maybe.

Positives

Once downloaded, the ePub is under your control. Back it up on a disk, store it in the cloud, memorise the bytes. It is yours and can't be forcibly deleted. You can even share it with a friend! But you'd have to tell them the book's password which would make it trivially linkable to you if it ever got shared widely.

At the moment, any LCP book reading app will open it. Even if your licence is somehow revoked, apps don't need to go online. So there is no checking for revocation.

ePub is an open standard made up of zipped HTML, CSS, images, and fonts. An unencrypted ePub should be readable far into the future. LCP is a (paid for) ISO Standard which is maintained by a foundation which is primarily run by an EU non-profit. So, hopefully, the DRM scheme will also be similarly long-lived.

Because the underlying book is an ePub, it should have the same accessibility features as a normal ePub. No restrictions on font-sizes, text-to-speech, or anything similar.

Privacy. The BLOB only checks with the issuer of the book whether the licence is valid. That's useful for library books where you are allowed to borrow the text for a specific time. If you bought books from a dozen sources, there's no central server which tracks what you're reading across all services.

Downsides

Will the proprietary BLOB work in the future? If it never gets ported to Android 2027 or TempleOS, will your books be rendered unreadable on your chosen platform?

The LCPL file contains dates and signatures related to the licence. Perhaps the BLOB is instructed to check the licence after a certain period of time. Will your books refuse to open if the BLOB hasn't gone online for a few years?

If you forget your password, you can't open the book. Thankfully, the LCPL does contain a "hint" section and a link back to the retailer. However, it's up to you to securely store your books' passwords.

The book seller knows what device you're reading on. When you load the LCPL file into a reader, the app downloads the ePub and sends some data back to the server. The URl is in the status section of the LCPL file. After opening the file on a few apps, mine looked like:

{
    "id": "fdcddcc9-...-f73c9ddd9a9a",
    "status": "active",
    "updated": {
        "license": "2025-03-04T12:34:56Z",
        "status": "2025-03-09T20:20:20Z"
    },
    "message": "The license is in active state",
    "links": [
        {
            "rel": "license",
            "href": "https://example.com/lcp/license/fdcddcc9-...-f73c9ddd9a9a",
            "type": "application/vnd.readium.lcp.license.v1.0+json"
        }
    ],
    "events": [
        {
            "name": "Thorium",
            "timestamp": "2025-03-04T15:49:37Z",
            "type": "register",
            "id": "7d248cae-...-c109b887b7dd"
        },
        {
            "name": "FBReader@framework",
            "timestamp": "2025-03-08T22:36:26Z",
            "type": "register",
            "id": "46838356-...-73132673"
        },
        {
            "name": "FBReader Premium@Boyue Likebook-K78W",
            "timestamp": "2025-03-09T14:54:26Z",
            "type": "register",
            "id": "e351...3b0a"
        }
    ]
}

So the book seller knows the apps I use and, potentially, some information about the platform they're running on. They also know when I downloaded the book. They may also know if I've lent a book to a friend.

It is trivial to bypass this just by downloading the ePub manually and inserting the LCPL file as above.

DRM Removal

As I've shown before, you can use OCR to rip an eBook. Take a bunch of screenshots, extract the text, done. OK, you might lose some of the semantics and footnotes, but I'm sure a bit of AI can solve that. The names of embedded fonts can easily be read from the ePub. But that's not quite the same as removing the DRM and getting the original ePub.

When the DeDRM project published a way to remove LCP 1.0, they were quickly hit with legal attacks. The project removed the code - although it is trivial to find on 3rd party sites. Any LCP DRM removal tool you can find at the moment is only likely to work on Basic Encryption Profile 1.0.

There are now multiple different encryption profiles:

In 2024, the EDRLab Encryption Profile 1.0 was superseded by 10 new profiles, numbered “2.0” to “2.9”. Every LCP license provider chooses one randomly and can easily change the profile.

If I'm reading the source code correctly¹, the user's password is SHA-256 hashed and then prefixed with a secret from the LCP code. That is used as the decryption key for AES-256-CBC.

I'm sure there's some digital trickery and obfuscation in there but, at some point, the encrypted ePub is decrypted on the user's machine. Maybe it is as simple as grabbing the binary and forcing it to spit out keys. Maybe it takes some dedicated poking about in memory to grab the decrypted HTML. Given that the key is based on a known password, perhaps it can be brute-forced?

I'll bet someone out there has a clever idea. After all, as was written by the prophets:

trying to make digital files uncopyable is like trying to make water not wet²

As a quick primer, modern computing gives us two main ways of displaying a letter with an accent. The first is simple - encode every single accented letter as a separate "pre-composed" character. So è (U+00E8), é (U+00E0), ê (U+00EA), and ë (U+00EB) are all stored as different codepoints.

But this seems a little inefficient and can make it hard to search through text for an exact lexical match.

So there is a second way to add accents. You take the base character - e (U+0065) - and then apply a separate "combining" accent character to it. For example the combining accent ◌́ (U+0301). That means you can add an accent to áńý ĺét́t́éŕ!́

Note, the accent ◌́ (U+0301) is separate from the character ´ (U+00B4). In fact, most accents have a pre-composed, combining, and separate form. This, understandably, causes much confusion!

Here's a good example. I was reading the excellent Fallen Idols, when I noticed this typesetting bug.

It's always hard to transliterate languages. The Victory Arch in Iraq is known as قوس النصر, and usually written in English as the "Swords of Qādisīyah".

Examining the HTML code in the eBook, it was obvious that the publishers had used a macron ¯ (U+00AF) rather than the combining version ◌̄ (U+0304).

I've reported it to the publisher. I've no idea if they'll fix it in a subsequent re-issue.

I was reading a fascinating eBook recently which was, sadly, designed to mimic a legacy / paper book. To the point where the authoring software had hard-coded in page numbers and forced them to be displayed.

Here's what it looked like:

There are two abominations here. There's no need to interrupt the reading experience by bisecting a page and displaying the page numbers. And there's no need to put footnotes at the actual foot of the artificial page.

The whole point of an eBook is to free the reader from the tyranny of the publisher's choices. If the reader wants to justify the text, change the font, hide all footnotes, or has strong opinions about widows and orphans - they can choose a reading experience which suits their needs.

Let's take a look at the code behind the page and how it should been written.

Page numbers

The HTML the book uses to show the page numbers is:

   ...
   <div class="page-break">end p.16</div>
   <div id="page_16"> </div>
</div>
<div class="page-bounds">
   <div id="acprof-0195171276-div1-8c">
      <div class="para">
         ...

The CSS is:

div.page-break {
    text-align: right;
    line-height: 1px;
    font-size: 10px;
    color: #aca368;
    border-bottom: 1px solid #706650;
    padding: 3px 4px 8px 0px;
    margin: 0px 2px 10px 0px;
}

So, what should it be? I've previously written about the support ePub has for page numbers. And the answer is well documented in the specification.

It's simply this:

<span epub:type="pagebreak" id="page_123_a" title="123" />

That inserts an invisible pagebreak. The reader can choose to render one page per physical screen. Or they can choose to display a page number. Or they can choose to ignore the suggestion.

HTML Footnotes

Here's the code as presented in the ePub:

   <div class="para">Not only was that result in disagreement with the other trials made by the committee but also it was the direct opposite of the observations by Adams and De Luc, </div>
</div>
<div class="footnote-inline">
   <div>15. See <span id="xref-acprof-0195171276-bibItem-84c"><a href="content9.html#acprof-0195171276-bibItem-84">De Luc 1772</a></span>, 1:219-221, §408.</div>
</div>
<div class="footnote-inline">
   <div>16. See ...</div>
</div>
<div class="page-break">end p.16</div>
...

There's no need to put footnotes alongside the text. If you do that, you're basically telling the reader that you know better than them how they want to read the book. Most eReaders will pop-up a footnote, making it easy to read and easy to close:

The footnote link should have a specific ePub type, and the footnote itself is semantically represented as an <aside> with it's own type:

<p>The use of dilithium crystals was discouraged<a epub:type="noteref" href="https://shkspr.mobi/blog/2023/04/stop-treating-ebooks-like-paper-books/#n1" id="fn1">1</a>.</p>

<aside epub:type="footnote" id="n1">
    <p><a epub:type="noteref" href="https://shkspr.mobi/blog/2023/04/stop-treating-ebooks-like-paper-books/#fn1">1.</a> Scott, M (2257).</p>
</aside>

The footnote text can be placed at the end of the chapter or the end of the book. No need to force it into the reader's eyeline.

There's also similar advice from Kindle.

What have we learned today

Books are magical. And, in my humble opinion, eBooks are better than legacy paper books. I can boost the font size of my eBook rather than having to buy an expensive large-print version. I can navigate by searching, or by semantic features, rather than grubbing around with page numbers. And I can choose to follow a footnote or ignore it as the whim strikes me.

But all that requires the publishers actually understanding how to take advantage of the format.

What we do have is a Blockbuster card and, between us, just enough cash to rent a newly released movie. Eight of us pile into the local Blockbuster and begin to scavenge the shelves. DVDs have yet to appear in our sleepy town, so we hold up chunky VHS boxes for appraisal.

"The English Patient?" "Rubbish."

"Trainspotting?" "Seen it."

"The Full Monty?" "My mum won't let me watch that."

"Titanic?" "Oooooh! Go on then!"

I took the empty carcass up to the desk. The incredibly worldly-wise 19 year old looked at us disdainfully. "Sorry mate, out of stock."

You see, hard as it may be to believe, the local Blockbuster franchise had underestimated the popularity of Titanic. They'd purchased a dozen copies to rent out. Once those walked out the door, that was it. We could ask them to ring us when a tape was returned - but we'd be at the bottom of a long waiting list.

So we leafed through a few display racks and went home with the kid's film about a genie, "Shazaam". It wasn't very good, as I recall.

If only Netflix were like that! Imagine if you tried to watch Stranger Things and were told that too many people were streaming the first episode. Netflix will notify you when there's a slot available. In the meantime, why not watch "Clarissa Explains It All"?

Wouldn't that be brilliant! Netflix could restrict demand, make things artificially scarce, and just generally make a worse user experience for everyone.

Wait... no... that'd be shit!

And yet, that's exactly how digital library books work in the UK!

Look, perhaps a Netflix for books wouldn't work; it's harder to read than it is to stick on TV in the background. But there's a healthy library scene in the UK. Authors get paid when people borrow their books. So why are libraries restricted to only loaning out a limited number of copies at once?

There's a part of me - a very small part - which can see the utility in this. If everyone could borrow the latest Dan Brown smash-hit all at once, would they ever explore any further? When you're told "Sorry, we don't have that - but you might like..." it could expand your reading horizons.

But that's a weak argument. With an endless supply of books, people can choose what they want to read, when they want to read it.

There is no digital scarcity. We need to rid the world of this analogue thinking.

This is a quick-and-dirty way to grab images of the pages and convert them to a standard PDF using Linux. There's a lot more you can do to make the end book more useful, but this'll get you started

Lots of Screen Shots

With a USB cable plugged into my phone and laptop, I wrote a horrible little bash script:

#!/bin/bash
for i in {00001..00555}; do
   adb exec-out screencap -p > $i.png
   adb shell input tap 1000 2000
   sleep 1s
done
echo All done

This runs a loop 555 times. Takes a screenshot, names it for the loop number with padded zeros, taps the bottom right of the screen, then waits for a second to ensure the page has refreshed. Slow and dull, but works reliably.

Images range from 200KB to 2MB depending on complexity. Back them up before doing the next bit.

Cropping

The screenshots are all 1080x2160. But the page only takes up part of that. The top left corner is at 50x432 and the bottom right is at 1028x1726.

This command crops all the images. It is destructive, so make sure you have a backup.

mogrify -crop 978x1294+50+432 +repage *.png

It's also useful to trim the images to remove any whitespace from the borders. That makes a smaller file size.

mogrify -trim *.png

Images can be shrunk with:

pngquant *.png

PDF and OCR

Sticking all the images together into a single PDF is pretty easy:

convert *.png +repage output.pdf

The +repage option keeps the aspect ratio of the trimmed image.

But there's no text to search. There are a bunch of OCR programs on Linux, I like PDF Sandwich:

pdfsandwich -rgb -nopreproc output.pdf

That'll get you a colour PDF with OCR'd text embedded in it. The text is "sandwiched" behind the image of the page, so you can't see it but can search for it.

You can also use OCRmyPDF which may result in a smaller file:

ocrmypdf -l eng output.pdf output_ocr.pdf

And that's it. I now have a searchable PDF which I can read on any device.

What have we learned?

DRM on textbooks is an annoyance. For computer science books, it's little more than a fig-leaf.

libgourou is a free implementation of Adobe's ADEPT protocol used to add DRM on ePub files. It overcome the lacks of Adobe support for Linux platforms.

There are a few limitations, but nothing too serious:

• Only ePub is supported. No PDF
• Command line only
• Alpha quality software. It works - but is a bit finickity

You can compile the code yourself, but I just downloaded the pre-built binaries.

On Ubuntu / Pop I needed to sudo apt install libzip-dev.

Once you've unzipped the download, cd into it and run:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PWD

Then

./adept_activate -u youremail@example.com -p SuperStrongPassword

Use the same credentials as you do in Adobe Digital Editions. You can just use the -u flag and type your password in at the prompt - but I couldn't get that to work. The -p flag worked fine.

After a few seconds, you'll see: youremail@example.com fully signed and device activated in /home/you/libgourou_utils_0.3.1/./.adept

Then run: ./acsmdownloader -f whatever.acsm

After a few moments, you'll see: Created whatever.epub

That's it! Your file is downloaded and you can read the ePub.

Note: If you try to download a PDF, you'll get an error saying: Exception code : 0x5007 Message : whatever.epub

You can rename the file back to .pdf, but it will still be encrypted.

Sure, you can futz around with Docker, WINE, and old versions of Python - and if you're lucky, you might get a book out of it.

I wasn't quite so lucky. I wanted to see if I could download an ePub without using Adobe Digital Editions. Spoilers! I couldn't. But this is what I found.

The First ACSM file

When you buy an eBook, the vendor sends you a .acsm file. Adobe Content Server Message is a simple XML file. This is what it looks like and what each line means:

<fulfillmentToken fulfillmentType="buy" auth="user" xmlns="http://ns.adobe.com/adept">
  <distributor>urn:uuid:b479af7f-09bf-48f5-a6c6-...</distributor>
  <operatorURL>http://drm.firebrandtech.com/fulfillment</operatorURL>
  <transaction>67809895895d46aab...</transaction>
  <expiration>2021-07-19T18:55:59-04:00</expiration>

This states I've purchased the book, who distributes it, where the download server is, and some metadata

Next, metadata about the book:

  <resourceItemInfo>
    <resource>urn:uuid:77d79621-0e96-4f4f-8fee-...</resource>
    <resourceItem>0</resourceItem>
    <metadata>
      <dc:title xmlns:dc="http://purl.org/dc/elements/1.1/">The End of Bias</dc:title>
      <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jessica Nordell</dc:creator>
      <dc:publisher xmlns:dc="http://purl.org/dc/elements/1.1/">Granta Publications</dc:publisher>
      <dc:identifier xmlns:dc="http://purl.org/dc/elements/1.1/">urn:ean:9781846276774</dc:identifier>
      <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">application/pdf</dc:format>
    </metadata>
    <licenseToken>
      <resource>urn:uuid:77d79621-0e96-4f4f-8fee-...</resource>
      <permissions>
        <display/>
        <excerpt/>
        <print/>
        <play/>
      </permissions>
    </licenseToken>
  </resourceItemInfo>

Finally, a digital signature:

  <hmac>rL4Ttn7ASp16Y4...=</hmac>
</fulfillmentToken>

The Second ACSM file

When you open the .acsm file in Adobe Digital Editions (ADE), the software creates a new .acsm file. This one is signed with the key that Adobe generates when you register with it. This is what the file looks like and what each line means:

First, information about me as a user, and my device:

<fulfill xmlns="http://ns.adobe.com/adept">
  <user>urn:uuid:99b1e32d-5b39-4968-8ef6-c5cb6a739ec8</user>
  <device>urn:uuid:ac790662-5da0-4075-aee2-99b3c4592619</device>
  <deviceType>standalone</deviceType>

Then a repeat of the original .acsm:

  <fulfillmentToken fulfillmentType="buy" auth="user">
    <distributor>urn:uuid:b479af7f-09bf-48f5-a6c6-...</distributor>
    <operatorURL>http://drm.firebrandtech.com/fulfillment</operatorURL>
    <transaction>67809895895d46...</transaction>
    <expiration>2021-07-19T18:55:59-04:00</expiration>
    <resourceItemInfo>
      <resource>urn:uuid:77d79621-0e96-4f4f-8fee-...</resource>
      <resourceItem>0</resourceItem>
      <metadata>
        <dc:title xmlns:dc="http://purl.org/dc/elements/1.1/">The End of Bias</dc:title>
        <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Jessica Nordell</dc:creator>
        <dc:publisher xmlns:dc="http://purl.org/dc/elements/1.1/">Granta Publications</dc:publisher>
        <dc:identifier xmlns:dc="http://purl.org/dc/elements/1.1/">urn:ean:9781846276774</dc:identifier>
        <dc:format xmlns:dc="http://purl.org/dc/elements/1.1/">application/pdf</dc:format>
      </metadata>
      <licenseToken>
        <resource>urn:uuid:77d79621-0e96-4f4f-8fee-...</resource>
        <permissions>
          <display/>
          <excerpt/>
          <print/>
          <play/>
        </permissions>
      </licenseToken>
    </resourceItemInfo>

Then, a different HMAC:

    <hmac>rL4Ttn7ASp16...=</hmac>
  </fulfillmentToken>

And, finally, another digital signature

  <signature>znoLnR2A4wG1uE85oXPYzSZjTRNo76ctgfR8COY8nlNTCcPge9O6VeB5UY...=</signature>
</fulfill>

POSTING the file

Digital Editions then posts the new .acsm file to the DRM server mentioned. It replies with a location where the file can be downloaded from. In this case:

http://drm.firebrandtech.com/media/77d79621-0e96-4f4f-8fee-....pdf

That's literally just the resource's UUID as the filename. It can be downloaded and opened in ADE.

Signing the file yourself

So, if you've downloaded the first .acsm file and have your encryption keys extracted from ADE you can sign it yourself, right?

I dunno. I'm no good at reverse engineering binaries. I suspect so. ADE is a Shockwave / Flash app - so I doubt it has anything too taxing in there - but it is beyond my skillset.

Further Reading

• gedonder's notes on ACSM
• Karl Voit's rant about ADE

KOReader is the best eReader software I've found. It works beautifully on eInk screens, Android, and Linux. Just a gorgeous - and infinitely customisable - experience.

There's one thing I don't like - to move forward a page, you have to click the right of the screen and, to move back, the left. That's fine if you're holding the book in your right hand. But sometimes I behave in a sinister fashion and hold it in my left. I want to tap the bottom of the screen to move forward, and the top to move back a page.

My previous eReader had an easy-settings menu like this:

KOReader doesn't have anything like that - yet - so here's how to set it up manually.

1. In the book selection screen (not when reading a book) tap the top of the screen to bring up the menu bar, then press 🛠️ for Tools
   
2. At the bottom of the menu, scroll across to page 2
   
3. Select "More Tools"
   
4. Select "Advanced Settings"
   
5. Read the big scary warning message and press "OK"
   
6. Scroll along until you find "DTAP_ZONE_BACKWARD". Tap on it, and edit the values to read h=0.5 w=1 x=0 y=0
   
7. For "DTAP_ZONE_FORWARD", set the values to h=0.5 w=1 x=0 y=0.5"
   
8. Press the "X" in the top right corner, and restart KOReader.

Done!

Adapted from this GitHub issue. I've also added these instructions to the KOReader Wiki

what about gift giving? No one I have ever asked has thought that an e-book was an acceptable substitute for a printed book when giving a gift.

I've received an eBook as a gift (thanks David!) and it was perfectly acceptable. It was nice to receive, and didn't feel like any less than a gift. I got rid of most of my physical books a few years ago. Receiving a paper book is also nice - but it comes with the burden of having to dust it, shelve it, and deal with its bulk when I come to move.

Similarly, some friends got me a lovely CD as a gift (thanks Sookie & Emo!) and it took me a few days to find a CD player! A digital copy might have been easier to use play - if we were all using the same music service.

And, I think that's the real reason why digital gift giving hasn't gone mainstream - the infrastructure doesn't support it.

Is it possible?

Some platforms just don't allow you to send digital content as gifts. For example, PlayStation doesn't support gifting. You can send a gift voucher to a friend, but there's no way to buy them Day of the Tentacle.

Others are laggards. Amazon only recently supported giving eBooks as gifts in the UK.

But even if you can send a gift, can the recipient receive it?

Platform lock in

I don't have iTunes. If someone gifts me the latest Spice Girls album, I'd have to sign up for an account, download iTunes, and find a way to get music onto my Android phone.

If I give someone a DVD, they can play it on any DVD player. If I gift an Amazon movie they need the right TV, dongle, broadband speed, and online account.

There's no way for me to buy a digital voucher for "SpiceWorld: The Spice Girls Movie" - and have it redeemable on the recipient's choice of platform.

Similarly, I could buy a DRM-free copy of a book - but I'd need to know whether the recipient can read ePub or not (hint - Kindle can't unless it is manually converted).

Information leakage?

Some stores do let you give digital gifts. Steam, the video game shop, lets you do that. With one interesting detail:

How can I tell if my friend already owns the game(s) I would like to gift? If your friends are members of your Steam Friends list, you can learn whether they already own the game you'd like to give. Steam FAQ

For a social gaming experience like Steam, it may make sense for your friends to know what games you have. But do you want all your friends knowing you own an eBook copy of "Spice Up Your Life: The Authorised Biography of the Spice Girls"?

Audible - the audio book company - handle this quite well:

What happens if I buy somebody a book they already have? If you give a book that the other person already has in their library, we'll give them a credit or coupon they can use to choose something else. Audible gift FAQ

Abuse

Steam only lets you give gifts to people on your friends list. What's the potential for abuse if you can send a gift to anyone with an email address?

I'm sure you could think of a dozen ways you could annoy or harass someone if you could send them gifts without prior permission.

The Gift That Keeps On Giving

At the moment, there are limited options for giving of specific digital gifts. If a store allows it, you can buy a digital gift and then hope your friend is on that specific platform.

Is there a better way?

Amazon sells eBooks in KF8 format. That is an ePub with some proprietary extras. ePub is a standard based off HTML5. You can read the ePub 3 specification but, basically, it is a .zip of HTML files. If you unzip an eBook, you can read the source code behind it.

When trying to read a Kindle book on a non-Kindle device, I noticed a bug. Some words were not displaying. I took a look at the underlying source code, and found this:

Sometimes words and letters were wrapped with a pagebreak span like this:

<span id="pg5" epub:type="pagebreak">‘But</span> of course!’

When I tried to read the book using KOReader the word "‘But" didn't appear. Why? Let's take a look at the ePub3 specification concerning page breaks:

pagebreak

• A separator denoting the position before which a break occurs between two contiguous pages in a statically paginated version of the content.
• HTML usage context: phrasing and flow content, where the value of the carrying elements title attribute takes precedence over element content for the purposes of representing the pagebreak value

Here's the problem - eBooks can have page numbers. Despite "Page Numbers in eBooks Considered Harmful" lots of publishers still use them. I guess it is kind of useful if you want to refer to something on a printed page - but eReaders allow you to change font size and line spacing, so the concept of a page is somewhat nebulous.

The way the spec is written, means that you can write something like:

<span epub:type="pagebreak" id="page_123_a" title="123">123</span>

You use the id for internal linking and the title attribute for the value.

Because of this, most eReaders do not display the physical page number inside the span. It has no semantic content for the reader, and breaks flow. If they did display it, you might end up reading text like this:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vel

9

risus at metus molestie tincidunt. Donec aliquet aliquam lorem, ...

So KOReader deliberately ignores any text which is wrapped with epub:type="pagebreak".

If you look at the example ePubs provided by the International Digital Publishing Forum, you'll see that the majority of their spans are self-closing.

<span epub:type="pagebreak" id="p123-a" title="123"/>

Very occasionally, you see something which has just a page number in it:

<span epub:type="pagebreak" title="169" id="Page_169">169</span>

I checked with KOReader and they confirmed that they were following the spec. I agree with them. There's no reason to wrap readable content in a metadata span like that.

I've checked several other books from different publishers. None of them abuse pagebreaks this way. I think Penguin Random House are doing it wrong and I would like to correct them.

Reporting it

I've previously reported buggy ebooks to vendors. But because the Kindle app doesn't exhibit this problem, I thought it was futile going via Amazon. So I thought I'd try going directly to the publisher.

Sadly, Penguin UK's GitHub repo is dead. Their dedicated digital publishing team haven't tweeted in 2 years.

Their contact page has a suggestion for what to do if there is an error in an eBook:

It is best if you return the book to the original bookshop from which it was purchased; they should be happy to exchange it for a perfect copy. If you have any difficulty with this then please return the cover and title page of the book to us.

Hmmm....

I dropped them an email, and got back this very reasonable reply:

Thank you for reaching out and bringing this to our attention. The distinction you’ve made is already a part of our specification; this was an oversight which we’re looking into as a result of your input—it bypassed checks both because it validates and also passes visual checks on all the major platforms we screen for. This isn’t reflective of our entire library and should be limited to specific titles which we’re currently investigating.

That's fair enough. The rendering quirk is specification compliant - but hard to spot because of the Kindle monoculture.

Change the spec, change the world

I've made a suggestion on GitHub that the spec should be clarified. I don't think it's particularly obvious that content in a pagebreak may not be displayed.

Most resources agree that the content of a pagebreak should either be blank, or be the page number.

If you include the page numbers as text content within a span or div, the pages will be more easily accessible to both sighted users and users using assistive technologies. This method has been employed in previous DAISY standards. The potential downside, however, is that mainstream user agents will not provide equivalent functionality to turn off unwanted content, forcing users to hear and view the page numbers.

Digital Accessible Information System (DAISY)

Whose fault is it anyway?

This is a tricky one. I think Penguin have undoubtedly made a mistake with the way they publish ePubs. But, so far, KOReader is the only rendering engine I've found which suppresses the content of pagebreaks by default.

Generally speaking, a user wouldn't want to display page numbers on an eBook. Software could have a user defined toggle to switch them on or off. Luckily, KOReader has a variety of style-sheets for rendering eBooks - so I picked one which displayed pagebreak content.

Software is hard.

A friend of mine recommended an obscure book, published a couple of years ago. The blurb made it look right up my alley, so I tried to buy it. I only read eBooks, but I couldn't find it anywhere for sale in the UK. Amazon had a listing for a paper copy, but it was permanently out of stock.

In desperation, I went straight to the publisher. They would ship a dead-tree book across the Atlantic to me. With shipping costing even more than the book.

I found someone on Twitter who was posting highlighted screenshots of the book, so I Tweeted him and the publisher to find out where to get a copy. He graciously offered to send me a PDF.

At which point, the publisher waded in - furious at the situation.

How dare you give this away for free? We're a small publisher and we have to sell books to stay in business!

Fair enough. So I asked them where I could buy an eBook version. Their response was disappointing.

It's only available on Proquest and Ebsco. Sorry!

Both of those are academic databases, available on subscription only, with no public pricing available.

So, let's be clear. You don't want people giving it away, but you won't actually sell me a copy?

What do you want me to do? Not read your book?

I took the emailed PDF. I'm not particularly proud of that. The book is good, and I'm enjoying learning from it. I just wish I could have paid for it.

Download the latest dictionary from DictInfo.com. At the time of writing, the latest English version is October 2018

The dictionary file is a .7z file. It's easiest to unzip it on your computer, rather than the eReader. I recommend 7zip.

There are three files:

• wikt-en-en-2018-10-07.ifo
• wikt-en-en-2018-10-07.idx
• wikt-en-en-2018-10-07.dict.dz

Copy all of the files to the /Dict folder in the root of your eReader.

Open up a book using the default reader app. Long press on any word and the default definition will pop up.

• Press the A-Z dictionary icon in the top right corner.
• Untick the system dictionary and make sure the Wiktionary dictionary is ticked.
• Then press the up arrow so Wiktionary is at the top.
• Press back.
• Long press on a word again.

Tada!

That's it! Your eReader now has a modern English dictionary with definitions.

Bonus!

You can build your own dictionaries using the Open Source Wikitonary Convert tool

OK! OK! That's not the main reason. It has pretty good support from the manufacturer and a vibrant community around it. Masses of memory, warm lighting, and oodles of space. And, I think, pretty hackable.

Quick video

Specifications

• Android 6.0 - with a promise to update it to Android 8.0
• Touchscreen with Wacom stylus
• 1.5GHz CPU
• 2GB RAM
• 32GB storage plus a microSD slot
• 7.8 inch E-ink Carta HD (300 PPI) screen
• Dual colour front lights
• USB-C for charging, data transfer, and headphones
• WiFi and Bluetooth
• Speakers and microphone
• 3200 mAh battery

Essentially it's an Android tablet with an eInk screen. The Wacom stylus can be used for handwriting and note-taking.

The reading experience

Amazing! The screen is goregous. You have precise control over the thickness of the fonts, line spacing, word spacing, and more. Pinch to zoom works perfectly. You can even side-load your own fonts. You can also read in landscape mode with two columns. I find that particularly useful.

Links within books work, as do footnotes and endnotes. The keyboard is pretty quick for searching. You can change how bright the light is - and flip between warm and cool lighting.

It also does Text-To-Speech, so a little robot can read books out via the stereo speakers. It'll also play MP3s. No headphone jack - but it supports Bluetooth and USB-C.

There are some glitches in the default reading experience - especially when it comes to punctuation.

Formats supported

A sample of ePub, .mobi, PDF, and .txt files all worked well.

It shows up as an MTP device when connected to a computer via USB. Or you can send files via Bluetooth. It also has a built in webserver, so you can send via WiFi.

ePub 3

I tried the default reader using some of the sample ePub 3 documents. It coped with Arabic (right to left), Japanese with Ruby, and inline images.

Weirdly, it didn't like linebreaks in running text - collapsing them so there was no spaces between words.

It didn't support embedded fonts in eBooks. But, that's ok, you can add your own!

Fonts

Create a directory called /fonts/ on the device. Paste in either TTF or OTF fonts. They magically appear in the reading app!

No support for WOFF / WOFF2 fonts in the default reader.

Apps

There are a few built in apps - the standard Android browser is included. There's an app store and the ability to side-load. There are a bunch of reading apps if you don't like the default one.

Yup, you can install the Amazon Kindle app if you really want to!

(Screenshots are in colour, but the screen is black and white.)

Note taking

I don't like handwriting - but the Wacom stylus is easy to use. You can draw on the screen, annotate PDFs, and erase your scribblings.

Quirks

It doesn't come with a case, nor a screen protector. I'm in two minds about this. It has a glass screen, so should be fairly rugged. I don't plan on using the Wacom stylus, so I doubt that'll scratch it. But seeing as any blemish interferes with your reading experience, some protection is a must. I purchased a £20 case for it.

Start-up time is slow. This is an Android tablet, so doesn't have quite the same energy efficiency as other readers. From off to reading takes about 45 seconds. You can set it to never switch off, but you'll need to charge it a little more often.

The UI isn't brilliantly translated into English. You'll understand it, but the grammar and spacing are quirky. You can also see a few HTML entities in the the UI. So, not perfect quality. But usable.

There are also some untranslated /UI elements.

The UI takes a little getting used to. Some options are hidden away in menus, others behind icons. Most things you'll only have to set once, but it can be a challenge finding everything.

The first time I rebooted, it reverted to Chinese, but it was pretty simple to set it back.

Cost and Verdict

I paid £190 from eBay - plus £20 for a case. I reckon that's a bargain! There are cheaper eReaders out there - but this is the only one I found with USB-C. It doesn't tie you in to the Amazon Kindle monoculture.

As an Android table, it's basically fine. Good enough for occasional web browsing, and some specifically optimised apps.

And as a book reader? Close to perfect! Text is crisp and clear, page turns are instant. Lots of options to fiddle with to get your books just right.

What happens when a robot begins to question its creators? What would be the consequences of creating a robot with a sense of humour? Or the ability to lie? How do we truly tell the difference between man and machine? In "I, Robot", Asimov sets out the Three Laws of Robotics – designed to protect humans from their robotic creations – and pushes them to their limits and beyond.

After attending a lecture on the ethics of self-driving cars, I decided to re-read Asimov's "I, Robot".

Any discussion of robots killing people inevitably returns to the supposed wisdom of the "3 laws of robotics".

I argue that the "3 laws" should be considered harmful.

Let's remind ourselves of the laws:

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.

The first thing to note is that these are a literary device - not a technical device. Killer robots are boring sci-fi. The interesting sci-fi is looking at "good" robots which inexplicably go bad. "I, Robot" is essentially a collection of entertaining logic puzzles. Æsthetics are not a good basis on which to build an algorithm for behaviour.

The second thing to note is that the laws are vague. What do we mean by "harm"? This is the lynchpin of one of the stories where (spoilers!) a telepathic robot avoids causing psychological pain.

Most people can't deal with complexity. Here's a common complaint:

Archimedes’ Principle: 67 words The Ten Commandments: 179 words The Gettysburg Address: 286 words The Declaration of Independence: 1,300 words The US government regulations on the sale of cabbage: 26,911 words As circulated by email from everyone's "kooky" relative

The claim above is utter nonsense - but laws are complex. The Ten Commandments may be short - but they cause a huge amount of ambiguity. What does "Thou shalt not kill" cover? Gallons of ink has been spilled interpreting those four words. Ironically, blood has been shed trying to resolve those ambiguities.

Would it have been helpful to have, from the start, 30,000 words explaining exactly what each rule meant?

Thirdly, these aren't natural laws. Too many people - including scientists - seem to think that these are hard-wired into robots! I've had conversations with otherwise rational people who haven't quite grasped that these aren't baked into the fabric of existence.

The "laws" are a harmful meme. That's testament to the power of Asimov's writing. His stories have infected every discussion of robotics and ethics. Even though we know it is fiction, something deep inside us recognises them as a necessary part of creating "acceptable" robots.

The 3 laws are brilliant for story-telling, but lousy for AI policy making.

The dramatic human story of an epic scientific quest: the search for the solution of how to calculate longitude and the unlikely triumph of an English genius.

A fascinating look at a defining moment in technological development. Full of intrigue, double-crossing, maths, and science.

It cracks along at a fair pace, sometimes lightly skipping over details. I would gladly have read this if it were twice the length. Not a bad thing for a book to leave you wanting more.

The only weakness is a lack of diagrams and maps. Happily, there is an illustrated edition, which I will check out in due course.

Death’s End (死神永生) is a science fiction novel by the Chinese writer Liu Cixin. It is the third novel in the trilogy titled Remembrance of Earth's Past, following the Hugo Award-winning novel The Three-Body Problem and its sequel, The Dark Forest.

This is an unforgiving book. Did you remember every detail from the last two novels? No - better go back and take some notes!

It is epic sci-fi. Bouncing between times, exploring big ideas, and gently bubbling techno-horror.

But it is uncompromising in how much work it expects you to do. A throwaway line towards the end of the book directly relates to a minor plot-point in the first.

Overall, the three books are a masterwork - but it requires a lot of effort to appreciate.

​Welcome to 97-hour weeks. Welcome to life and death decisions. Welcome to a constant tsunami of bodily fluids. Welcome to earning less than the hospital parking meter. Wave goodbye to your friends and relationships... Welcome to the life of a junior doctor.

I saw Kay perform his delightfully disgusting parody songs on the Amateur Transplants tour way back in 2008. The humour in this book is much the same - bodily fluids, a healthy disregard for squeamishness, and some big-and-clever swearing.

If you have any mates in the medical profession, you'll have heard similar anecdotes to the ones in the book. Patients sticking stuff up their bums, doctors accidentally chopping off the wrong bits, bosses leaving equipment inside a patient. It is a well-worn seam of comedy.

Don't get me wrong, it is funny - and a stark look at the realities of working in the NHS - but it probably won't teach you anything new. It's a quick read and entertaining enough - although not great for people with a fear of blood.

I'd recommend that you read Blood, Sweat, and Tea - Brian Kellett's amazing account of life working on London's Ambulances. Funnier and more raw.

Celebrating the fiftieth anniversary of the film’s release, this is the definitive story of the making of 2001: A Space Odyssey, acclaimed today as one of the greatest films ever made, including the inside account of how director Stanley Kubrick and writer Arthur C. Clarke created this cinematic masterpiece.

This is the ultimate "DVD Extra" of a book. Every single detail of the genesis and revelation of 2001 is documented in painstaking detail. The author has exclusive access to original manuscripts, and has conducted dozens of interviews with everyone from Arthur C Clarke to - literally the on-set tea boy.

Full of odd little anecdotes - some barely more fleshed out than an IMDb trivia entry - including some absolute gems of stories in there. A complete guide to how the film twisted and turned in its creation. I'd go so far as to call it a pure biography of a cultural artefact.

At times it feels like each chapter is written by a different author. There are meandering asides, and spurious footnotes - but it is all rather jolly.

It is long - but what else would you expect? A great book for anyone who loves the film.

Exploring issues from eradicated black history to the political purpose of white dominance, whitewashed feminism to the inextricable link between class and race, Reni Eddo-Lodge offers a timely and essential new framework for how to see, acknowledge and counter racism. It is a searing, illuminating, absolutely necessary exploration of what it is to be a person of colour in Britain today.

Sparked off by her explosively popular blog post, this is a timely and deliberately provocative book.

Some parts absolutely struck a chord with me - especially the lack of education in Britain about the country's role in the slave trade. I also found the discussion of the structural biases within certain institutions to be extremely relevant.

If I'm being selfish, I'd have liked to have seen some discussion of events like the Battle of Bamber Bridge, where white British people weren't quite as awful as they might have been.

I felt the polemic occasionally got in the way of the argument. But perhaps this isn't a subject which deserves dispassionate analysis.

All that's thin criticism to an excellent and convincing book. Highly recommended.