View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010722 | Scribus | Import / Export | public | 2012-05-29 07:18 | 2012-07-10 05:22 |
| Reporter | Frank_Cox | Assigned To | cezaryece | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Platform | x86_64 | OS | Linux | OS Version | Centos 6 |
| Product Version | 1.4.1 | ||||
| Summary | 0010722: Large odt import into linked frames with columns appears to run forever | ||||
| Description | We have found what appears to be a regression in importing text into multiple text frames with columns. We have a newspaper layout which has a five-columns-across layout that extends through between thirty and forty pages. We have one large text box on each page, each with five columns, and each one linked to the previous page and the next page. With Scribus 1.3.5 we could import an ODT file into a 34 page paper in about one minute. With Scribus 1.4.1 it takes about ten minutes to import the ODT file into a 28 page layout, and a 30-plus page layout never seems to finish. Since this worked fine with Scribus 1.3.5, it appears that a bug has crept into the newer version. | ||||
| Steps To Reproduce | Load testlayout.sla into Scribus 1.4.1 Right-click on the text frame marked "IMPORT TEST.ODT INTO THIS TEXT FRAME" Select "Get Text" Select test.odt to import Wait | ||||
| Additional Information | This issue can be worked around. Instead of importing test.odt into the existing text frame, delete the text frame, create a new text frame, importing test.odt into that frame, then add the columns to the frame and link it to the remainder of the paper. It also works if you add the columns to the frame before importing the odt but the import takes significantly longer. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
|
|
|
Hmm... on my QuadCore importing ODT takes about 5 seconds. Long, but it end at least. I see another issue - working with text in first frame is terrible - all operations takes almost same time - about 5 seconds. I am almost sure that it is issue of layouting whole text in linked frames. I will try to investigate what we can do with that. |
|
|
And maybe it is very good example and test case for start thinking about Scribus performance. Layouting of text is computed with double precision and that is probably bottleneck. I think there is no reason for such big computation overload, when in fact users need 1/10 of point, maybe 1/100 of point precision for text. We can rewrite text layout using integer values instead of double. Just lets take internal unit equal to 1/1000 of point (point is about 0.4 mm, so with that new unit we can have 0.0004 mm precision - not enough?). I am sure it can make text operation much faster. As additional benefit we will have much more precisely layouted text as now all overflows have 1 point precision only. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-05-29 07:18 | Frank_Cox | New Issue | |
| 2012-05-29 07:18 | Frank_Cox | File Added: testlayout.tar.bz2 | |
| 2012-05-29 07:29 | cezaryece | Note Added: 0028041 | |
| 2012-05-29 07:42 | cezaryece | Note Added: 0028042 | |
| 2012-07-10 05:22 | cezaryece | Status | new => closed |
| 2012-07-10 05:22 | cezaryece | Assigned To | => cezaryece |
| 2012-07-10 05:22 | cezaryece | Resolution | open => unable to reproduce |
