Experimental epubs


It appears that the auto generated epubs are epub2, but they are using sematic markup found in html5 which is only allowed in epub3.

I uploaded the file to this epub check tool,, and it says that the detected epub type is 2.0.1. It gave the following errors

Error while parsing file ‘element “section” not allowed anywhere; expected the element end-tag, text or element “a”, “abbr”, “acronym”, “address”, “applet”, “b”, “bdo”, “big”, “blockquote”, “br”, “cite”, “code”, “del”, “dfn”, “div”, “dl”, “em”, “h1”, “h2”, “h3”, “h4”, “h5”, “h6”, “hr”, “i”, “iframe”, “img”, “ins”, “kbd”, “map”, “noscript”, “ns:svg”, “object”, “ol”, “p”, “pre”, “q”, “samp”, “script”, “small”, “span”, “strong”, “sub”, “sup”, “table”, “tt”, “ul” or “var” (with xmlns:ns=“SVG namespace”)’.

I believe it is the section tag that is not allowed in epub2.

I converted the file to epu3 using a sigil plugin and then it validates (mostly) just fine.

Was there a reason you were generating the epubs in 2 instead of 3?


No, they should be EPUB 3. Or whatever the latest standard is! I will file this under the bugs.


It has been suggested that this comment might be more relevant here.
So I’m cross referencing. Feel free to move it or ignore it :slight_smile:


These versions are amazing! I love using them so much and they are invaluable on my iPad where navigating the SC site can be a bit of a pain compared to an ebook. I’ve been using them to do a lot of jumping around to read all the references in A History of Mindfulness.

Sorry if this is a lot of feedback, but hopefully some of it is useful :pray:t2:

Cover art broken in iBooks for iOS

Maybe this is related to the epub version or not, but it’s a strange little bug.

On iBooks iOS (ipad and iphone) the cover art doesn’t show for these books, even though on iBooks for macOS, they do show:

iOS is iOS12, though this also happened in iOS 11. macOS is High Sierra, haven’t upgraded yet.

This isn’t the end of the world, but would be nice to have fixed in the long run.

Could cover art have bigger text, and Pali version of title?

Separately, while I love the cover art, I’d vote to make the actual title much much bigger, as an icon on my devices, I kind of prefer the auto-generated one just because it makes the title bigger.

It would also be great to have both the english and pali names in big letters. They are usually referred to with their pali names and I always do a double-take when I need to figure out which of the english versions I need (which is actually a useful training opportunity, but still, I bet a lot of people would appreciate having both).

+1 for Pali names of each sutta in its header

To echo something above: I’d also love to see the pali names of each sutta along with the english ones. I really enjoy having them both while reading here on the website, it helps me train my pali and sets me up to be able to recognize them by their pali names later. I doubt this duplication would bother anyone too much.

Reference code of each sutta in its header

I’d also strongly vote to have the “reference code” (sorry not sure what they are called!) repeated in the header of each sutta, like “MN 28” etc.

This would mean that when searching, I could type that code in search and go straight to the sutta, rather than having to search for the code, click on the result (which is in the index at the start) then click through to the actual sutta.

This sounds just annoying, but on my older iPad it’s actually very slow just to click links and go to the actual sutta (in addition to the search itself taking a long time). It would be really nice if the actual sutta location came up along with the index, and I could pick which of them I want to go to (since I still might want to read your extremely helpful summary in the index before reading).

Having the reference code in the header would also mean that the auto-generated ToC of the book would have these numbers, which I for one would really welcome. Having lists of the English sutta names, without numbers, makes it kind of impossible to navigate. If the numbers were in the headers, and in the ToC, then I could often skip the search entirely.

On top of all that, I think having the numbers visible all the time is a good training opportunity. I like trying to memorize the locations of the suttas I’m familiar with by the codes, and of course on the SC website we are rewarded enormously for knowing these numbers by heart (typing in URLs directly). Having this baked into these books would be great, and I doubt anyone would complain.

Linked Discourses: Chapters in ToC should be the Samyuttas, rather than individual suttas.

Not sure if this one came up already, so sorry if it did, but as of the version I downloaded, the “Contents” of the Linked Discourses file that shows in iBooks is an interminable list of every tiny sutta that’s pretty much impossible to scroll, and without any reference to the chapter each sutta belongs to, it’s even less plausible that I could ever use that list.

