View Single Post
Old 03-23-2012, 11:55 AM   #11
Yoths
Enthusiast
Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.Yoths is as sexy as a twisted cruller doughtnut.
 
Posts: 30
Karma: 15142
Join Date: Sep 2010
Device: SONY PRS-T1
snarkophilus
That's not a tease! Your post helped me a lot!

To the decryption details:

I figured out the following rules:
- Nodes which type is not "Element" or "Text" are ignored
- Outside of the <html> node, numbers after slash represent the count of first level children
- Inside of the <html> node and outside of an <p> node, numbers after slash represent the count of first level children and their "inner xml" blocks (or simply the double count of first level children)
- Inside of the <html> node and inside of an <p> node, numbers after slash represent the count of first level children
- The number after colon is byte offset in utf8-encoded text node, but if the text contains Windows formated line breaks (\r\n), they must be counted as one character insted of two.


Sometimes I've seen the following behavior:
- If you select text at the begin of an paragraph, not the corresponding text node with offset 0 is pointed but the parent node.
- If you select text at the end of an paragraph, not the corresponding text node with the corresponding offset is pointed but the next node.
- If you select text at the end of the last paragraph of the book, not the corresponding text node with the corresponding offset is pointed but the not existing (!!!) node behind the last one.

Last edited by Yoths; 03-26-2012 at 08:54 AM.
Yoths is offline   Reply With Quote