View Issue Details

IDProjectCategoryView StatusLast Update
0008373ScribusGraphics / Image Framespublic2020-11-04 10:03
Reporterjghali Assigned To 
Status confirmedResolutionopen 
PlatformlinuxOSFedoraOS Version10
Product Version1.3.5 
Target Version1.5.4 
Summary0008373: After deleting page containing inline frame, frame remains in saved doc
Description[remaining frame part of issue 0008369]

If I create a page with an inline image frame, and then delete the page, the frame remains in the .sla document with no apparent way to delete it.
Steps To Reproduce1. Start scribus and create a new blank document.
2. Add a new page (page 2).
3. On page 2, insert an image frame with any old pdf image.
4. Also on page 2, insert a text frame.
5. Copy the image frame from step 3 and paste it in to the text frame as an inline image.
6. Delete the original image frame.
7. Save the document.

The modified document still contains the FRAMEOBJECT item corresponding to the inline image, even though it is no longer referenced anywhere.


related to 0008369 closedjghali After deleting page containing inline frame, scribus crashes on exit 
has duplicate 0016248 closedjghali Warn when embeded object isnt used 
related to 0016313 new remove the "window > inline items" and do not allow to reuse inline items 



2012-01-03 20:02

administrator   ~0027442

Adding Franz to CC..

Franz, with your recent 1.5 work on inline text frames, do you think you can fix this in 1.4.1.svn without risk of destabilising inline frames


2012-01-03 20:44

administrator   ~0027446

I've already fixed that in 1.5.0svn for Drag'n'Drop of objects. These fixes can safely backported to 1.4.x without breaking anything.


2013-07-12 17:38

developer   ~0030436

0011522 : same issue about PDF Effects between pages.


2014-07-03 05:16

updater   ~0032424

Last edited: 2014-07-03 12:09

Can recreate on OSX 10.8.5 1.5svn r19309


2014-07-03 12:06

manager   ~0032425

Last edited: 2020-09-24 06:35

a/ no need to have a look at the .sla, the item is in the "inline items" window

b/ currently, inline items are not deleted when a "surrounding" text frame is deleted (so, it's not deleted when a page is deleted, either)

c/ since you can insert one single inline item in multiple text frames this behavior is coherent.


d/ we probably should not have an "inline items" window

e/ the inline items could be shown as sub items of a text frame in the outline window

f/ it should not be possible to insert one single inline item in multiple text frames

so, this bug should probably be closed... but i would welcome a feature request for the points d/ to f/ :-)


2014-07-03 12:55

developer   ~0032429

Last edited: 2014-07-03 13:00

I'm not sure for d) and f)

f) depends how items behaviours relate to other scribus objects behaviours : notably scrapbook objects, symbols and one of the type of cezary's marks (that are text-bits that can be used in multiple places).
When inline items could be inserted only in a single place, it would bring less versatility, less design options, but more UI and code simplicity (KISS way).

d) depends on the status of inline objects. As long as they can be inlined into multiple frames, they are very independant objects, and as such it' probably usefull to have a dedicated window for them. Even if inline objects become very basic it could be usefull to list them and access to anyone, for maintenance sake (For example : At one point, if SLA gets too large, user might want to change some inline images into external files and will need to find/browse them)
Beside, this window could propose other operations, like import / export inline items...

As for c), it could evolve toward :

c2) Garbage collector : as long as inline items can be inlined in multiple frames, they should only be deleted when their last insertion point is being deleted. When such a situation occurs, either the inline object is simply deleted, either the UI asks whether the item should be deleted or kept for future use.



2020-09-24 05:03

developer   ~0048093

Last edited: 2020-09-24 06:08

In 0016248 (closed as duplicate) i proposed that a warning should somehow be issued when an embeded object isnt used anymore :
- with a dialog when removing the last embeded object's inserting point
- with some red text or warning icon in the "Embeded objects" palette
- in the preflight checker (as other out-of-page-image warnings)


2020-09-24 06:41

manager   ~0048094

i repeat my self: what is the use of inserting the same inline item multiple times?

imo this problem should simple not exist and is triggered by a feature nobody asked for and almost nobody uses (if somebody ever used it).

really, if you want to reuse an item, we have symbols.
we don't need a garbage collector or warnings in the verifier for inline items.
we just need to strongly link the inline items with the only frame they are inserted in.


2020-09-24 07:59

developer   ~0048096

@ale I dont use symbols or very rarely. I dont know how different they are to other items or tools (inlined items, symbols + clipboard album). This is not clear to me. Providing these different tools requires good UI and documenting + converting tools because user could want to convert inlined item into symbol or bring it into the clipboard album and the same for any of them to any other type (convert a clipboard album item into symbol usw).


2020-09-24 10:17

manager   ~0048098

symbols = clipboard items with a link to the original. (you edit one, all change)

inline items are items that are inside of a text frame.

