Quote:
Originally Posted by kovidgoyal
Having specialised tools for every format quickly leads to insanity. Instead calibre takes the approach that you write your HTML once and it will do its best to render it as faithfully as possible in all the formats.
|
And I think that's a good approach. But my needs here are a bit different. I'm not trying to create a mobipocket file from my custom HTML, all I want is minimally change the HTML (or whatever) that is already in the mobipocket file. Maybe the mobipocket file has unsupported tags, or unclosed elements... but I don't care, I don't want them corrected (that's good in general, but that's not what I want now, I mean).
See, with ePUB is easy. I can unzip the .epub file, change "black" to "white" and zip everything again, and I don't care whether or not the XHTML validates or CSS classes are undefined. Well, I was thinking that it would be good to be able to do the same with mobipocket files, if you see what I mean.
Of course, it's your program and you do what you see fit
I just thought that since there are already programs that can parse and create mobipocket files, it shouldn't be too hard to have a program that blindly unpacks and packs mobipocket files.
But anyway, I'm still confused that mobi->oeb->mobi->oeb generates such a "mess". Maybe the mobi->oeb conversion is more or less lossless, but then oeb->mobi tries to fix the HTML? I thougt that mobi->oeb would already fix things so that the subsequent oeb->mobi->oeb would be rather transparent.