View Single Post
Old 01-16-2012, 02:51 PM   #262
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 28,734
Karma: 206739468
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
Quote:
Originally Posted by KevinH View Post
Hi DiapDealer,

I wonder if the new layout has multiple huffdic dictionaries (different for each mobi header in the .mobi). If so, we might need to offset the huffdic section number by the self.start since it could be relative to the specific mobi header and not the same one used for both rawmls.
Code:
               if compression == 0x4448:
                        print "Huffdic compression"
                        reader = HuffcdicReader()
                        huffoff, huffnum = struct.unpack_from('>LL', self.header, 0x70)

                        # need to add this line
			huffoff = huffoff + self.start

                        reader.loadHuff(self.sect.loadSection(huffoff))
                        for i in xrange(1, huffnum):
                                reader.loadCdic(self.sect.loadSection(huffoff+i))
			self.unpack = reader.unpack
That did the trick!

Now then... with the way Amazon is allowing you to define separate CSS files (or special CSS directives) to handle the way the fall-back mobi is styled vs the KF8 styling... there may be some parsing of the actual css files themselves needed to build a fully working epub, ready to be fed back to kindlegen.

In my case, I'm using @import statements to tell kindlegen how to build the two different components, but the new Kindle Publishing Guideline defines four different methods to achieve this.

So my main stylesheet (called by the individual xhtml files) in my source ePub consists only of this:

Code:
@import url(../Styles/mobi7.css) amzn-mobi;
@import url(../Styles/kf8.css) amzn-kf8;
Kindlegen then pulls in those two stylesheets to build the hybrid mobi.

When I unpacked my KF8 mobi, my main stylesheet looked like:
Code:
@import url(XXXXXXXXXXXXXXXX) amzn-mobi;
@import url(kindle:flow:0002?mime=text/css) all;
If that second import statement were:
Code:
@import url(../Styles/style0002.css) all;
the ePub would display using the KF8 stylesheet. But the stylesheet needed to properly build the fall-back mobi appears to have been lost in the shuffle. For all I know, it may not even exist anymore (outside the SRC).

Last edited by DiapDealer; 01-16-2012 at 02:55 PM.
DiapDealer is offline   Reply With Quote