Seems to me that for the Linked Discourses, each Samyutta should be marked as a chapter, with each sutta as a subheading within the chapter, or something along those lines.

Maybe this is more of a limitation of iBooks, in which case sorry for making a fuss about it, but it’s a shame if that’s the case.

Either way, if you could get the idea above about having the reference codes show up in the ToC work, that would make a big difference here too, as at least the list of suttas would say e.g. SN 2.4: With Maghadha and the list of such names would make the structure clear.

Thanks for considering these, and regardless for the amazing books! You’re making this kind of research so much more accessible in so many different ways :pray:t2:


As I think was mentioned above, this is tricky if the covers are to be generated automatically.

The following versions are going to be put up on SC, hopefully soon. They have been modified manually and incorporate many of the suggestions folks have made. I am posting them here so folks can give feedback on how the auto generated books might work in the future.



Hi friends,
I was just reading mn96 in my ePub downloaded via the link above and noticed a few problems.

The first seems like a typo but I checked the live version and it’s not there. I will use SC ID references to explain myself.

At Sc10.13
My ePub has ‘the wealth prescribed by a merchant is the scythe and flail.’ Where it should be worker.

At SC15.10 and at 14.10 unnecessary mid sentence paragraph breaks occur between the words ‘aristocrat’ and ‘brahmin’ .

Mettā Pasanna


Just to be clear, these problems are in the EPUB but not in the site?

The first one is probably a correction, the EPUB files are of necessity a little stale compared to the ones on the site. Once we can fully automate the process this lag will be eliminated. But for now, we supply a rough version that Snowbird has tidied up.

I am not sure about the second problem; maybe this is an issue with the conversion?


Yes. I have checked the site and these problems don’t exist. Only the ePub are formatting weird.

It could be a problem with stale ePub on the first account, as I also found a translation mistake in MN97 at SC26.1 where the Buddha is mentioned instead of Ven Sariputa but this seems fine on the site too.


NOTE TO FUTURE POSTERS: Please give the link when referring to the file you are reporting. The thread now has a variety of versions so simply referring to to “link above” can cause confusion.

@Pasanna, It looks like you are referring to the epubs in the very first post. They are indeed outdated in terms of errors in the text. There was a major update of the website after the files in the first post were created. The files in this post are the most up to date. The merchant/worker typo is corrected there. Thanks for posting.

The unnecessary paragraph break looks like this in both the old auto generated epub and the newer one on There is just a regular paragraph division in the code. It looks like this:

And on the site it looks like this:

So it looks like this is a problem that originates on the site and just gets passed to the epbub.


It would be useful to include a version number or creation date in the front matter. Once the book is on my ereader I can’t access such info.


That’s an excellent idea. For the versions I worked on I added “October 2018” at the end of the frontmatter. Except… The Majjhima Nikaya. Sorry about that.

This should absolutely be part of the auto generated books.


Indeed. The problem here is that the paragraph breaks for the Pali text get passed to the translation, but they are not always suitable, depending on the abbreviations used. My intent is to review and correct these, but so far I have not got around to it.


Honestly I have found remarkably few of these, fwiw.



Ultimately I’d like to review the paragraphing, not just to fix broken ones, but to improve the break points, making them more consistent and readable.


Is this link constructed correctly?

I’m trying to generate an epub of the Kathāvatthu. But I get an “Internal Server Error” even when I use an incognito window. Any ideas? I realize this is an experimental feature,but perhaps I’m just constructing the link wrong.


Not sure what is up with that, sorry.

Note also that staging is being actively updated. It was recently (yesterday) upgraded to the latest version of our framework, and updates will be ongoing. This is likely to break things! Meanwhile, finalizing the epub/pdf export is very much on our roadmap, and we anticipate robust support in the next few months.


Apologies if this has been covered already… Is it possible to generate ebooks (epub or pdf) with English-Pali line-by-line, as it is possible to view online?


I’m wondering if an update could be given here by @sujato about the status of the automatically generated epubs. It seems that the staging. link in the op no longer works. I didn’t see mention of this feature in the release notice.


We just missed out on getting this ready for launch: it was literally the next feature to start, and then we ran out of money. :sob: But I spoke with Blake about it yesterday, and he is ironing out the few back end bugs as a matter of priority. So I am still hopeful we will get it going very soon.