Closed bibimbop closed 11 years ago
So I gather from 114 that this issue was due to operator error and should be closed?
No, no save involved.
Verified. Under investigation.
So what happens is, reflow replaces entire paragraphs. If a paragraph spanned a page, and let ¶ represent the zero-width page boundary position:
Now is the time for all\n
post-processors to come to\n¶
the aid of pgdp.\n
\n
Reflow replaces all three lines with, let us say, two longer lines thus,
Now is the time for all post-processors
to come to the aid of pgdp.\n¶
\n
The stored textCursor that marks the start of page 2 slides down to the end of the inserted text. If the paragraph is long, the displacement is considerable. But run the cursor up to and past the end of the paragraph and you'd see the PNG display flip then.
This is something Qt is doing and I'm not sure I can prevent it. Maybe I can go back and repair it afterward.
Note that when the page breaks between paragraphs, or between lines of a poem or other non-reflowed text, there should be no problem. Hmm, I just better verify that.
Yes, a page break in a poem or /C etc section is fine. It's only when reflow replaces a paragraph that spans a page break that we get a problem.
Hmmm interesting -- doing ^Z undo of the reflow does not fix the page cursors, they are horked.
Closed in error.
A naive solution:
It seems guiguts is doing something like that, using x7f (DEL) as the special character.
It may not be that complicated. When reflowing a paragraph of open text, the proper position of a page break is unchanged by reflow. All reflow does is change some spaces to newlines and vice versa, the count of characters doesn't change. If there is a page break at offset P (all a textCursor is, is an integer offset P that Qt maintains across edits), the page break is still at offset P after reflow. So for the common case all I have to do is: (a) note which textCursors in the page break list fall within the current paragraph -- there will be 0, 1 or rarely more than 1 of them; (b) and note their current position values P; (c) after reflow, Qt has incremented them by the size of the inserted paragraph but I just reset them to their original P values.
But we also have /Q/R/P/C/* sections where we are adding spaces to implement F and L margins. In these cases the textCursor should be reset to P+S where S is the number of margin spaces inserted between the start of the para and P. The arithmetic could get rather hairy here. Especially when I think how we permit re-re-reflowing text changing the margins each time. So sometimes F and L are actually negative and we take spaces away during reflow.
Oh, and tables. Let's just give tables up as a lost cause. Page break in a table? Tough.
Hmmm, maybe the special marker route would be easier. Since this is Unicode, 200C the Zero Width Non Joiner might be appropriate.
Tables are not supported but everything else is ok now.
Much better but still not right.
I tested on the same book. Everything is correct except the last 2 pages where the marker is exactly one line below.
The very last ppqt tag is /* ... */. If I change them to /Q .. Q/ then everything is fine.
Here a copy of my files: https://dl.dropbox.com/u/94763902/prostitution5/projectID490fe6a7a5ef0-PP.zip The project is there: http://www.pgdp.net/c/project.php?id=projectID490fe6a7a5ef0
(note that this file has now /Q Q/ at the end, so change it back to /* */ to test).
ca89f44. Bad practice: also fixes a bug in poetry line number insertion and adds code to reposition to the top of the reflowed area after reflow.
This specific problem -- that page markers get misplaced during text reflow -- was fixed by the commits referenced above. There is an underlying general problem which raised its ugly head in #147. This bug as written was fixed. #147 remains open, see there for more details.
If I have a text perfectly in sync with the pictures and I reflow the text, then the page markers move between paragraphs. Depending on how long the paragraph is, the displayed picture can be several pages away from where the cursor is.