Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book Formats > Kindle Formats

Notices

Reply
 
Thread Tools Search this Thread
Old 01-15-2012, 12:44 PM   #256
nickredding
onlinenewsreader.net
nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'
 
Posts: 324
Karma: 10143
Join Date: Dec 2009
Location: Phoenix, AZ & Victoria, BC
Device: Kindle 3, Kindle Fire, IPad3, iPhone4, Playbook, HTC Inspire
Using the latest to unpack a KF8 generated by kindlegen from an OEB generated by calibre, I get a trap in mobi_k8proc.py/K8processor
Code:
		# read / process other index, looks like a partial <guide> of <toc> but not too sure.  
		# Not being used yet
		othtbl = []
		if self.othidx != 0xffffffff:
			outtbl, ctoc_text = self.mi.getIndexData(self.othidx)
			for [text, tagMap] in outtbl:
				# text, ctoc text, file num
				ctocoffset = tagMap[1][0]
				ctocdata = ctoc_text[ctocoffset]
				othtbl.append([text, ctocdata, tagMap[6][0]])
		self.othtbl = othtbl
That tagMap doesn't have a key 6. Upon investigation it looks like the tagMap key is 3 as in
Code:
		# read / process other index, looks like a partial <guide> of <toc> but not too sure.  
		# Not being used yet
		# KF8: tagMap[6] key error, think it's tagMap[3]
		othtbl = []
		if self.othidx != 0xffffffff:
			outtbl, ctoc_text = self.mi.getIndexData(self.othidx)
			for [text, tagMap] in outtbl:
				# text, ctoc text, file num
				ctocoffset = tagMap[1][0]
				ctocdata = ctoc_text[ctocoffset]
				othtbl.append([text, ctocdata, tagMap[3][0]])
##				othtbl.append([text, ctocdata, tagMap[6][0]])
		self.othtbl = othtbl
which works because the info in question is the masthead coordinates. Following is the console output from the corrected code
Code:
0 Masthead Image
name length is  9
15 image/jpg
IndexCount is 1
TagTable: [(1, 1, 1, 0), (2, 1, 2, 0), (3, 1, 4, 0), (0, 0, 0, 1)]
parsed INDX header:
len C0 nul1 0 type 1 gen 0 start D0 count 1 code FFFFFFFF lng FFFFFFFF total 0 ordt 0 ligt 0 nligt 0 nctoc 0
208 1
>>tagMap
{1: [0], 2: [1], 3: [15]}
masthead
other table: text_type, ctoc data, file number
[['masthead', 'Masthead Image', 15]]
I added the >>tagMap dump investigating this.
nickredding is offline   Reply With Quote
Old 01-15-2012, 01:20 PM   #257
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,506
Karma: 5433350
Join Date: Nov 2009
Device: many
Hi Nick,

Great catch! We currently do not make use of the othtbl (guide?) elements. That said, it is nasty they changed the tag keys on us.

Exactly which version of kindlegen are you using? Mine reports:

./kindlegen

**************************************************
* Amazon.com kindlegen(MAC OSX) V2.3 build 36043 *
* A command line e-book compiler *
* Copyright Amazon.com 2011 *
************************************************** *

Are you using an earlier or later version? Were these guide elements in the original? If the same version, perhaps we simply have to support both tags and that they indicate something slightly different.

I will change the code to support either for the moment until we learn more.


Quote:
Originally Posted by nickredding View Post
Using the latest to unpack a KF8 generated by kindlegen from an OEB generated by calibre, I get a trap in mobi_k8proc.py/K8processor
Code:
		# read / process other index, looks like a partial <guide> of <toc> but not too sure.  
		# Not being used yet
		othtbl = []
		if self.othidx != 0xffffffff:
			outtbl, ctoc_text = self.mi.getIndexData(self.othidx)
			for [text, tagMap] in outtbl:
				# text, ctoc text, file num
				ctocoffset = tagMap[1][0]
				ctocdata = ctoc_text[ctocoffset]
				othtbl.append([text, ctocdata, tagMap[6][0]])
		self.othtbl = othtbl
