02-11-2014, 10:24 AM | #661 | |||
Connoisseur
Posts: 94
Karma: 10
Join Date: Feb 2014
Location: Japan
Device: Kindle PaperWhite, Kobo Aura HD
|
Hi KevinH,
Quote:
On my environment (python 2.7.6 windows 32bit), the minidom is able to parse utf-8 and stored as an Unicode string; re-encoding utf-8 is necessary to use. It is quite confusing for me. (Utf-8 is one of the encodings of unicode, isn't it?) If the minidom stored elements as utf-8 strings, it would be very easy, I think. Quote:
But, now, there are many epub 2 ebooks available but epub3 books are not so popular, and as you mentioned, books basically based on epub2 plus partly included epub3 definition are published from vendors. So, I think, it is not time for creating the pure epub3 version of the KindleUnpack. Quote:
Thanks, tkeo |
|||
02-11-2014, 11:39 AM | #662 |
The Grand Mouse 高貴的老鼠
Posts: 71,510
Karma: 306214458
Join Date: Jul 2007
Location: Norfolk, England
Device: Kindle Voyage
|
I don't have time to join in development, but I think that splitting KindleUnpack into ePub2/ePub3 versions would be a mistake.
Surely we can detect whether a Kindle book contains stuff that requires ePub 3, and only output an ePub 3 when that is present? Even a command-line switch between ePub 2 and 3 output would be preferable to my mind. I would also mention that KindleUnpack should be producing something that can be run back through KindleGen and produce the same file as the original (assuming the same KindleGen version is used). This is a great feature that should not be lost in trying to produce an ePub-like output as well. |
Advert | |
|
02-11-2014, 01:00 PM | #663 |
Grand Sorcerer
Posts: 27,552
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
It would be pretty hard to determine if the source material was ePub3 or just ePub2 with elements of ePub3/CSS3. Or indeed whether an ePub was even used at all to create the Kindlebook. It's all getting pretty gray.
Surely, the OPF (and maybe NCX vs NAV document) is where the only real differences lie between outputting ePub3 as opposed to ePub2, right? We do nothing now (to my knowledge) to filter out any xhtml/css that's not ePub2 "compliant", so I wouldn't think it would out of the question to have two different OPF generation routines and just give the user the option to choose 3 vs 2 based on what they're seeing. Perhaps even the option to forego ePub generation altogether (just the OEBPS output)? EDIT: it occurred to me that we could be trying to push html5 into an xhtml-shaped box at times, though. But that still seems only a matter of leaving off the DTD and xhtml namespace, no? Specific attributes and links are massaged, but the markup itself should come through relatively unscathed--regardless of whether it's xhtml or html5--shouldn't it? Last edited by DiapDealer; 02-11-2014 at 01:16 PM. |
02-11-2014, 07:10 PM | #664 |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
Hi,
It sounds like everyone wants to go with epub2 plus extensions for things supported by Kindlegen. So I will strip out the minidom stuff leaving the re code, add in the 3 or 4 minor bug fixes not yet in his version, add tkeo as one of the authors and produce a KindleUnpack version 0.64 to prevent confusion. It will continue to work as before and produce an epub2 format with his extensions added in. Hope to have something by next week or before. How does that sound? Kevin |
02-12-2014, 09:16 AM | #665 | |
Connoisseur
Posts: 94
Karma: 10
Join Date: Feb 2014
Location: Japan
Device: Kindle PaperWhite, Kobo Aura HD
|
Quote:
Thanks for joining me to the autors. I agree with you: to go with epub2 plus extensions for things supported by Kindlegen, is preferable. I should have named my modifed version as v0.62mod or something like that at first place. Though you have already been fixing the code, I have separeted the code I have written to an individual file 'mobi_k8resc.py' and changed to use re instead of dom. 'mobi_k8proc.py' is reverted to be identical to v0.62. I have made to possible to turn of/off of processing RESC. I will post it to this weekend probably. Thanks, tkeo |
|
Advert | |
|
02-12-2014, 10:34 AM | #666 |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
Hi tkeo,
Wonderful! Thank you. I will wait to get that, add in the missing minor bug fixes and author info and produce a release. Take care, KevinH |
02-16-2014, 08:57 AM | #667 |
Connoisseur
Posts: 94
Karma: 10
Join Date: Feb 2014
Location: Japan
Device: Kindle PaperWhite, Kobo Aura HD
|
KindleUnpack v0.63a
Hi,
I have updated my modifed version of KindleUnpack. From v0.63,
The RESC setcion processing and the cover creation are able to tun on/off by booleans PROC_K8RESC and CREATE_COVER_PAGE respectively. Please remove any part of my modification that is not necssarily nor appropriate in later version. As for the cover page, some spine in RESC has striped tace of it. I tried to create such a mobi, but I couldn't. In my experiment, the cover page is moved to last page insead of striped. I attach a mobi and a src. Although the cover xhtml page is not required in EPUB regulation, I have made insertion of it also, because my primary epub viewer does not show cover image itself. I hoe this version works on any environment. Thanks, |
02-23-2014, 11:09 AM | #668 |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
KindleUnpack V064
Hi All,
Okay, I have integrated a bug fix for full unicode command lines not being properly parsed, and integrated a contributed bug fix to better identify some JPEG files, into tkeo's major changes to support RTL books and to properly parser the RESC and extract more information from the spine. I have also added tkeo to the list of authors and updated the copyright to 2014. Attached is the most up-to-date version of KindleUnpack with all outstanding changes integrated. All testing and bug reports are welcomed especially with some of the new features just added. Please report any issue or problems here. KindleUnpack V064 Thanks, KevinH |
02-23-2014, 12:46 PM | #669 |
Grand Sorcerer
Posts: 27,552
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
Nice work guys!
One quick, persnickety thing: the "title" attribute for the new (experimental) cover-page resource item in the guide section of the OPF is currently being set to the actual full title of the ebook. Probably not going to cause any problems that I know of (not sure the attribute is used by devices/apps, to tell the truth), but it doesn't really make sense to put it there either. It can be quite long at times, and who knows how long it will before something in there(a character perhaps) borks the processing. Something like "Cover" should suffice for that particular reference item's "title" in all cases. |
02-23-2014, 01:10 PM | #670 |
The Grand Mouse 高貴的老鼠
Posts: 71,510
Karma: 306214458
Join Date: Jul 2007
Location: Norfolk, England
Device: Kindle Voyage
|
|
02-23-2014, 04:27 PM | #671 | |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
Hi DiapDealer,
Quote:
I will look into it. I can't quite tell from your post... Is this tkeo's generate an xhtml cover page file name or the general opf entry for the generated file or only the guide entry itself in the opf? KevinH |
|
02-23-2014, 06:00 PM | #672 | |
Grand Sorcerer
Posts: 27,552
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
Quote:
Like I said, not a big deal at all (at least I don't think so). It just seems like overkill for that attribute's value to be the entire title of the ebook. EDIT: Found it in mobi_k8resc.py. Something to the tune of the patch/diff file attached (had to change the file's extension to .txt so the forum would accept it) is what I had in mind. Last edited by DiapDealer; 02-23-2014 at 07:35 PM. |
|
02-23-2014, 08:41 PM | #673 | |
Sigil Developer
Posts: 7,645
Karma: 5433388
Join Date: Nov 2009
Device: many
|
Hi DiapDealer,
Wonderful! Thanks for the patch. I will add it for the next release. Nice Work! KevinH Quote:
|
|
02-24-2014, 06:33 AM | #674 | |
Connoisseur
Posts: 94
Karma: 10
Join Date: Feb 2014
Location: Japan
Device: Kindle PaperWhite, Kobo Aura HD
|
Quote:
I have written the code base on the description of, https://wiki.mobileread.com/wiki/Ebook_Covers. It seems that the required attribute in the reference tag for cover page is type="cover" and the title is not required. I'm not sure what is the most proper way for a cover page. Thanks, |
|
02-24-2014, 08:35 AM | #675 | |
Grand Sorcerer
Posts: 27,552
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
|
Quote:
Just out of curiosity, are you manufacturing the "linear=No" attribute for the created cover page's spine entry? Or is that something that unpacks "as is"? I prefer the somewhat "standard" svg method of creating a cover page, but that's just a personal preference. Feel free to take a look at my hacked-up mobi_k8resc.py file if you're interested at all. I've added a 'borrowed' method to get the necessary dimensions of jpeg, gif, or png images (and removed the 'linear' attribute for my own selfish reasons). Don't feel any pressure to adopt my changes or anything. I don't mind adjusting the "official" codebase to suit my needs. That's how I get my practice. Thanks for your input on the project, by the way. Much appreciated! Last edited by DiapDealer; 02-24-2014 at 08:51 AM. |
|
|
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 | 2 | 06-22-2009 09:28 AM |