Quote:
Originally Posted by =X=
Big-endian/little-endian is processor specific not OS. Chances are your going to run into little/big endian issues on Linux as well.
|
Er, yes. That was what passes for a joke in my tribe
. There was a preprocessor check for big-endianess in the GPLed LZX compression code I appropriated. Unfortunately neither of the two preprocessor macros it compared are defined by the included set of headers under VC 2008, which meant the condition evaluated to "true".
Quote:
|
BTW I took a look at the LIT file you posted. It looks like the links do not work on the LIT file. I checked the MOBI and they do work.
|
That would be one of the two outstanding issues already mentioned. Until someone figures out the hashing algorithm MSReader uses, links into files with more than six anchors won't work. Any2lit splits the input at page boundaries, which improves matters somewhat, but the book in question still specifies more anchors than will work. I could go a step further in working around the problem by only indexing anchors which are actually the targets hyperlinks, but that's just another layer of complexity / slowness which won't be necessary once we figure out the algorithm.
Quote:
|
Also there are issues with the CSS. I suspect this is because you are converting to ePUB first then to LIT. ePUB uses CSS2 I don't know what version LIT supports, but CSS2 is stricter than CSS1. (Note the CSS problem is caused because CSS2 does not allow styles to start with a number, where this was valid in CSS1)
|
And that would be the other outstanding issue mentioned. Right now neither any2lit or oeb2lit do much of any style/markup pre-processing to produce something more palatable to MSReader. I've got some CSS "flattening" code which should get things most of the way there, but there are still some kinks I need to work out.