That tagMap doesn't have a key 6. Upon investigation it looks like the tagMap key is 3 as in
Code:
		# read / process other index, looks like a partial <guide> of <toc> but not too sure.  
		# Not being used yet
		# KF8: tagMap[6] key error, think it's tagMap[3]
		othtbl = []
		if self.othidx != 0xffffffff:
			outtbl, ctoc_text = self.mi.getIndexData(self.othidx)
			for [text, tagMap] in outtbl:
				# text, ctoc text, file num
				ctocoffset = tagMap[1][0]
				ctocdata = ctoc_text[ctocoffset]
				othtbl.append([text, ctocdata, tagMap[3][0]])
##				othtbl.append([text, ctocdata, tagMap[6][0]])
		self.othtbl = othtbl
which works because the info in question is the masthead coordinates. Following is the console output from the corrected code
Code:
0 Masthead Image
name length is  9
15 image/jpg
IndexCount is 1
TagTable: [(1, 1, 1, 0), (2, 1, 2, 0), (3, 1, 4, 0), (0, 0, 0, 1)]
parsed INDX header:
len C0 nul1 0 type 1 gen 0 start D0 count 1 code FFFFFFFF lng FFFFFFFF total 0 ordt 0 ligt 0 nligt 0 nctoc 0
208 1
>>tagMap
{1: [0], 2: [1], 3: [15]}
masthead
other table: text_type, ctoc data, file number
[['masthead', 'Masthead Image', 15]]
I added the >>tagMap dump investigating this.
KevinH is offline   Reply With Quote
Advert
Old 01-15-2012, 05:26 PM   #258
nickredding
onlinenewsreader.net
nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'nickredding knows the difference between 'who' and 'whom'
 
Posts: 324
Karma: 10143
Join Date: Dec 2009
Location: Phoenix, AZ & Victoria, BC
Device: Kindle 3, Kindle Fire, IPad3, iPhone4, Playbook, HTC Inspire
Same build (36043), but I was processing OEB output from calibre, and the masthead was certainly in the source OEB data (it was output by a news recipe).
nickredding is offline   Reply With Quote
Old 01-15-2012, 05:37 PM   #259
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,506
Karma: 5433350
Join Date: Nov 2009
Device: many
Hi Nick

That means the code must support both. I will add a field to the othtbl for tag 3 (or NOne) and tag 6 (or None) so that both are recorded in case there are any ebooks with both types of tags.

Thanks,

KevinH
KevinH is offline   Reply With Quote
Old 01-16-2012, 01:25 PM   #260
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: 27,465
Karma: 192992430
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
I'm getting errors unpacking a KF8/MOBI I built with Huffdic compression using the new Kindlegen 2.3(36043). I'm using the most recent mobi_unpack (from this post).

Code:
MobiUnpack 0.33
  Copyright (c) 2009 Charles M. Hannum <root@ihack.net>
  With Additions by P. Durrant, K. Hendricks, S. Siebert, fandrieu and DiapDealer.
Unpacking Book...
Palm DB type:  BOOKMOBI
Mobi Version:  6
Codec:  utf-8
Title:  Shahnameh
Huffdic compression
Mobi Ebook uses the new K8 file format
Mobi Version:  8
Codec:  utf-8
Title:  Shahnameh
Huffdic compression
Traceback (most recent call last):
  File "mobi_unpack.py", line 864, in <module>
    sys.exit(main())
  File "mobi_unpack.py", line 855, in main
    unpackBook(infile, outdir)
  File "mobi_unpack.py", line 559, in unpackBook
    mh = MobiHeader(sect,i+1)
  File "mobi_unpack.py", line 222, in __init__
    reader.loadHuff(self.sect.loadSection(huffoff))
  File "C:\Users\***\Downloads\mobi_unpack_update\mobi_uncompress.py", line 42, in loadHuff
    raise unpackException('invalid huff header')
NameError: global name 'unpackException' is not defined
Besides the fact that the unpackException class doesn't exist for error handling... mobi_unpack appears to think the huff header is invalid. The mobi otherwise performs as expected with Kindle previewer (simulating Kindle Fire) and a standalone Kindle 2.

