This is the KOReader CREngine fork. It cross-pollinates with the official CoolReader repository at https://github.com/buggins/coolreader, in case you were looking for that one.
70
stars
45
forks
source link
CJK: fix bad ruby drawing on last paragraph line #548
Actually, all inline boxes on the last line of a justified paragraph.
Follow up to c7c6bef9, where I didn't think about light formatting and not all lines going thru alignLine() on the initial opening of a book: these wrong positions would be saved in the cache, and never corrected.
I'm not super confident with this though: modifying stuff fetched from the cache (we never do that), and not explictely updating an existing cache (we also never do that, when this is needed, we fully reload and rebuild the DOM+cache).All the cache memory <=> disk handling/flushing/trashing is still pretty obscure to me, and I'm not sure if implicit cache update can happen (and what happens when it happens :). There is code that can do that, that could be triggered under memory limit pressure, that has caused issues in the past and that I made do a printf("CRE WARNING"), that I think I have never seen printed...I'm also not sure if this code was ever really meant to be used and has been tested, or if it was just remnants of ideas that were never fully implemented.
(The same reason that makes me lukewarm with https://github.com/koreader/koreader/pull/10940.)
But all other solutions I could think of would be to have CJK paragraphs not rendered "light formatting", so making CJK book slowers to open.
(Or, thinking again while writing this - although I may have thought about it, but ruled it out, not sure if and why :/...: we may know it has CJK and inline boxes early, so we could do non-light formatting only in this case - which could still make some book opening unncessarily slow.)
We'll see.
I think I'll go with that sissy safest road.
Actually, all inline boxes on the last line of a justified paragraph. Follow up to c7c6bef9, where I didn't think about light formatting and not all lines going thru alignLine() on the initial opening of a book: these wrong positions would be saved in the cache, and never corrected.
See https://github.com/koreader/koreader/issues/11021#issuecomment-1771537372
I'm not super confident with this though: modifying stuff fetched from the cache (we never do that), and not explictely updating an existing cache (we also never do that, when this is needed, we fully reload and rebuild the DOM+cache).All the cache memory <=> disk handling/flushing/trashing is still pretty obscure to me, and I'm not sure if implicit cache update can happen (and what happens when it happens :). There is code that can do that, that could be triggered under memory limit pressure, that has caused issues in the past and that I made do aprintf("CRE WARNING")
, that I think I have never seen printed...I'm also not sure if this code was ever really meant to be used and has been tested, or if it was just remnants of ideas that were never fully implemented.(The same reason that makes me lukewarm with https://github.com/koreader/koreader/pull/10940.)But all other solutions I could think of would be to have CJK paragraphs not rendered "light formatting", so making CJK book slowers to open.(Or, thinking again while writing this - although I may have thought about it, but ruled it out, not sure if and why :/...: we may know it has CJK and inline boxes early, so we could do non-light formatting only in this case - which could still make some book opening unncessarily slow.)We'll see.I think I'll go with that sissy safest road.Should allow closing https://github.com/koreader/koreader/issues/11021.
This change is![Reviewable](https://reviewable.io/review_button.svg)