Quote:
Originally Posted by st_albert
Late to the party again, but....
One of many things I'm confused about is this:
Does this phenomenon apply only to Type1 fonts, or all fonts (ttf, otf, ...)?
And if the former, does it apply to otf fonts that were converted from Type1 (as the GhandiSans example would suggest)?
Also do I understand correctly that the phenomenon is observed whether you upload an epub (sigil compressed vs. WinRar compressed), OR whether you upload a mobi file built locally via kindlegen (which version? does it matter?) from the corresponding S or WR epub source. Even though both mobi files are properly functional before upload to DTP?
A comment:
I'm also interested in the experiment where the WR epub is compressed using "defX" instead of "defN" compression, and whether it can be replicated on linux using the standard zip program (at various compression levels).
Then there are the "extra field" and "text vs binary" issues. The combinations and permutations are overwhelming.
Albert |
Hey, Albert:
Well, there are some confluences of differing events/bugs here, so, firstly, we have:
- The one guy's bug, in which having two different h2 classes, one overriding the other, nuked ALL vestiges of fonts in his mobi;
- The issue with Type1/Postscript fonts, in which for some reason, they are not "sticking" in properly-formatted mobi files, nor valid ePUBs, nor zipped HTML files; and,
- The fact that the KDP-Previewer is not displaying the corrupted results of the uploaded mobis correctly.
The guy, Mathew, with the h2 classes--that's resolved, and that bug has been reported to KDP. It's only resolved in that, we all know about it now, and most of us who make a lot of books wouldn't have run into it, as we likely wouldn't have conflicting h2 classes, the way he did. Nonetheless, his html and his CSS were both valid, and having the file literally stripped of all fonts (which were every type, tested repeatedly, OTF, TTF, etc.) is bizarro-world.
The font issue we've had has been with a Type1 (and yes, we also FontForged, to no avail). The font that started it all, at our end, was Orator Std, and lo, the long/short of it is, IT JUST DON'T WORK. ;-)
And more importantly, it caused all the other fonts to fail, as well. Nothing we've done makes this font work at KDP, but we've seen other instances with other fonts, in different books, although the corrupted upload method discussed has worked with those. When we made a mobi in our standard way (KG), the resulting post-upload preview file displayed no fonts. When downloaded and unpacked, fonts were in the kindlegensrc.zip, but nowhere else. We tried zipped html files, ePUBs...nothing. The only way we got fonts to "take" was to take the source files, tweak them for mobi as we usually do, zip the results using WinRAR (other zipping methods, thus far, have not worked at all), then rename the resulting zip file as "ePUB" and upload it, even though that "ePUB" was not a valid ePUB. Now, when I say, this got the fonts to "take," the other font, Century Schoolbook, displayed fine; but the Orator was a disaster. (See image).
The image you see is from Previewer (desktop), taken from the post-Step-6 Preview mobi, downloaded, and viewed on Previewer. Interestingly, on the KDP-Previewer, this same file appeared as though it were
perfect. So, obviously, as I said earlier, there's a KDP-Previewer display bug, as well.
We've seen this with a TTF Com4s Sans and yes, the Gandhi, which is a Type1. So, thus far, I haven't been able to nail it down to one thing/factor.
And, yes, we are seeing this issue sporadically whether the mobis are perfectly functional and made without any error messages via KindleGen, KindlePreviewer, or even via dropping an OPF; thinking it was something in the compression/zipping of Sigil, versus the "new" KDP, I've tried epubpack, I've tried ePUBTweak, and I've used several other zipping utilities. For the Orator book, only the WinRAR-ed, then-renamed, not-valid ePUB got any font result at all, and you see what a mess that is. (Obviously, we're making the book with a different font now, but suffice it to say,
client no happy.) At the moment, we are making the books, uploading them ourselves at my own KDP account, downloading the preview files, putting them on Previewer and every device in-house, BEFORE we ship them to the client, because the KDP-Previewer is utterly unreliable as an indicator as to whether or not the file is working.
And, yes, the permutations and possibilities ARE overwhelming. I'm not explicating this clearly enough, I know; it's because the last 7 days have been spent putting out fires, instead of having the time and luxury to really investigate and get to the bottom of what the hell is causing this, what the commonalities are, IF it's the compression (or not)...etc. Very frustrating.
Hitch