Re: The Greatest Salesman In The World Epub 11
Leana Eckes
I have created an EPUB (fixed layout) file with animations in Indesign, which works without problems on a Thorium reader on PC. When I checked the file on the EPUB checker, it reports errors with the animations, and it reports similar or the same error everywhere with all the animations:
While most EPUB validators are a waste of time, EPUBchecker is as much the gold standard as is Thorium Reader. If your EPUB works on Thorium, any further checking, testing or attempt at optimization is... probably wasted. Clearly, this XML flaw doesn't keep the document from working on the most highly standardized reader you can get. You can spend a lifetime on this kind of all but phantom flaw and gain nothing.
Thanks for feedback. Actually, the animations work on all the readers I've tried now, but what I'm worried about is the distribution across online platforms, namely that these errors, which don't affect the performance of the EPUB file at all, would result in the file being rejected.
If you insist on using fixed layout epub you are likely to be in for a bit of pain. At this point, I wouldn't touch a job with it unless it was for a limited internal distribution that could be tested on specific devices with specific reader applications.
I am aware of the disadvantages of EPUB fixed layout, but the e-book is a children's cookery picture book for which a fixwd layout is probably more appropriate than a reflowable layout. So the problem is not the format, because the book and the animations that were made with Indesign otherwise work fine on all the readers it was tested on, the only problem is the code that Indesign generates that does not follow the xml standard. This problem is only detected by the EPUB checker, and does not affect the performance of the file. I have also prepared a file without animations, and it is error-free, but I would like to publish an e-book with animations, so I would like to fix this problem.
That it works on all the readers you've tried it on should be enough for distribution, but many of the vendors do demand strict validation compliance.... which is often meaningless, but they're as tired of the fallout from broken books as everyone else.
Thank you both for clarifications. I was also counting on the fact that the full range of functionality will probably not be able to meet the requirements of all web platforms, so we have the possibility to avoid this problem by simply uploading the EPUB file without animations, which will solve the issue, at least as regards the animations.
Not quite sure what your web comment means... after the chaos of the HTML4/XHTML/browser war era, in which no two browsers showed the same rendering of simple pages without scads of conditional code, the web has become almost astonishingly pan-compatible. It's only in a few minor areas that some browsers don't have full/matching support. An HTML5/CSS3 web page is as close to a universal document/display page as the world has, I think. You have to get pretty convoluted or tricky for the standard range of browsers not to show the page identically.
Well... leaving out the idea that EPUB surgery is obsolete, are you sure there are no external calls to that function? Maybe not in this case, but it doesn't help to rename something internally if an external library, server or database (for example) uses it.
I've run into this issue myself before. It works. Those function names are repeated across several files, with up to 9 or so instances or more (depending on the number of pages with animations, of course).
The insistence of some resellers on validation perfection, is, perhaps, a problem in itself. (Although, peeking in horror as I do at some of the amateur publishing forums etc., maybe it's just necessary self-defense. )
First, as you probably know, fonts are encrypted so that they cannot be extracted from an EPUB and reused. Only some fonts are licensed/allowed to be used in this fashion, so any font that does not have the right license encoding will be rejected by the export, or (when stuck in the middle) result in errors. The very short answer here is that you'll need to replace that font (face) with one that is compatible with encrypted EPUB export.
It is, however, a deprecated practice to embed fonts, or to designate specific fonts at all. Modern practice is to use generic font definitions (serif, sans-serif, monospaced) and let the reader (app or device) and user choose and optimize the actual fonts used.
So... if you're using FXL, consider changing to reflowable layout and not spec'ing or embedding fonts. But if you don't want to make any of those changes, you need to find an alternate, technically compatible font for the one that's being rejected.
In this case I will probably not upload this to Apple Books, but I would like to know what is wrong and how to fix it. The font used is RooneySans, which is an Adobe font! Am I making a bad choice during the export phase, in the export epub dialog?
The solution is to fix the font, one way or the other (replace, get a better font file/version, etc.) It may be that InDesign was glossing over this mismatch/error until v19, and now processes the XML summary properly, so the doc "works" but fails strict validation. I don't really know who to point a finger at here; I'd be surprised if the same font did not cause an encryuption.xml error using old 'build it" tools as well. That is, the fault here may have been that ID was allowing the error to pass. But I really don't know.
...doesn't tell what font is causing the error. By the way, there are two fonts here: RooneySans and SF Pro (which I could convert to outline, since it's just icons from the SFSymbols app). Even assuming I find the culprit, how does one fix a font? What error is actually there?
I'm going to dig into the actual files here and see if there's useful information, but it's basically simple: if you have an Info note for any "non standard font," it results in an Error for the encryption.xml file. I have tested enough to know that when all fonts that spawn that warning are removed, the error goes away. So it's not one or the other of those fonts in your case, but both/either.
Again, I don't know if this is a mistake/fault on ID's part, or simply something that's been brought into more rigid conformance and is thus creating an error with elements that formerly passed. Experimenting now.
Yeah, I agree: it's all a bit vague. What the OP could try: open the file in Sigil and right-mouse click the offending obsfucated fonts, then either turn that off or use the alternative obsfucation method. Then try again.
Thought I answered this... maybe not. The answer is that you can't identify any one font among the culprits if you have more than one "nonstandard font" warning. Any one or more of those will cause the "Font Core" error in response. ALL of those fonts have to be replaced.
I'm not sure this is a much a general "Computer Science" knowledge issue as it is just another fault of EPUB: it's excessively complex, it's fussy about far too many things and there's no documentation in between the standards declaration and something comprehensible. The details of this issue could be resolved by laborious code-tracing and standards-reading (bring aspirin), but in the end, it will be just one niche issue resolved, and likely to no useful end. Validation won't accept those nonstandard fonts; period. There's no fix but to replace them with compliant fonts, no matter what the technical/structual reasons and algorithms are.
"Obfuscated" is XML-speak for "encrypted," more or less. It's a method to protect stuff in completely open ASCII code by using substitute characters (such as the ASCII codes for spaces and line returns), then tangling up the code so that only an expert with a great deal of patience can turn it back into understandable, modifiable, steal-able code. It's common in all web sites build using commercial tools and libraries, since otherwise anyone who can view the site can review the code and copy those advanced features. Here, it's extended to the fonts being encrypted, a super-form of "obfuscation" but this world only knows its own terms.
Once open, locate the fonts folder in the left outliner panel. Check the fonts one by one. Right-mouse click each font to either remove or change the encryption (obfuscation). Try removing the obsfucation and save the file for testing.
PS replacing the font files is directly possible in Sigil, but you would have to edit the code manually everywhere these files are referenced in the epub. Usually there are only a few files here and there with a few references for your fonts.
Ideally we wouldn't want to embed any fonts in our epub files, btw. We ought to leave the font choice to the reader and the user's reader font settings. Same for font sizes (never use PX, always use relative units such as EM) and line height (leading). eReader devices allow the user to customize these to their liking, and by setting hard absolute px/pt units it often becomes impossible for the user to adjust these.
Well, I've made it pretty clear in my postings here (and elsewhere) that I think the days of post-creation surgery on EPUB are over and done. Sigil, BBedit, all those tools are relics of a past when you built your e-book (of any format) from handmade scraps and files, or you didn't do it at all. But just as we don't post-process PDFs any more, or fix printouts with wite-out and a pen, it's outdated and misdirected to have to overhaul EPUBs after every single export attempt.
The real solution here is don't embed the damn fonts in the first place, as it's contrary to modern e-book design... another point on which I maintain an inflexible viewpoint. Respect the medium, don't try to drag lead-type notions into it. If all e-publishers followed that one practice, e-book aficionados wouldn't need to keep a repair and hot-rodding tool set around. That so many people are willing to put up with this nonsense (and often crappy book design to boot) just to use this reader or that for everything kinda boggles me.
7fc3f7cf58