Hi tkeo,
Quote:
Originally Posted by tkeo
I have run your code. It's fine!! Please change to your code although more improvement of the code is required to parse RESC. Be careful to parse comments especially multi-line ones.
|
Please let me know what improvements you think we still need to just *PARSE* the RESC? Please be specific or post a problem testcase and I will be happy to modify it to add that support. I realize that much code must be added after the parsing stage to do the real work so I am just asking about the parsing stage itself.
Edit: Ah, I see tricks can be played using a multiline comment to hide or invalidate a block of tags! So I will have to special case comments even more when parsing to grab everything up to the "-->" no matter how far ahead it is.
If you have an RESCxxxxx.dat file that is very complicated, I would love to have it as a testcase. I won't need the entire book just the RESCxxxxx.dat file. Thanks.
My idea is that we change the parseRESC code to use a loop with yield so we can then create our own RESC iterator. Then using one loop in k8resc we check each tag name sequentially that exists in the RESC, and process the meta data we need building up an epub2 or 3 version on the fly, find the cover info, get the spine attributes, and grab the skelids and any properties associated with them and store all of this away in the k8resc object for later retrieval.
That should handle everything we need correct?
Quote:
|
I prefer to split mobi7 vs mobi8(epub2 and epub3) because the epub2 opf is more similar to epub3 opf than mobi7.
|
The mobi7 is just a much simpler subset of the mobi8 epub2 one. If you want to keep it separate then please do. But I thought you said that splitting out epub3 from epub2 was more important to create fewer ifs and simpler/cleaner code?
I am willing to do whatever you feel is best in the opf code as long as it reduces redundancies and creates simpler code overall.
Thanks!
KevinH