View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013993 | Scribus | Import / Export | public | 2016-04-28 09:50 | 2016-05-02 12:34 |
| Reporter | AlmaTlust | Assigned To | jghali | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | not fixable | ||
| Product Version | 1.5.1 | ||||
| Summary | 0013993: Problem after collecting for output | ||||
| Description | If I collect for output and delete the exported folder while Scribus is still open, I can't save anymore, and the links to the images point to the now deleted export folder. | ||||
| Steps To Reproduce | Take any document with images "Collect for output" while Scribus is still open, delete the folder you exported into (as you might do if you zipped it to send it to someone else). Click on "save" Result: Scribus complains that it can't save, and the links to the images point to the (now deleted) export folder. When closing without saving, everything is fine again. When saving to another file in that state, the problem remains when reopening. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
| related to | 0012883 | new | Missing image file sometimes blocks PDF export |
|
|
I think there is misunderstanding what 'Collect for output' is doing. When you Collect for output scribus is internaly changing document to point all picture references in newly created directory (as you found out). If you are deleting files scribus is depending on you should not expect for any better behavior then scribus is performing now. Scribus is not holding all data in memory (especialy not pictures - it has downsampled pictures in memory for showing in canvas - not original one) so it can not recreate complete documents with all dependencies if you delete the folder (and it already forgot the places where originaly pictures were placed because it made a copies in now deleted folder). To bring an extreme example - this seems similar to following situation: You are running your OS of choice and some programs, then you open file manager (or terminal) and delete whole disk drive (rm -rf /). I would not expect anything sensinble to come out of this situation. (Sorry for this last paragraph) Therefore I do not think there is any fault on scribus side. |
|
|
As juraJ explained, "collect for output" change all image links. So there is nothing we can do if you are deleting the new image folder. |
|
|
The problem is not that it does what it does. From your explanations I gather that indeed this is and has to be expected behavior. The problem is that suddenly you work on a different file without being notified - which does not make itself obvious to the uninitiated right away. |
|
|
So maybe some sort of notification that one now is working on a new copy might be helpful to avoid confusion. |
|
|
It is there already: the title of the document change. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-04-28 09:50 | AlmaTlust | New Issue | |
| 2016-04-28 16:49 | jurajF | Note Added: 0040584 | |
| 2016-04-28 21:35 | jghali | Note Added: 0040589 | |
| 2016-04-28 21:35 | jghali | Status | new => resolved |
| 2016-04-28 21:35 | jghali | Resolution | open => not fixable |
| 2016-04-28 21:35 | jghali | Assigned To | => jghali |
| 2016-04-28 21:35 | jghali | Status | resolved => closed |
| 2016-04-29 08:09 | AlmaTlust | Note Added: 0040593 | |
| 2016-04-29 08:09 | AlmaTlust | Status | closed => feedback |
| 2016-04-29 08:09 | AlmaTlust | Resolution | not fixable => reopened |
| 2016-04-29 08:10 | AlmaTlust | Note Added: 0040594 | |
| 2016-04-29 08:10 | AlmaTlust | Status | feedback => assigned |
| 2016-04-29 08:42 | jghali | Note Added: 0040596 | |
| 2016-04-29 08:42 | jghali | Status | assigned => resolved |
| 2016-04-29 08:42 | jghali | Resolution | reopened => not fixable |
| 2016-04-29 08:42 | jghali | Status | resolved => closed |
| 2016-05-02 12:34 | Kunda | Relationship added | related to 0012883 |
