I am happy to accept patches into KindleUnpack master. Just make sure any changes run properly on both python 2.7 and python 3.4.

And whoever attempts this don't forget to change the metadata stored too. Including the metadata that says there is an HDcontainer in the first place and the extra BOUNDARY metadata, and the extra BOUNDARY section itself as well as the HDContainer and its sections

I strongly recommend looking at the output of DumpMobiHeader latest version to see the metadata and the extra sections to figure out what all has to go away.

I should clarify: I'm placing code bounty on full-blown, proper Pull Request. So with KevinH blessing it can be merged with KindleUnpack codebase and be useful for the whole community.

Additionally: Can anybody confirm if PW3/Voyage use HD container at all? Last time I checked only Kindle Fire family used it.

Manga from Amazon Store is delivered to PW3 as almost empty AZW3 file and all images are in separate AZW6. I can only guess that that AZW6 file is created from HD container of original upload.

If that is true my goal described in my first post might be wrong. In this case HD container should be left alone and all other non-cover images embedded in KF8 should be replaced with Empty_Image/Resource_Placeholder.

Speculations... Only if I would have skills to check it myself :-P When somebody strip HQ container we will see if quality drop. That will answer if HQ container is used at all.

Speculations... Only if I would have skills to check it myself :-P When somebody strip HQ container we will see if quality drop. That will answer if HQ container is used at all.

If you download 'for transfer via USB' for a PW3, you should get a single .azw3 that's equivalent to the azw3/azw6 combination. If the file sizes are similar enough (to indicate that the images in the single azw3 and the azw3/azw6 are the same), you should be able to check with Kindle Unpack which images are getting sent to a PW3.

Sadly this entire corpse cutting not answered my main question: From where Kindle PW3/Voayge read images when we sideload bare KindleGen output with embedded HD container.

EDIT2:
Well. I found reason of bloat. I screwed up EPUB headers. book-type and original-resolution need to be meta name not meta property. I messed that up in last update. With them in place KindleGen don't create HD container at all.

That error happens in python 2.7 when the terminal encoding is not properly set to handle utf-8 characters. It is actually the copyright symbol in the "print" that is the issue.

If you are redirecting the output of the program in any way, python 2.7 is stupid enough to set sys.stdout to None. But that said, there is code in kindleunpack.py that should take care of this case for python 2.7.

That error happens in python 2.7 when the terminal encoding is not properly set to handle utf-8 characters. It is actually the copyright symbol in the "print" that is the issue.

If you are redirecting the output of the program in any way, python 2.7 is stupid enough to set sys.stdout to None. But that said, there is code in kindleunpack.py that should take care of this case for python 2.7.

<snip>

If you have python 3.4 available, could you please test with it to see if it barfs about the same thing?

Thanks,

Kevin

Ah, I've had other issues with the copyright symbol & utf-8...

Just tried it again with both Active Python 3.4.1 & Python.org 3.4.3 - crash.

Is it my understanding that you are saying this is 'supposed' to crash when I redirect output? --because the only way I can get v0.80 to properly execute from the command-line is to redirect output.

To be honest, I am not sure how to best work around it. Your cp437 encoding just has no character that represents the copyright character and therefore any attempt to convert to your encoding from full unicode will fail. I have to look to see if the codec automatic output encoding setting allows for fallback replacement of some sort. I know if I convert each string manually in python, it does allow for fallback replacement but that kind of defeats the whole purpose of using the output codecs for sys.stdout

A better long term solution for you may be to get a shell/terminal program that supports the utf-8 encoding. This is standard on all Linux, and Mac OS X systems. There is code in Kindleunpack that enables the Windows cp equivalent to utf-8 but users must enable that encoding for it to work. I have heard that using the windows cp equivalent to utf-8 causes issues on some older Windows systems. I have no idea how well it works on newer Windows 8.1 or later systems.

Alternatively,you could always use the gui as it provides a full utf-8 terminal scroll pane window.

To be honest, I am not sure how to best work around it. Your cp437 encoding just has no character that represents the copyright character and therefore any attempt to convert to your encoding from full unicode will fail. I have to look to see if the codec automatic output encoding setting allows for fallback replacement of some sort. I know if I convert each string manually in python, it does allow for fallback replacement but that kind of defeats the whole purpose of using the output codecs for sys.stdout

A better long term solution for you may be to get a shell/terminal program that supports the utf-8 encoding. This is standard on all Linux, and Mac OS X systems. There is code in Kindleunpack that enables the Windows cp equivalent to utf-8 but users must enable that encoding for it to work. I have heard that using the windows cp equivalent to utf-8 causes issues on some older Windows systems. I have no idea how well it works on newer Windows 8.1 or later systems.

Alternatively,you could always use the gui as it provides a full utf-8 terminal scroll pane window.

You mentioned a workaround of your own? What is it?

Thanks,

KevinH

Hi Kevin,

No problem - I didn't mean for you to spend so much time on this. Normally I use kindleunpack embedded inside another program I wrote that allows me to automate some text processing tasks, run kindlegen and finally run kindleunpack to split out the mobi8 file. I have each process dumping their output (stdout & stderr) to log files for later review. This still works fine. I ran across the above mentioned bug when I was testing some text processing changes I'd made while running kindlegen.py via command-line without redirecting the output. Anyway after checking everything on my end my first workaround was 'don't do that'. After you told me what was triggering the crash, I edited the code to change the copyright character to (C) in my copy of the code. Works fine now so I'm good. FYI: I've tripped over this problem over the years so tend to go 'kiss' with message text in direct command-line interfaces.