why will my .sda not open?

Previous topic - Next topic


I've been using Scribus for a while, but this seems the appropriate forum. It's a bit of an emergency as I'm working to a deadline, so any help would be appreciated.

A document (~260 page book, heavily illustrated) that was working fine until yesterday is refusing to open in Scribus 1.4.6.
I've tried
* uninstalling and reinstalling Scribus 1.4.6 (several times)
* restarting my laptop (several times)
* trying Scribus 1.5.3. instead
* changing the name of the folder containing all of the graphics (so as to lessen the burden on opening the document)

Ususally, the document opens to about 26 or 27% and then crashes. If I change the name of the graphics folder, it will get to around 95%. A couple of times (I have tried *many*) it got all the way to 100%, but then crashed within a couple of minutes when I tried to carry out simple procedures.

Could someone have a look at this thing and see if there's something inherently problematic with it?


p.s. One last try with Scribus 1.5.3 before I posted this, and (typically!) I got it to open and export to PDF. But I still think there must be something problematic with the file, so would appreciate any hints on what this might be.

[attachment deleted by admin]


The file you attached was created using Scribus 1.5.3 and cannot be opened in 1.4.6.
Can you attach a 1.4.6 version please?


repetita juvant:

- reinstalling scribus is not a solution (not even several times)
- restarting the computer normally does not help, either. (except if you don't have enough memory available because of some leak)
- restarting scribus itself might help in some cases
- in other cases letting scribus recreate its setting might help (but probably not in your case).

i've opened your file with 1.5.3 and it's a big one.
the diagnose is: you probably don't have enough RAM on your computer.
the fact that it goes further without images seems to confirm this.
(in this case rebooting the computer could have helped...)

i cannot try with 1.4.6 since -- as garry also said -- you posted the file you have saved with 1.5.3.


It will be interesting to see the 1.4.6 version.

My first guess was that the problem might be memory-related but then I wondered: "How was there enough memory to hold the document and save it (including having the Undo stack in memory) but there's not enough memory to load the same document?"

I don't know how Scribus does these things but it seems a bit strange that Scribus cannot load something it quite happily saved (especially if Scribus was the first application to be run after a reboot). A curious little problem.


hi garry

Quote from: GarryP on July 06, 2017, 10:14:07 AM...I wondered: "How was there enough memory to hold the document and save it (including having the Undo stack in memory) but there's not enough memory to load the same document?"

i have seen this before (at least twice in the german scribus forum) – i was able to open those files on my computer and split them, so the owners could work with them again...

scribus is able to produce and safe files too big to open on the same machine.



It's strange. It suggests that loading may be more memory-hungry than editing and saving which doesn't sound right to me.

Maybe there's a fundamental problem with how Scribus works, or maybe it's just how things are. It could be an issue with how Scribus is using the Qt APIs on different OSes, perhaps.

Since opening the file without images doesn't work either I thought it might be something to do with fonts but that doesn't seem to make sense either.

Opening the file with a debug build of Scribus in Qt - and carefully watching the memory usage - might shed some light on the matter.


hi garry

the loading of a .SLA file has probably little to do with the way Qt works.

what might be happening:

- when opening a document scribus will calculate the position of the whole text in the document and store it in memory
- a 250 pages document might or not be easy to load.

of course this can be optimized and only the pages that are absolutely needed should be retained and calculated when loading the docuemnt.
but picking the pages to be loaded and correctly layout them (when you don't have the full information) is hard and complex work.

it would be of course nice if somebody would improve that, but it should probably be somebody who is not involved in the daily scribus business...



this shows the real potential of the application: usually programs can't produce files too big to open – scribus looks to be a lot better in this respect...



a.l.e: the point I was trying to get across was that either the way that the Qt APIs worked, or how Scribus is using those APIs, might have an effect on the loading of a document, not the other way round. Maybe the APIs default to a certain value/size - or whatever - that's not good for what Scribus needs, or something like that. File access APIs always have loads of different ways of doing things and there might be a simple change that makes it better. I don't know how Scribus works so I'm just throwing ideas out there.

This could be a major flaw in Scribus. If someone doesn't have access to another machine with a bigger memory - or the web - then they could get to a point where their document is non-recoverable (without some judicious XML editing). They could be happily adding stuff to their document day-by-day and then - POW! - they cannot open their document again, which is exactly what happened to MW above. That's not a good situation.

At the very least Scribus should give a "document too large" message while loading rather than just hang. Then the user will know what's wrong even if they can't do much about it.

Would it be possible for Scribus to - somehow - estimate whether it could be saving a document that cannot be subsequently loaded?
Or could Scribus give some kind of percentage memory free indication?
I don't know how useful - or otherwise - these things could be; just more ideas randomly thrown out there.

utnik: Nice thinking. It's not a bug, it's a feature!


hi garry,

the issue has (very likely) nothing to do with Qt.

Scribus is using several other external libraries, not only Qt. But, in this case, it's rather likely that the issue has nothing to do with any of them, and it's related to the architecture the programmers of Scribus have chosen for the application and about the code they have written to implement it.

And, well, i'm not sure that Scribus can really create files that are bigger than what it can load.
(you know, the user could have update some software or installed new ones and now has less memory available for the programs)
Except if there is a memory leak in the file loader that is not also in the internal manipulation of the documentation structure.
Anyway, since the problem seems only to be happening in 1.4.6 and not in 1.5.3, we could consider that the problem is fixed for future versions of Scribus.
Or not?

Finally, the problem with the "out of memory" errors is that they can happen at any place in the code.
And you cannot know how much memory is still around (afaik). At least not in an speedy way.
All you can do is: make sure that if something fails because there is no more memory, you catch that error and do something meaningful.
But that "meaningful" is probably what a computer can consider as meaningful and not an end user in a GUI : - )
In such a situation, it's often hard to keep the program up and running... because you don't have any memory available!
While it's for sure wise to catch those errors, it's not easy to write code that checks for it at every and each step.
So, even if the programmer could notice that there has been an issue often all she can do is to shut down the application in a controlled way (as opposed to simply crashing) but showing an alert might be out of reach.
In this specific case, Scribus could just fail to load the document without crashing, delete all references to the document and hope that at the end it has enough memory to tell the user that it failed. Maybe it could say that it was a memory issue, maybe it cannot tell it.

If we want to test this and see if there is somebody that can be done, somebody able to run Scribus in a debugger should create a file that fails in a similar way and check where the program is failing.
I fear that this will be hard on my computer with a multiple GB RAM... but it might be possible with a virtual machine with less memory available.


I guess if it's fixed in 1.5.x then 1.4.6 users will just have to put up with it. I'm also guessing that the majority of Scribus users won't even know there's a problem and they'll be fine.

Assuming that it is an "out of memory" situation, and not something else, then I would expect Scribus to crash instead of hanging unless there was some code that "handled" the exception by just ignoring it and putting the application into an infinite loop. It sort of makes me think that there's code in there to catch the exception but it doesn't handle it correctly, or in a nice user-friendly way.

Anyway, like you say, running the problem through a debugger on a memory-starved machine (or VM) would probably make it pretty easy to figure out what was happening.