07-22-2013, 10:08 PM | #16 | |
Bookmaker & Cat Slave
Posts: 11,447
Karma: 157030631
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Quote:
The other guy? Mathew? He has errata somewhere in his HTML. I was able to get his ePUB to build to a mobi with "sticky" fonts (ttfs) of the not-Type1 variety by nuking a bunch of his HTML chapters. I did make 1-2 small other changes, but it's obviously an open tag or...? somewhere in the body. I sent him the pared-down ePUB that does build, and the mobi I built with it, and told him "look between X and Y" for open tags or the like, and I suspect he'll be up and running shortly. If he just reassembles it one chapter at a time, he should be able to narrow it down adequately so that he can find the tricky beast, but his CSS, etc., was fine. His issue is separate and apart, albeit highly coincidental, to ours. Hitch |
|
07-22-2013, 10:41 PM | #17 |
Grand Sorcerer
Posts: 27,465
Karma: 192992430
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
Don't feel too bad. I had some insight into the font embedding issue (if not the funky "solution") from another thread. It IS quite convoluted. No harm, no foul.
|
07-23-2013, 02:47 AM | #18 |
Wizard
Posts: 4,520
Karma: 121692313
Join Date: Oct 2009
Location: Heemskerk, NL
Device: PRS-T1, Kobo Touch, Kobo Aura
|
If you have a linux machine up and running you can try the 'zipinfo' program to see which compression methods are used for a Sigil ePUB and a WinRAR pseudo-ePUB. Perhaps that would help to see if there is a difference.
It would not be a solution of course, but might provide more information. |
07-23-2013, 04:13 AM | #19 | |
Bookmaker & Cat Slave
Posts: 11,447
Karma: 157030631
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Quote:
The other...man, who knows. This is seriously hinky Fu, submitting "unsafe at any speed" ePUBs, but....for this week, until I can clear out everything we have in-house that has Type1s, it's the solution du jour. What's interesting is we had some inklings of this (no CS Lewis cracks, guys!), not about fonts, but about SRL's (Start Reading Locations) because we've had to rig together some unzipped--zipped--ePUB'ed files, also imperfect, to solve THAT problem, as well, in the last month or so. Something is definitely "up" at KDP, and whilst it may be helping the DIY'ers, it's certainly not helping the rest of us. Just my $.02, FWIW. Tox: I have a linux box around here, but I'll have to dig it out and see what I have running on it. My assistant has a linux laptop but her sys resources are very limited. Thanks, guys, Hitch |
|
07-23-2013, 08:58 AM | #20 |
Grand Sorcerer
Posts: 12,119
Karma: 73448614
Join Date: Nov 2007
Location: Toronto
Device: Nexus 7, Clara, Touch, Tolino EPOS
|
Zipinfo is also available for Windows... See http://www.info-zip.org/
In theory it's available from ftp://ftp.info-zip.org/pub/infozip/win32/ but Chrome seems to have issues with this site, refusing to show me any links. Other FTP tools seemed to work. unz600xn.exe is the desired file for windows. When executed (I'd suggest from the command line) it will self-extract the various components of the unzip component of the info-zip project. By default it seems not to create an executable for zipinfo, however if you just either rename unzip.exe to zipinfo.exe or copy unzip.exe to zipinfo.exe it will function as the zipinfo command. |
07-23-2013, 12:51 PM | #21 | |
Bookmaker & Cat Slave
Posts: 11,447
Karma: 157030631
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Quote:
Thanks, Peter! Hitch |
|
07-23-2013, 03:59 PM | #22 |
Sigil developer
Posts: 1,275
Karma: 1101600
Join Date: Jan 2011
Location: UK
Device: Kindle PW, K4 NT, K3, Kobo Touch
|
Do you have a very cut down test file that you can upload here in both the Sigil.epub and the WinRAR epub formats?
|
07-23-2013, 05:11 PM | #23 | |
Bookmaker & Cat Slave
Posts: 11,447
Karma: 157030631
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Quote:
Thanks, Hitch |
|
07-26-2013, 05:35 PM | #24 |
Grand Sorcerer
Posts: 27,465
Karma: 192992430
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
Just a followup on zip methods: (using zipinfo)
The main differences between the archive that Sigil creates and that WinRar creates (using default settings) is that Sigil treats most files as text (no extra field) and WinRar treats them all as binary (with an extra field). Both treat the font files as binary. Both use the Deflate method, but where Sigil uses maximum compression, WinRar uses normal compression (by default). The WinRar archive shows a zip version of 3.1 on a "fat" system ... where the Sigil archive shows a zip version of 0.0 on an "ntf" system (using a Windows Vista platform: Sigil 0.7.2 and WinRar 4.20). WinRar also stores the actual directories in the archive where Sigil does not. Best Guess?? The Maximum Deflate compression on the font files in Sigil could possibly be the deal-breaker on these type of fonts (wouldn't know why at all). You could probably test that fairly easily by creating your WinRar zip file using the "maximum" deflate method and see if it fails your KDP test after the MOBI is built from it. Haven't started picking apart the MOBI files built from the two different archives yet. (Attaching the zip info output for each archive) Last edited by DiapDealer; 07-26-2013 at 05:37 PM. |
07-26-2013, 08:14 PM | #25 |
Guru
Posts: 688
Karma: 150000
Join Date: Feb 2010
Device: none
|
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 |
07-26-2013, 11:07 PM | #26 | |
Bookmaker & Cat Slave
Posts: 11,447
Karma: 157030631
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Quote:
Well, there are some confluences of differing events/bugs here, so, firstly, we have:
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 |
|
07-27-2013, 12:17 AM | #27 | |||
Guru
Posts: 688
Karma: 150000
Join Date: Feb 2010
Device: none
|
Quote:
Quote:
Quote:
I'm getting the impression that there are several separate issues.
The previewer problem suggests that the previewer is displaying the "pre-step-6" file before it gets trashed. I wonder what kind of processing goes on after step 6? Could it have to do with applying DRM? Seems to me it has to be a bug in KDP. Hopefully it can be avoided by not using Type1 fonts at all. I'll keep you in my prayers. Albert |
|||
07-27-2013, 05:12 AM | #28 |
Bookmaker & Cat Slave
Posts: 11,447
Karma: 157030631
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, NookColor. 2 Droid, Oasis, Boox Note2
|
Albert:
Essentially, yes, BUT: Vis-a-vis your 2, "Type1 fonts don't display properly even when present in the final file," no, we've been able to get around that with the faux-ePUB upload method for some of the fonts, e.g., the Com4sans and Gandhi. We have never been able to get Orator to work--it is as you see it in the screenshot. Other than that, yes, your summation seems to be correct. And, yes, I think that Sigil is exonerated, but something hinky is still going on. Some of our ePUBs are hand-made, and don't seem to suffer the same issue. Again, with so much fire-fighting this past week, I have not had adequate time to truly research the root causes. (I was able to help Mathew get to the root of his, but not ours, natch. Phurg.) I hope I'll have time this weekend, after we close the office Saturday evening, to start figuring out the nuts and bolts of the problem. Thanks, Hitch |
08-01-2013, 05:43 PM | #29 |
Addict
Posts: 238
Karma: 1500000
Join Date: Nov 2009
Location: Toronto
Device: Pandigital Novel (Black), T-2 and 3, Nexus 7
|
The key issue with the mimetype file is that it must be the first file and it must be added as stored, not compressed. The easiest way to do this is with the command line (info)zip program. Create the file first by adding the mimetype file with compression 0 (store). Then append all the other files to this zip file with the compression factor of your choice. But the mimetype, must be the first file and it must be stored. I don't know if using WinRAR or other programs will maintain the position of the mimetype as the first. The infozip program does.
I've been planning on writing a program to specifically zip up a directory tree into an epub file. I'll get to it real soon now. I just need to find a cross-pltform zip library for Free Pascal. As I said, real soon now. |
08-01-2013, 11:42 PM | #30 | |
Guru
Posts: 688
Karma: 150000
Join Date: Feb 2010
Device: none
|
Quote:
Code:
$ zip -X0 mybook.epub mimetype $ zip -Xgr mybook.epub META-INF $ zip -Xgr mybook.epub OEBPS But if you did make a stand-alone, cross-platform application that could do this, I'm sure it would be a hit. Of course, the trick might be how to handle non-standard internal structure. ETA: Oh, and as I understand it, the key to solving the fonts problem, currently, is having a "non-standard" epub to pass to KDP. Just adding this to keep us more-or-less on topic, while hopefully passing useful info for the general case of (re)packing an epub. Albert who is possibly the laziest ebook-builder on this forum Last edited by st_albert; 08-01-2013 at 11:47 PM. Reason: an afterthought. |
|
Thread Tools | Search this Thread |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
epubcheck error: mimetype entry missing or not the first in archive | rjnagle | ePub | 23 | 11-16-2013 07:16 AM |
epub mimetype and Content Server | paulfiera | Calibre | 4 | 10-08-2012 12:51 AM |
epub et mimetype | merlinetmoi | E-Books | 4 | 09-10-2010 01:20 AM |
What are opf and mimetype files? | BookCat | Other formats | 6 | 12-15-2009 08:44 PM |