Recent posts

#1
Code / Optimisation solution for long...
Last post by phoebe - Today at 02:16:57 PM
Hi everyone,

My first time posting, and I hope this is the right way to go about it.

I started using Scribus with scripting as part of an automation solution and immediately hit the problem that has been mentioned here previously about the linear slow-down when working with long chains of text frames. Each new frame takes longer than the last.

I did some tests to establish that it wasn't related to the page count. Nope, no problem there, even at 500 poges. Then I tried dividing the long text I was using into 4 parts and starting each in a new frame not linked to the previous chunk. That worked as expected. Now the delays were localised into four smaller ramps instead of one long one. Append the text, however, to a previous frame when starting a new spill and the larger linear growth returns.

This seemed likely related to some sort of recursive behaviour. I figured that each time a new frame was added, all the previous ones were marked as needing an update, too, just to be safe. But I'm working on a deterministic layout solution so once a page has been done, it's almost certainly done, minus some potential reflow on the current page when linking to a new page due to widow orphan control or similar. So I just need to find a way to stop the reflow except for the last page when linking its frame to a new one.

Then I remembered, PageMaker had a little thing in its scripting to pause reflow. I think InD might have it too, but I don't recall. I checked the code in Scribus and there definitely isn't anything, so I downloaded the 1.7 source, added it to the scripting API and obviously added a few bits to the main source here and there to implement. Rebuilt on my Mac, and it works perfectly.

With reflow paused the actual chain time over 106 pages is 24x faster. The final page takes 1.86s with reflow on, and 0.06s with it turned off. Average time per page reduces from 0.95s to 0.04s. The solution is 3.3x faster overall, but that's because importing is a massive bottleneck, and I don't yet understand why, so I've separated import time from the results. Also, this was just a txt file. I haven't tried other formats yet, although the solution I'm working on will be using docbook.xlm.

I don't know how to submit this for consideration, and I'm not much of a programmer. I've had a lot of experience with system design, etc, and lots of scripting, but not much c++. I had to use AI to help point me to the right places in the code, so this has not had a proper look over. It just happens to work in my testing, and the changes are very low footprint.

You can use this in a script simply by calling scribus.setReflow(0) to pause reflow, and scribus.setReflow(1) to turn it back on. And it will always turn reflow back on when script execution ends, even if it's in an error or crash. Turning reflow back on during a script will be useful as well to give pages a chance to settle in again, I presume, and to get on with other layout tasks. While that will then trigger a full update to all frames (it does this deliberately anyway, when its state is changed), this only happens once instead of repeatedly, so the time improvements remain.

Super simple, really effective, not sure how to share it except here.

Hope it helps,
Phoebe

Test 1 - Increasing time for each new frame
============================================================
Run: 2026-04-23 12:31:34
Mode: CONTINUOUS
Reflow: enabled (no setReflow)
Trim: 152.4 x 228.6 mm (6" x 9")
Frame: 107.0 x 177.8 mm
Input: ulyssess_small.txt (269582 chars) x 1 iterations

Total pages: 107
Total time: 136.85s
  Import time: 35.20s
  Chain time:  101.58s
  Avg per chain page: 0.9493s
  Fastest chain: page 1 (0.0000s)
  Slowest chain: page 105 (1.8610s)

Sampled pages (10 of 107):
  Page   1: 0.0000s  #
  Page  13: 0.2034s  ##
  Page  25: 0.4450s  ####
  Page  36: 0.5861s  #####
  Page  48: 1.0333s  ##########
  Page  60: 1.0533s  ##########
  Page  72: 1.2571s  ############
  Page  83: 1.3777s  #############
  Page  95: 1.6915s  ################
  Page 107: 1.8068s  ##################

Test 2 - Reflow paused, adding frames to a chain, even a quite long one, always proceeds at the same pace
============================================================
Run: 2026-04-23 12:32:48
Mode: CONTINUOUS
Reflow: paused during build
Trim: 152.4 x 228.6 mm (6" x 9")
Frame: 107.0 x 177.8 mm
Input: ulyssess_small.txt (269582 chars) x 1 iterations

Total pages: 107
Total time: 41.31s
  Import time: 37.02s
  Chain time:  4.22s
  Avg per chain page: 0.0394s
  Fastest chain: page 1 (0.0000s)
  Slowest chain: page 2 (0.0612s)

Sampled pages (10 of 107):
  Page   1: 0.0000s  #
  Page  13: 0.0351s  #
  Page  25: 0.0372s  #
  Page  36: 0.0570s  #
  Page  48: 0.0435s  #
  Page  60: 0.0498s  #
  Page  72: 0.0443s  #
  Page  83: 0.0452s  #
  Page  95: 0.0340s  #
  Page 107: 0.0208s  #

Path file
From: DLS Project
Subject: [PATCH] Add setReflow() API to fix text frame chain performance degradation

Add a `setReflow(enabled)` Python API to let scripts pause
backward invalidation and chain walking during linked frame construction,
reducing the per-page cost.