the "symbols" name is imo bad but one get used to it...


2020-09-25 16:22

developer   ~0048102

It doesnt help discovering scribus to have so widely different namings for so closely related items, all the more when the tools are totaly different and not linked to each other.
Clipboard items, inlined items and symbols are very much the same : parts of a document.
Inlining an item is just a way to use it.
Having it in a clipboard is just a way to share it amongst document
Naming it a symbol is just a way to be able to propagate its changes to all its use places.
The UI should better reflect this.


2020-09-28 08:58

manager   ~0048109

no, inline items are not the same.
even if they might be stored in a .sla in a similar way.
they are simply non-text items that have been pasted inside of a text frame.
or, at least, they should just be just that.
no need at all to have an inline items dialog or even to have them as a name in scribus.

scrapbook is imo a good name.
symbols are badly named.
symbols should probably just be scrapbook items and depending on the way you drop them into the document the link to the original is kept or not.
there is probably no need for the name "symbols" to be shown in the UI.
there should only be scrapbook items. it's the way you link them in the document that should make the difference, not the way you add them in the scrapbook.

the clipboard is a completely different thing.
even if the scrapbook can be seen as some sort of permanent clipboard.
discovering that there can be a link between the two makes me sad.
(really? who wants the clipboard to be automatically added to the scrapbook?)

imo, not because something is technically similar, that it should be shown as the same thing to the user or provide the same features.
and not because two things are (partially) implemented in a same way, that they should share parts of the UI.

btw, you forgot patterns!

really, scribus should start caring more about the way things are used and avoid leaking details about how things work behind the scene or are stored in a .sla.

Issue History

Date Modified Username Field Change
2009-08-23 01:07 jghali New Issue
2009-08-23 01:07 jghali Issue generated from: 0008369
2009-08-23 01:07 jghali Relationship added related to 0008369
2009-08-23 01:10 jghali Summary After deleting page containing inline frame, frame remains => After deleting page containing inline frame, frame remains in saved doc
2009-08-23 01:10 jghali Description Updated
2009-08-23 01:10 jghali Steps to Reproduce Updated
2009-08-26 21:17 jghali Severity crash => minor
2009-10-04 22:15 cbradney Target Version => 1.3.6
2010-01-06 23:22 cbradney Target Version 1.3.6 => 1.3.7
2010-05-26 22:30 cbradney Target Version 1.3.7 => 1.3.8
2010-07-17 20:51 cbradney Target Version 1.3.8 => 1.3.9
2010-11-23 20:14 cbradney Target Version 1.3.9 => 1.4.0
2011-04-16 10:02 cbradney Target Version 1.4.0 => 1.4.1
2012-01-03 20:02 cbradney Note Added: 0027442
2012-01-03 20:44 fschmid Note Added: 0027446
2012-04-29 21:13 cbradney Target Version 1.4.1 => 1.4.2
2013-01-13 21:32 cbradney Target Version 1.4.2 => 1.4.3
2013-07-04 20:24 cbradney Target Version 1.4.3 => 1.5.0
2013-07-12 17:38 JLuc Note Added: 0030436
2014-07-03 05:16 Kunda Note Added: 0032424
2014-07-03 12:06 ale Note Added: 0032425
2014-07-03 12:09 Kunda Note Edited: 0032424
2014-07-03 12:55 JLuc Note Added: 0032429
2014-07-03 12:57 JLuc Note Edited: 0032429
2014-07-03 12:57 JLuc Note Edited: 0032429
2014-07-03 12:59 JLuc Note Edited: 0032429
2014-07-03 13:00 JLuc Note Edited: 0032429
2014-07-03 14:16 Kunda Target Version 1.5.0 => 1.5.1
2015-09-17 20:10 Kunda Category Graphics / Image Frames => Graphics/Img Frames
2015-09-17 20:11 Kunda Category Graphics/Img Frames => Graphics / Image Frames
2016-01-23 17:17 cbradney Target Version 1.5.1 => 1.5.3
2016-05-12 12:53 Kunda Tag Attached: inline
2016-05-12 17:10 Kunda Status new => confirmed
2016-12-08 22:04 Kunda Target Version 1.5.3 => 1.5.4
2020-09-24 00:16 jghali Relationship added has duplicate 0016248
2020-09-24 05:03 JLuc Note Added: 0048093
2020-09-24 05:04 JLuc Note Edited: 0048093
2020-09-24 06:08 JLuc Note Edited: 0048093
2020-09-24 06:35 ale Note Edited: 0032425
2020-09-24 06:41 ale Note Added: 0048094
2020-09-24 07:59 JLuc Note Added: 0048096
2020-09-24 10:17 ale Note Added: 0048098
2020-09-25 16:22 JLuc Note Added: 0048102
2020-09-28 08:58 ale Note Added: 0048109
2020-11-04 10:03 ale Relationship added related to 0016313