That's the second time through on the KF8 MobiHeader parse, when trying to build the Huffdic reader for the KF8 portions. It looks like the huff header for the KF8 portions is either different or in a different location.

I'm looking, but I thought I'd let someone else know as well.

Last edited by DiapDealer; 01-16-2012 at 01:51 PM.
DiapDealer is offline   Reply With Quote
Advert
Old 01-16-2012, 01:54 PM   #261
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,506
Karma: 5433350
Join Date: Nov 2009
Device: many
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.

I will add the exception code back to the mobi_uncompress as well.

Thanks!

Kevin

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
Quote:
Originally Posted by DiapDealer View Post
I'm getting errors unpacking a KF8/MOBI I built with Huffdic compression using the new Kindlegen 2.3(36043). I'm using the most recent mobi_unpack (from this post).

Code:
MobiUnpack 0.33
  Copyright (c) 2009 Charles M. Hannum <root@ihack.net>
  With Additions by P. Durrant, K. Hendricks, S. Siebert, fandrieu and DiapDealer.
Unpacking Book...
Palm DB type:  BOOKMOBI
Mobi Version:  6
Codec:  utf-8
Title:  Shahnameh
Huffdic compression
Mobi Ebook uses the new K8 file format
Mobi Version:  8
Codec:  utf-8
Title:  Shahnameh
Huffdic compression
Traceback (most recent call last):
  File "mobi_unpack.py", line 864, in <module>
    sys.exit(main())
  File "mobi_unpack.py", line 855, in main
    unpackBook(infile, outdir)
  File "mobi_unpack.py", line 559, in unpackBook
    mh = MobiHeader(sect,i+1)
  File "mobi_unpack.py", line 222, in __init__
    reader.loadHuff(self.sect.loadSection(huffoff))
  File "C:\Users\***\Downloads\mobi_unpack_update\mobi_uncompress.py", line 42, in loadHuff
    raise unpackException('invalid huff header')
NameError: global name 'unpackException' is not defined
Besides the fact that the unpackException class doesn't exist for error handling... mobi_unpack appears to think the huff header is invalid. The mobi otherwise performs as expected with Kindle previewer (simulating Kindle Fire) and a standalone Kindle 2.

That's the second time through on the KF8 MobiHeader parse, when trying to build the Huffdic reader for the KF8 portions. It looks like the huff header for the KF8 portions is either different or in a different location.

I'm looking, but I thought I'd let someone else know as well.

Last edited by KevinH; 01-16-2012 at 01:59 PM. Reason: added a potential fix
KevinH is offline   Reply With Quote
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: 27,465
Karma: 192992430
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
Old 01-16-2012, 04:25 PM   #263
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,506
Karma: 5433350
Join Date: Nov 2009
Device: many
Hi All,

I have updated my last zip archive to mobi_unpack_update2.zip which now supports guide elements, and has bug fixes for missing tags in some files (Nick's bug report) and improper setting of the section to load for the HuffDic table (DiapDealer's bug report).

Have fun!
KevinH is offline   Reply With Quote
Old 01-16-2012, 04:29 PM   #264
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,506
Karma: 5433350
Join Date: Nov 2009
Device: many
Hi DiapDealer,

I will try to modify the code in mobi_html.py to find and fix kindle:flow references inside url references in the flowparts (css pieces).

That may help. Once we get that going you can see what else needs to be fixed. It would help if you could create a test case for me to play with.

Take care,

KevinH

Quote:
Originally Posted by DiapDealer View Post
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).
KevinH is offline   Reply With Quote
Old 01-16-2012, 05:09 PM   #265
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,506
Karma: 5433350
Join Date: Nov 2009
Device: many
Hi DiapDealer,

I created my own version of what you had. I dumped all of the raw pieces and unfortunately the mobi7.css is completely gone. It gets eaten up when creating the older mobi and nothing of it exists in the K8 part.

I am not sure how to deal with that except to remove the bad XXXXXXX url line from the stylesheet. Seems sad. I guess the only way to deal with this is to use the kindlegensrc.zip but that may not be available.

