Removing the cross symbol from composite picture frames

[PaoloT]

Hi,

I reported this in the past, but I see this has not changed, and I will request again for the new version.

When opening IDML files, pictures frames containing composite images are shown with a cross inside. I guess this should mean that this is a picture frame. But, contrary to an inserted image, the cross remains there even with some content.

This is extremely annoying when editing, both for the interference between the cross and the content, and for the sense of something going wrong caused by the crossed frame.

I would like an option to avoid this behavior, and make the cross disappear.

Paolo

 

[Dan C]

17 hours ago, PaoloT said:

When opening IDML files, pictures frames containing composite images are shown with a cross inside. I guess this should mean that this is a picture frame. But, contrary to an inserted image, the cross remains there even with some content.

Inspecting the file provided in your previous post regarding this, there are multiple Picture Frames in the imported IDML document - some of which are directly filled with content, however those showing the 'cross' are technically empty frames.

Although the frames have other layers nested within (such as Groups, or other Picture Frames), the frames themselves are technically 'empty' (ie do not currently have an image applied) and therefore will show the cross when editing.

This is expected behaviour within Affinity and as far as I'm aware isn't likely to change, though these crosses are only displayed when editing your document in Publisher and will not appear in the exported results, or with 'Preview Mode' enabled.

I hope this clears things up

[PaoloT]

4 hours ago, Dan C said:

This is expected behaviour within Affinity and as far as I'm aware isn't likely to change

Dan, thank you for your explanation.

Please consider that these 'empty' frames may become unavoidable, when you think to exporting to HTML. Without a containing frame, images exported from Publisher will go everywhere in a web page. The container I use will become a Div (or a Figure in other markup dialects), keeping the assembly together.

Considering it normal practice would prepare Publisher to be compatible with a web-savvy format.

Paolo

 

[PaoloT]

On 11/16/2023 at 12:00 PM, Dan C said:

This is expected behaviour within Affinity and as far as I'm aware isn't likely to change

Please let me ask you to reconsider this. The crossed composite frames are becoming maddening. As I explained above, it is very likely they will become even more common in the future, thinking to how 'images' have to be mandatorily included into composite 'figures' on the web.

The frames are not actually empty. In the above example, the top-level frame includes an FX. And then, it includes all the children (the other frames). So, the crossed display is reporting something untrue. In the end, it is just an annoyance, both because they overlap the content, and because they report an error that is not there.

Groups are not the equivalent of frames. You can't apply picture styles to them. Placing a group instead of a picture frame would prevent effects like shadowing or dimming.

At least, please add an option to make them be hidden. I will run the risk of ignoring the error report.

Paolo

 

[Alfred]

On 4/30/2024 at 10:25 PM, PaoloT said:

Please let me ask you to reconsider this.

+1

I can’t imagine there being many users who would naturally interpret a crossed picture frame as meaning ‘This frame doesn’t contain a picture’ rather than ‘This frame is empty’.

[Dan C]

On 4/30/2024 at 10:25 PM, PaoloT said:

The frames are not actually empty. In the above example, the top-level frame includes an FX

'FX' are a function applied to the active layer (and all children) and is not a Layer or Object itself - therefore a frame with no assigned 'content', but with FX applied will still show this 'X' across the frame.

On 4/30/2024 at 10:25 PM, PaoloT said:

And then, it includes all the children (the other frames). So, the crossed display is reporting something untrue.

The frame in the above screenshot contains a Group, which is a Layer Container and neither a Layer or Object itself. You can add a Group as your Frame Content, but this will automatically convert the Group to a Constraints Group.

This group within then contains an empty Picture Frame (which has not be assigned as another Picture Frames 'contents'), and 2 further frames which do have content applied.

None of these layers are assigned as the 'contents' for the frame, and therefore the 'X' on the frame continues to display on your canvas, as we'd expect.

51 minutes ago, Alfred said:

I can’t imagine there being many users who would naturally interpret a crossed picture frame as meaning ‘This frame doesn’t contain a picture’ rather than ‘This frame is empty’.

As per the helpfile -

Quote

In the case of picture frames, though, only one child object can be flagged as the framed ‘content’. This object is indicated in the Layers panel by a box containing a diagonal cross, overlaid on its layer thumbnail.

(...)

To add an object as frame content, drag its layer onto the target frame's name in the Layers panel and drop when the frame's row is highlighted.

(...)

To add an object to a frame as a regular child object, drag its layer just below the target picture frame's row in the Layers panel and drop when a highlight line appears beneath the frame's layer name. You can add as many child objects as you wish in this way.

Therefore the 'X' does not only indicate if a Picture is present or not, it's a direct indication of how the contents is applied to the frame and this changes how the app then handles this contents. The layer with the 'X' by the thumbnail Layers Studio is the layer that will be used for frame scaling etc.

If you have a frame with layers added as children, but none have been assigned as the frame contents (indicated with the 'X' by the thumbnail) then the app must indicate this to the user - and the method we've chosen is to leave the 'X' displaying for the frame, on the canvas directly. Simply assigning any layer within that frame as the 'contents' will remove the 'X' across the frame, this can be any compatible layer and does not have to be a picture.

