Okay, it looks like:
- EpubSplit is copying the encrypted TTF file from the source, exactly as it is in the source epub.
- For the split epub to use that TTF file, it needs the META-INF/encryption.xml file and the same <dc:identifier ...> value, as jhowell pointed out.
The exact problem, for me at least, was initially being masked by the fact that Calibre's Edit book
automatically decrypts the TTF file when you open the epub and
re-encrypts it again on save. (The older Explode book tool does not do that, BTW.)
Which leads to a couple interesting work arounds:
- You can copy the TTF file from the source epub while in Edit book because it's already decrypted at that point.
- You can delete META-INF/encryption.xml from the epub while in Edit book and when you save the epub, it won't re-encrypt the TTF file again. Splits after that are fine.
Clearly, Calibre knows how to decrypt the TTF file. The question then is whether EpubSplit should:
- Copy the encryption.xml file and unique-id value.
- Decrypt the TTF file like Edit book does, leaving it decrypted.
- Re-encrypt the TTF file to the new unique-id value.
- Do nothing and refer users to the work arounds above. Will DeDRM do anything about encrypted fonts?
I also have to consider what, if anything, should be done with Epub
Merge about this. Multiple merged epubs will have different encryption.xml file and unique-id values.
While I think about think it, see the work arounds above.