It would be useful to create a mobi adder python script which joins the best older mobi to the best K8 mobi. This should be doable.
KevinH is offline   Reply With Quote
Old 01-16-2012, 05:24 PM   #266
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: 27,465
Karma: 192992430
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
Quote:
I created my own version of what you had. I dumped all of the raw pieces and unfortunately the mobi7.css is completely gone. It gets eaten up when creating the older mobi and nothing of it exists in the K8 part.
I sort of suspected that. Oh well.

Quote:
It would be useful to create a mobi adder python script which joins the best older mobi to the best K8 mobi. This should be doable.
I have a feeling something like that would come in very handy.
DiapDealer is offline   Reply With Quote
Old 01-17-2012, 01:07 PM   #267
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,506
Karma: 5433350
Join Date: Nov 2009
Device: many
Hi,

Fixed a few more bugs and now mobi_unpack_update3.zip is now there. See my previous post (where update2 was posted).

KevinH
KevinH is offline   Reply With Quote
Old 01-17-2012, 06:12 PM   #268
PeterHatch
Member
PeterHatch began at the beginning.
 
Posts: 10
Karma: 10
Join Date: Jan 2012
Device: Kindle
Quote:
Originally Posted by KevinH View Post
It would be useful to create a mobi adder python script which joins the best older mobi to the best K8 mobi. This should be doable.
I've been wondering - I hope Amazon made it so bookmarks, notes, and highlights can be shared between the older and K8 versions of a book, but I've no idea how they would have made that work. If it does work, I'd be concerned about such a script breaking it.

But then, that breaking probably wouldn't be enough to stop me from using such a script.
PeterHatch is offline   Reply With Quote
Old 01-17-2012, 07:49 PM   #269
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: 27,465
Karma: 192992430
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
I made a few minor changes to Kevin's last update (mobi_unpack_update3.zip from post #255)... mostly some changes to the generation of the OPF file. There were a few things concerning metadata that were making epub checkers like Flightcrew bark a little bit.

Also removed some unnecessary Amazon specific attributes that were cluttering up the epub and generating warnings from epub validators.

Hopefully it's building a slightly cleaner epub now. The more KF8 content that gets unpacked, the sooner mobi_unpack can become more accurate/consistent.

I'm currently getting output that's nearly identical to the original source epub (minus the filenames of course).
Attached Files
File Type: zip mobi_unpack_update4.zip (31.4 KB, 357 views)

Last edited by DiapDealer; 01-18-2012 at 09:11 AM.
DiapDealer is offline   Reply With Quote
Old 01-18-2012, 08:31 AM   #270
whoqwerty
Junior Member
whoqwerty began at the beginning.
 
Posts: 7
Karma: 10
Join Date: Dec 2011
Device: kindle touch
Quote:
Originally Posted by DiapDealer View Post
I made a few minor changes to Kevin's last update (mobi_unpack_update3.zip from post #255)... mostly some changes to the generation of the OPF file. There were a few things concerning metadata that were making epub checkers like Flightcrew bark a little bit.

Also removed some unnecessary Amazon specific attributes that were cluttering up the epub and generating warnings from epub validators.

Hopefully it's building a slightly cleaner epub now. The more KF8 content that gets unpacked, the sooner mobi_unpack can become more accurate/consistent.

I'm currently getting output that's nearly identical to the original source epub (minus the filenames of course).
Hello I am getting an error on line 886 in <module> sys.exit<main<>> and
line 886 main, in main, infile, outdir = argv[1:]
value errr"too many values to unpack"
whoqwerty is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Can i rotate text and insert images in Mobi and EPUB? JanGLi Kindle Formats 5 02-02-2013 04:16 PM
PDF to Mobi with text and images pocketsprocket Kindle Formats 7 05-21-2012 07:06 AM
Mobi files - images DWC Introduce Yourself 5 07-06-2011 01:43 AM
pdf to mobi... creating images rather than text Dumhed Calibre 5 11-06-2010 12:08 PM
Transfer of images on text files anirudh215 PDF 2 06-22-2009 09:28 AM


All times are GMT -4. The time now is 02:49 AM.


MobileRead.com is a privately owned, operated and funded community.