Quote:
Originally Posted by KevinH
The bug is epubcheck throwing an exception, not that obfuscation is correctly used on other resources in 3.0 spec. Perhaps this is part of 3.2 spec? The silly thing, if you do not compress that resource and instead pad it with a 1040 byte xml comment at the top, you will have achieved nothing in the form of "protection".
DRM to protect files I understand, but obfuscation here (non-font) is not something all mainstream readers are going to grok so you lose readers and gain no real protection.
|
Oh I absolutely 100% agree and will not use obfuscation.
The issue is I created a python script to obfuscate resources for those who want to do so as part of a CLI workflow, but to test it I didn't want to test on fonts because Calibre will use fonts installed on my operating system if it can't load the embedded font files, so I wouldn't be able to tell if the obfuscation was working.
That's why I tested the obfuscation with an SVG image file. It works (Calibre and all other readers I tried render it just fine) - but in doing so, discovered the ePubcheck bug.
I'm not a fan of obfuscation or DRM. Pirates always find a way around it, obfuscation and DRM only hurts the honest users. But since some font licenses literally *require* it I provided a tool for CLI workflow that does it.