View Issue Details

IDProjectCategoryView StatusLast Update
0010722ScribusImport / Exportpublic2012-07-10 05:22
ReporterFrank_Cox Assigned Tocezaryece  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionunable to reproduce 
Platformx86_64OSLinuxOS VersionCentos 6
Product Version1.4.1 
Summary0010722: Large odt import into linked frames with columns appears to run forever
DescriptionWe 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 ReproduceLoad 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 InformationThis 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.
TagsNo tags attached.
Patch

Activities

Frank_Cox

2012-05-29 07:18

reporter  

testlayout.tar.bz2 (391,334 bytes)

cezaryece

2012-05-29 07:29

updater   ~0028041

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.

cezaryece

2012-05-29 07:42

updater   ~0028042

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.

Issue History

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