Lee>We know that the pre-Fire Kindle reader does not support HTML 4 tags, or CSS. Sorry, but I don't know exactly what your prc2html program does. "We" know from mobi_unpack.py and copious net conversations that kf8 actually contains two separate file formats in one: a copy of the oldy moldy "mobi7" file format targeting "pre-current-generation" Kindles [*not* pre-Fire Kindles] and a "mobi8" file format targeting "current-generation" Kindles. Amazon's cloud server supposedly cuts this down on-the-fly and is smart enough to only send that part which is needed by a particular Kindle -- if the kf8 file gets served by Amazon from Amazon. [Don't know what happens if the kf8 gets served *through* Amazon by say a PG customer sending a hypothetical PG kf8 *through* Amazon using say the Amazon "Send to Kindle" desktop program.] Now of the "current-generation" Kindles the reality is only Kindle Fire *currently* has the software to render "mobi8" but Amazon claims they are busily churning away trying to get the updates out to allow "current-generation" Kindles to also render "mobi8" -- but Amazon has not been explicitly explicit about exactly what Kindle models they mean when they say "current-generation" Kindles. Does your prc2html software successfully extract *both* these file formats, or only the "mobi7" part? Now one problem for PG I would think with the "two, two, two formats in one" kf8 packing is that the currently already bloated mobi7 format (assuming one turns off compression, which I think is what PG is currently doing) becomes an even more bloated up (uncompressed) kf8.
Yes, KindleGen doesn't fix the limitations of earlier software, and indeed cannot. It /can/ modify/convert the input in such a way that older software can deal with it, but KindleGen can't make a silk purse out of a sow's ear.
Well, without intended insult but just stating the reality, that's what on some level Marcello's rewrite software attempts to do. There are at least three sources of cruftiness here: 1) The oldy-moldy mobi7 format 2) The oldy-moldy "html" files on PG that PG in practice makes impossible to update -- even for their most popular books 3) Current html writing practice of many people and groups submitting html to PG that is continuing to be written in a needlessly thoughtless way that prevents that html from displaying well on a large portion of PG's customers' devices even though they would only have to change a couple statements in their CSS slightly to make the situation much much better.