I hope this clears things up

[Alfred]

17 minutes ago, Dan C said:

Therefore the 'X' does not only indicate if a Picture is present or not, it's a direct indication of how the contents is applied to the frame and this changes how the app then handles this contents.

Thanks for the clarification, Dan, but it still seems enormously unintuitive.

I think it would make for a better UX if the ‘X’ meant (only) ‘Nothing to see here’.

[PaoloT]

Thank you for this further explanation of how it works under the hood, @Dan C. Unfortunately, this doesn't change that this excess of technical communication makes the visualization much worse, by adding what is a visual disturbance and a constantly ringing alarm.

I think the way InDesign does it is the correct way, since having any data inside a frame makes it non-empty. There is no need to communicate a subtle technical difference to the user, when the real-world experience is just that: the frame is not empty.

I really hope this can be solved at least with a preference option. It may seem a small thing, but it impacts greatly on the everyday life with Publisher. And will become worse, when you will export to Web or ePub, when having to deal with containers equivalent to 'Figures'.

Paolo

 

[fde101]

I believe this may be regarded as a defect in the import process?

Working within Publisher itself, with a new document, I can find no way to make a group a child of a picture frame without making it the content of that frame.  Am I missing something?

If not, the import process is basically creating a situation which cannot be created directly, which is resulting in a suboptimal behavior for users.  This doesn't appear to be a sane or particularly correct behavior.  When importing that group, why is it not being assigned as the frame's content?

I do agree that displaying the "X" on the frame when there is no content assigned is the most sensible behavior and should remain, but I am lost on why the frame would have a child layer which is neither content nor a mask, and I can find no way to create that situation within the app itself, I suspect the developers never intended for that to work, further leading me to the conclusion that the import process is broken here.

 

23 hours ago, Dan C said:

You can add a Group as your Frame Content, but this will automatically convert the Group to a Constraints Group.

It does if you assign it by dragging it onto the label of the frame in the Layers panel, but not if you cut it then select the picture frame and paste while Paste Inside is enabled.  Not sure if it should or not.

[PaoloT]

10 hours ago, fde101 said:

I believe this may be regarded as a defect in the import process?

Now, I believe this is the case.

1. I created a new empty picture frame.

2. Then assembled a composite "figure" of images + text + lines.

3. Grouped them, and then paste them inside the above frame.

No cross in the frame. In the following image, you can see the imported frame (above) and the newly created one (below).

If I understand the icons correctly, the group in the imported frame is interpreted as a picture frame inside a frame, while the newly create one is correctly interpreted as a group inside a frame.

 

[Dan C]

Are you able to provide a copy of an .IDML file that imports with the Picture Frame content not applied to the picture frame so I can investigate this further please?

On 5/3/2024 at 11:43 AM, fde101 said:

Working within Publisher itself, with a new document, I can find no way to make a group a child of a picture frame without making it the content of that frame.  Am I missing something?

There are ways to do this (and likely more ways I'm yet to consider), but these are generally fringe or unexpected workflows as the default behaviour should almost always apply the object as 'Content' for the frame. For example with an object already added as Content to a frame, you can create a separate group as a child object of the frame, then delete the assigned Content layer and the group will now show as in your screenshot as this does not automatically inherit the Content nature of the deleted object:

On 5/3/2024 at 11:43 AM, fde101 said:

It does if you assign it by dragging it onto the label of the frame in the Layers panel, but not if you cut it then select the picture frame and paste while Paste Inside is enabled.  Not sure if it should or not.

 Thanks for raising this - I must admit I'm not entirely certain if this is expected, so I will be sure to check with our team internally and log this as required

[Dan C]

Just to confirm, I have been able to replicate the issue when importing IDML files and the Groups not being added as 'Content' layer and therefore have logged this with our development team.

I have also separately logged the inconsistency when dragging/pasting a Group into a picture frame with our team.

I hope this helps

[PaoloT]

Hi,

Since this issue persists in the most recent version, I would like to ask if at least the 'X' can be hidden though a preference. Seeing this symbol, universally meaning 'deleted' or 'broken', is really maddening. I would even suspect it is not a major task adding this option.

I guess that it is perfectly fine not to get such a strong indication of an 'empty' frame, is so it has to be considered. There is no harm done in having an empty frame. Reasonably, if we have drawn a frame, we know we did. If we did it and then for some reason forgot it, no problem: it will not be printed.

Paolo

 

[Callum]

On 9/21/2024 at 6:00 PM, PaoloT said:

Hi,

Since this issue persists in the most recent version, I would like to ask if at least the 'X' can be hidden though a preference. Seeing this symbol, universally meaning 'deleted' or 'broken', is really maddening. I would even suspect it is not a major task adding this option.

I guess that it is perfectly fine not to get such a strong indication of an 'empty' frame, is so it has to be considered. There is no harm done in having an empty frame. Reasonably, if we have drawn a frame, we know we did. If we did it and then for some reason forgot it, no problem: it will not be printed.

Paolo

 

Hi Paolo, 

I can see from the internal report that Dan C raised that this is something our developers are still looking into I will add your request to that report. This issue should hopefully be addressed soon.

Thanks
C