View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001037 | Scribus | Scripter | public | 2004-09-05 17:19 | 2011-07-02 13:05 |
| Reporter | Assigned To | subik | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | x86 Linux | OS | Fedora Core | OS Version | 1 |
| Product Version | 1.2.1cvs | ||||
| Summary | 0001037: GetTextLength returns 0 for non-empty frame | ||||
| Description | During the development of the script refrenced in bug 0001036, a rather odd problem was encountered. The script looks at the return value of GetTextLength to decide when to stop creating pages and frames, as the linked text box it creates on a page will have text length zero if the last text box had no text that needed to spill. The script would run for three to five pages before terminating early - reporting that a text frame was empty when it was quite patently full of text and had a splill box. Considerable further testing and checking leads me to belive that it's not a bug in my script, but in Scribus. GetTextLength appears to return zero on a frame that should not be empty and is not empty when the script completes. GetText returns "" too. The number of pages generated before termination varies, and is smaller on slower machines. It looks like there might be some form of race between the Python script and the Scribus code doing the reflowing of the frame contents. I wrote another script for the other bug that scans through a generated document and unlinks all the frames while saving and restoring their contents. This script also sees the frames as empty if run immediately after the document is created by the first script. If you run the unlinker as part of the first script, you'll get blank, empty frames after about page 5. If you run it after the creator script finishes and scribus recovers from the experience, you'll get a full document full of unlinked text frames with their orignal, pre-unlinking contents (well, plus a bit extra spilling off due to the hacky way the unlinker had to be written). Looking at this, my opinion is that either I'm missing something important with my script, or GetTextLength is being called before the frame contents have been updated after the LinkTextFrames call. See the procedure below for details. | ||||
| Steps To Reproduce | (1) Download scripts 'odyssey.py' and 'odyssey_unlink.py' as well as the file 'odyssey.txt' from bug 0001036. Place all three into a directory and cd into it. (2) Read the scripts to make sure they won't harm your system by incompetence or malice. Failure to do so is your problem, not mine. I assure you they're designed to be utterly harmless as can be, but can't make any guarantees on incompetence. (2a) Edit the script and ensure that use_termination_hack is set to False and unlink_after_create is also set to False. (3) Launch scribus from the directory you saved the downloaded files into. (probably not required, but let's do it to make sure). (4) Script -> Execute Script, choose 'odyssey.py'. (5) In the resulting file dialog, choose 'odyssey.txt' from wherever you saved it. It's probably already visible if you followed the instructions. (6) Wait for the script to complete. It'll inform you of what it's doing using the status bar and progress bar. (7) Look through the resulting document. Note that it's only three to six pages long and the last frame has a LOT of text needing to spill. Note that the script has created a frame on the last page that shows the output of GetTextLength() that caused it to terminate - zero. Note that the frame contents are not zero length. (8) Edit the script file and in the configuration section set use_termination_hack to True. I recommend you set termination_hack_max_pages to about 10 to start with, as it'll make things a reasonable speed. Save your changes. (9) Run the (modified) script again as per the procedure already described, starting at (3) (or (2) if you're feeling particularly paranoid :-P). (10) Note that the number of pages you asked for have been generated. (11) Edit the script file again and set unlink_after_create to True. use_termination_hack should still be True. Rerun the script as per (3). (12) Note that the resulting document has empty frames after quite an early page (page 3 is the first blank one on my system) and that the script has informed you that GetTextLength on these frames returned zero. (13) Edit the odyssey.py again (getting used to this aren't you?) and set create_after_unlink back to False. (14) Rerun the script as per (3). (15) Note that like before it took forever for Scribus to recover. (16) Run the odyssey_unlink.py script by choosing Script -> Execute Script. It will run without further user interaction, but will keep the progress bar and status bar up to date. (17) Note that the document now has all frames unlinked, containing their original contents (and some spill due to the way the unlinker had to be written). | ||||
| Additional Information | If this is a bug in my script, it's a mighy impressive bug. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
I need to re-test this bug, but given that Subik has kindly added spill detection, it's less of a problem now. Well, unless it also affects spill detection, which is actually quite likely. I'm not fairly certain it's due to the way text reflow and redraw are intertwined in Scribus. With luck it will be fixed in the pageitem refactor. It's probably impractical to fix without that, since a workaround would involve redrawing the frames - introducing severe speed problems. |
|
|
This bug is still present. I don't expect it'll be possible to fix it until after the pageitem/scribusview refactor, when text reflow is sane. |
|
|
Craig, did you check it with 1.3.4cvs? Maybe there are some NLS affected changes. |
|
|
Fixed/No change required in current 1.4.0svn. Behavior of getTextLength() has changed and will return the length of underlying story for any frame of a text chain, ie the value returned will be the same for all frames of a text chain. One check if a specific frame overflows with textOverflows() functions. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-09-05 17:19 |
|
New Issue | |
| 2004-09-06 16:22 |
|
Category | Documentation => Scripter |
| 2004-09-06 16:22 |
|
View Status | @0@ => public |
| 2004-09-06 16:22 |
|
Description Updated | |
| 2004-09-06 16:22 |
|
Steps to Reproduce Updated | |
| 2004-10-19 05:53 |
|
Relationship added | related to 0001036 |
| 2004-10-19 20:16 | subik | Status | new => assigned |
| 2004-10-19 20:16 | subik | Assigned To | => subik |
| 2004-12-08 15:59 |
|
Relationship deleted | related to 0001036 |
| 2004-12-08 15:59 |
|
Relationship added | related to 0001036 |
| 2005-02-09 05:24 |
|
Note Added: 0003669 | |
| 2005-03-23 10:06 |
|
Note Added: 0003955 | |
| 2005-08-03 15:45 |
|
Relationship added | related to 0002376 |
| 2007-02-01 12:17 | subik | Note Added: 0015064 | |
| 2011-07-02 13:05 | jghali | Note Added: 0026511 | |
| 2011-07-02 13:05 | jghali | Status | assigned => resolved |
| 2011-07-02 13:05 | jghali | Resolution | open => fixed |
| 2011-07-02 13:05 | jghali | Status | resolved => closed |