Reflow is automatically re-enabled when a script finishes (even on crash)
via the finishScriptRun() cleanup path.

Benchmark: 107-page single-chain document (ulyssess_small.txt, 270K chars)
  Before: 101.58s chain time, avg 0.95s/page, slowest page 1.86s (page 105)
  After:    4.22s chain time, avg 0.04s/page, slowest page 0.06s (page 2)
  Total build: 136.85s -> 41.31s (3.3x faster)
  Import time: unchanged (~35s)

diff --git a/scribus/pageitem.cpp b/scribus/pageitem.cpp
index 64e91e7350..fe11cc3d33 100644
--- a/scribus/pageitem.cpp
+++ b/scribus/pageitem.cpp
@@ -1176,11 +1176,14 @@ void PageItem::link(PageItem* nxt, bool addPARSEP)
  }
  }
  invalid = true;
- PageItem* prev = this;
- while (prev->m_backBox && !prev->m_backBox->frameOverflows())
+ if (m_Doc->m_reflowEnabled)
  {
- prev->m_backBox->invalid = true;
- prev = prev->m_backBox;
+ PageItem* prev = this;
+ while (prev->m_backBox && !prev->m_backBox->frameOverflows())
+ {
+ prev->m_backBox->invalid = true;
+ prev = prev->m_backBox;
+ }
  }
  while (nxt)
  {
diff --git a/scribus/pageitem_textframe.cpp b/scribus/pageitem_textframe.cpp
index 3b48782545..b5b9e815a0 100644
--- a/scribus/pageitem_textframe.cpp
+++ b/scribus/pageitem_textframe.cpp
@@ -1177,20 +1177,28 @@ void PageItem_TextFrame::layout()
 // printBacktrace(24);
  if (m_backBox != nullptr)
  {
-// qDebug("textframe: len=%d, going back", itemText.length());
  PageItem_TextFrame* firstInvalid = nullptr;
- PageItem_TextFrame* prevInChain  = dynamic_cast<PageItem_TextFrame*>(m_backBox);
- while (prevInChain)
+ if (m_Doc->m_reflowEnabled)
  {
- if (prevInChain->invalid)
- firstInvalid = prevInChain;
- prevInChain = dynamic_cast<PageItem_TextFrame*>(prevInChain->m_backBox);
+ PageItem_TextFrame* prevInChain  = dynamic_cast<PageItem_TextFrame*>(m_backBox);
+ while (prevInChain)
+ {
+ if (prevInChain->invalid)
+ firstInvalid = prevInChain;
+ prevInChain = dynamic_cast<PageItem_TextFrame*>(prevInChain->m_backBox);
+ }
+ PageItem_TextFrame* nextInChain = firstInvalid;
+ while (nextInChain && (nextInChain != this))
+ {
+ nextInChain->layout();
+ nextInChain = dynamic_cast<PageItem_TextFrame*>(nextInChain->m_nextBox);
+ }
  }
- PageItem_TextFrame* nextInChain = firstInvalid;
- while (nextInChain && (nextInChain != this))
+ else if (invalid)
  {
- nextInChain->layout();
- nextInChain = dynamic_cast<PageItem_TextFrame*>(nextInChain->m_nextBox);
+ PageItem_TextFrame* prevFrame = dynamic_cast<PageItem_TextFrame*>(m_backBox);
+ if (prevFrame)
+ firstChar = prevFrame->m_maxChars;
  }
  // #9592 : warning, BackBox->layout() may not layout BackBox next box
  if (!invalid)
diff --git a/scribus/plugins/scriptplugin/scriptercore.cpp b/scribus/plugins/scriptplugin/scriptercore.cpp
index 92948e67b7..f253ea6b4a 100644
--- a/scribus/plugins/scriptplugin/scriptercore.cpp
+++ b/scribus/plugins/scriptplugin/scriptercore.cpp
@@ -162,6 +162,12 @@ void ScripterCore::finishScriptRun()
  if (!mainWin->HaveDoc)
  return;
 
+ if (!mainWin->doc->m_reflowEnabled)
+ {
+ mainWin->doc->m_reflowEnabled = true;
+ mainWin->doc->invalidateAll();
+ }
+
  mainWin->propertiesPalette->setDoc(mainWin->doc);
  mainWin->contentPalette->setDoc(mainWin->doc);
  mainWin->marksManager->setDoc(mainWin->doc);
diff --git a/scribus/plugins/scriptplugin/scriptplugin.cpp b/scribus/plugins/scriptplugin/scriptplugin.cpp
--- a/scribus/plugins/scriptplugin/scriptplugin.cpp
+++ b/scribus/plugins/scriptplugin/scriptplugin.cpp
@@ -*,* +*,* @@
+ { "setReflow", scribus_setreflow, METH_VARARGS, tr(scribus_setreflow__doc__)},
diff --git a/scribus/scribusdoc.h b/scribus/scribusdoc.h
index 1ce4404326..ac78a8b005 100644
--- a/scribus/scribusdoc.h
+++ b/scribus/scribusdoc.h
@@ -1480,6 +1480,8 @@ public:
  int TotalItems {0};
  PrintOptions Print_Options;
  bool RePos {false};
+ bool m_reflowEnabled {true};
+
  struct BookMa {
  QString Title;
  QString Text;
#2
Features / Re: Native Text Hyperlink Supp...
Last post by Flaxx - Today at 01:50:27 PM
I like to step in here as I just wanted to make a similar proposal - actually not as exhaustive as the OP did.

Our printer wants PDF/X-4 formats + 3mm. We compress embedded bitmaps (max. 300dpi) lossless via ZIP. This works fine obviously. The same brochure, now in pure A4 and max. jpg-compression is used for direct downloads. Unfortunately even the external link (web) function doesn't work in this configuration and we need to use PDF 1.6 in order to have resulting working links being only bound via the frame to a keyword - despite the other mentioned disadvantages.

An internal link-tool would be great.
#3
Showcase / Re: Dracula - An Archival-Insp...
Last post by IanicM - April 22, 2026, 06:05:03 PM
Thanks!

That's super cool to see other projects created with Scribus.

Love the illustrations! I hope the book finds its audience! ( From my experience...that's the hardest part )

Let me know which topic you choose for your next project so we stay in sync.  ;) ( yes, I'm only kidding )
#4
Showcase / Re: Dracula - An Archival-Insp...
Last post by Solara Maris - April 22, 2026, 05:32:45 PM
Fantastic book!

Coincidence : ). I too designed and drawn a book (graphic novel, bande dessinée) about Dracula in Scribus. I was actually born in Trannsylvania and literally I am familiar with Bram Stoker book (which I read) and the real life of Vlad Tepes (the historical character).

My book is less serious than yours : )

You can read it partially here (on Google Books):


Or purchase it on Amazon







Congratulations!
#5
Showcase / Dracula - An Archival-Inspired...
Last post by IanicM - April 22, 2026, 04:32:36 PM
Hi everyone,

Over the past months, I've been editing and illustrating an archival-inspired edition of Dracula, presenting the story through reproductions of journals, letters, telegrams, newspaper clippings, and other documents.

Once again, Scribus has been at the center of my project. It's such a joy to work with. I can easily bring my ideas to life and experiment with layouts and ideas directly in the software.

This project took me about six months in total. Most of the text within the book was added directly in Scribus, with the exception of a few elements like train tickets and some background text (such as on telegrams).

All of the artwork is a combination of 2D and 3D work. ( My background is in technical illustration. I share behind-the-scenes in my newsletter. For those interested see my website.)

I've included a few screenshots here showing how it looks in Scribus, and you can find additional photos and screen captures on my website. Also included an image of a ticket done in my photo editing software and a (very old) 3d software I use.

https://ianicmathieu.com/dracula.html

This marks the sixth book I've created using Scribus, and I've already begun working on a new project.  :D
#6
Raster and Vector Graphics / Re: Black Box
Last post by a.l.e - April 21, 2026, 07:56:13 AM
You've uploaded the screenshots with a view of the result.

The one thing that could help is an SVG file that we can try to load and see if the issue also happens on our computers.
#7
Raster and Vector Graphics / Re: Black Box
Last post by pyro - April 21, 2026, 04:51:07 AM
Hi Guy's,

I did upload some pic's , not sure what you need and how you need it.
#8
Linux / Re: Scribus 1.7.2 Imported Col...
Last post by Portreve - April 19, 2026, 07:04:34 PM
Ok, so here's the newest wrinkle in this Scribus-ian saga...

I had occasion to nuke-n-pave my system and set up Linux Mint 22.3/Cinnamon.

None of the problems mentioned in this thread happen with Scribus 1.7.3 AppImage and Linux Mint. Everything behaves exactly as one would expect.

Riddle me that one, Batman...
#9
Layout Issues / Re: Text boxes, image boxes, a...
Last post by MrB - April 18, 2026, 09:13:59 PM
Quote from: AdmFubar on April 17, 2026, 07:15:59 PMHe did mention that he was on and M3 mac, so an ssd is involved. ssd's get a conditions know as "bit rot" and "read fatigue" where the electrical charge stored starts to dissipate, making harder for the the system to read the date on the drive. this may have resulted in the altering of the data of the .sla.

see https://forums.grc.com/search/4427834/?q=fatigue&o=date

for more info on this drive condition


Highly unlikely for the age of this device, especially if its being used regularly.
#10
Layout Issues / Re: Text boxes, image boxes, a...
Last post by AdmFubar - April 18, 2026, 08:15:17 PM
Quote from: utnik on April 17, 2026, 06:46:50 AMedit: a look into the .xml code shows XPOS="nan" YPOS="nan" for this object (nan = not a number?) and the offset of 233016.8750 inches is the same value as 2^24 pt. something strange happened with this polygon.
This sounds like a nicety to add to scribus. one that alerts the user to a item that is set to an extreme size, with options to resize or delete.