Crossed graphics frames

[PaoloT]

Hi,

After importing an IDML file in Publisher V2 on Win10, I noticed that my image frames are crossed. I don't know if this is only happening when they are composite frames, containing both images and text, but it looks like it is.

Is there a way to prevent this from happening? It is extremely disturbing, and immediately making me think that something is going wrong.

Paolo

 

[thomaso]

This occurs in empty Picture frames and also if the image layer is not in the correct position within the parent frame layer. Drag the image to the name of the frame layer.

[PaoloT]

16 hours ago, thomaso said:

This occurs […] if the image layer is not in the correct position within the parent frame layer. Drag the image to the name of the frame layer.

I'm not sure this is the reason. For example, in the next picture frame I don't see any issue with the element's hierarchy. Or should I? Apparently, there is a picture frame containing a group, inside which there is another picture frame containing the foreground (solid) image, and another picture frame containing a background (dimmed) image. Everything looks like it should to me.

 

 

[thomaso]

Though it is possible to have more than 1 image in Picture Frame I guess there is no advantage in a setup / layer hierarchy with Picture frame children + sub-children.

Note that the tiny symbol on a thumbnail occurs exclusively for 1 layer inside a Picture Frame AND requires the correct nesting. Only then the typical interface appears that offers a.) the central circle on the Picture Frame to move its child around + the slider below the Picture Frame to resize the nested resource.

Your screenshot is tricky because it seems to show two different images with identical names. Also it looks confusing that the Picture Frame with the FX seems to contain another Picture Frame which contains an image while the nested Picture Frame does not show the typical thumbnail symbol + is named identical to its containing image.

Unfortunately I don't have V2 and are not used to its layers panel icons. If you want to I would take a look in this if you copy/paste the parent Picture Frame and its nested Group into a V1 document + upload this / or the .IDML document. –  I assume at least one of these Picture Frames is either redundant or might better be a Group or Layer layer instead. Also it seems to me the Picture Frames with the diagonal black crossing lines have their children not nested properly.

Look what I get in V1 if I nest a Group within a Picture Frame: The upper version shows the cross and no symbol on the thumbnail whereas the other shows all expected interface items. For the latter Affinity turned the Group layer I dragged on the Picture Frame layer automatically into a "Constraints Group" layer.

[PaoloT]

14 hours ago, thomaso said:

Though it is possible to have more than 1 image in Picture Frame I guess there is no advantage in a setup / layer hierarchy with Picture frame children + sub-children.

One of the advantages of using picture frames, instead of free-floating images, is that a group of images can be managed as a single unit. A typical case is an image with shapes and callouts, plus caption text – this is a single unit, composed by several different elements. Picture frames inside a containing picture frame act as clipping frames.

14 hours ago, thomaso said:

Note that the tiny symbol on a thumbnail occurs exclusively for 1 layer inside a Picture Frame AND requires the correct nesting. Only then the typical interface appears that offers a.) the central circle on the Picture Frame to move its child around + the slider below the Picture Frame to resize the nested resource.

As far as I can see, I have all of this: a correct hierarchy (containing picture frame for the group --> containing picture frame for clipping a single image --> picture). The resizing slider and the move circle with arrows do appear when double clicking.

14 hours ago, thomaso said:

Your screenshot is tricky because it seems to show two different images with identical names.

It's just a simple clipping and image with the same image. Something that in InDesign you do with the "Paster Into" command (and that should be replicated, in Publisher, by the "Paste Inside" command). You can do it with different images, or with the same image (to separate a detail from the complete image in the background).

14 hours ago, thomaso said:

Also it looks confusing that the Picture Frame with the FX seems to contain another Picture Frame which contains an image

This particular image has an FX (outer shadow) applied to the picture frame. This picture frame then contains an image, that has been interpreted by the IDML converter as an image inside a picture frame. Either I leave the image inside the child-picture frame, or I move it out of it, directly inside the main picture frame, I get the X in the image.

I this X means there is an error, I can't see where the error is.

Paolo

 

 

[PaoloT]

51 minutes ago, N.P.M. said:

Group the contents you want in the pictureframe before dragging it in the pictureframe.
…
If you group while 2 objects are already in the pictureframe it will show the cross.

If you see my second example, the contained images are grouped. I usually group the images on the pasteboard, and then paste them inside a picture frame in the text.

Yet, the cross is still there.

Paolo

 

[thomaso]

1 hour ago, PaoloT said:

I this X means there is an error, I can't see where the error is.

17 minutes ago, PaoloT said:

If you see my second example, the contained images are grouped.

To me the X occurs as long the Picture Frame contains no child that is correctly positioned in the layer hierarchy. Correct nesting gets indicated by the square symbol on the nested thumbnail.

What results do you get if you drag the nested parent layer (group or picture frame) first out of their parent Picture Frame and in a second step in again while you hover the cursor over various parts of the Picture Frame layer (e.g. thumbnail | thumbnail right edge | layer name | bottom layer edge)?

Compare my screenshot above with/without X.

[PaoloT]

56 minutes ago, thomaso said:

To me the X occurs as long the Picture Frame contains no child that is correctly positioned in the layer hierarchy. Correct nesting gets indicated by the square symbol on the nested thumbnail.

What results do you get if you drag the nested parent layer (group or picture frame) first out of their parent Picture Frame and in a second step in again while you hover the cursor over various parts of the Picture Frame layer (e.g. thumbnail | thumbnail right edge | layer name | bottom layer edge)?

Compare my screenshot above with/without X.

As far as I can see, nesting in my examples is correct. If there is something not correct, I can't see where.

As shown in my third example, moving a child element out of a child picture frame, up to the top picture frame, is not making the X disappear. To be true, I think this also damages the correct nesting.

Keep in mind that your second example involves a constrained group, that is a special case (you want child elements to remain unchanged in case of resizing the parent frame), and that can't be used in all cases (not for example, in my case, where I want that parent and child elements are uniformly resized when needed).

Paolo

 

[thomaso]

7 minutes ago, PaoloT said:

If there is something not correct, I can't see where.

Where the nested child layer thumbnail does not show the squared symbol. For instance:

… whereas it occurs here for instance:

19 minutes ago, PaoloT said:

Keep in mind that your second example involves a constrained group, that is a special case (you want child elements to remain unchanged in case of resizing the parent frame), and that can't be used in all cases (not for example, in my case, where I want that parent and child elements are uniformly resized when needed).

The Constraints property of the Group gets auto-created by the app when nesting a Group in a Picture Frame. See also the video of @N.P.M.. The settings of the Constraints Group respectively its child layers can be set in quite various ways, including the option "I want that parent and child elements are uniformly resized when needed" (which, I guess is the default setting in this situation). Consider to use the outer, bottom right handle for resizing.

If Picture Frames feel complex a simple rectangle cropping may be an option (Tools Panel > Vector Crop Tool). I often prefer it over a Picture Frame, for most uses it is easy to handle with the advantage that the name of its parent layer remains visible (helpful for collapsed layers). Also, this type of masking may have any shape, custom drawings, too. But it may get cumbersome if you need to scale its parent (the image or group) without scaling the masking object inside. Then you need to activate "Lock Children" first – a disadvantage which also happens to Picture Frames but in different situations.

[PaoloT]

43 minutes ago, thomaso said:

Where the nested child layer thumbnail does not show the squared symbol. For instance:

… whereas it occurs here for instance:

…but if the second of these two examples looks correct, it still doesn't work: the image has an X on it:

So, whether I move the elements in the hierarchy, these images (imported as an IDML file) have this X on them. As I understand from your explanation, this means that there is an error. It should be an error in the hierarchy. But even what looks linear, and correct, results in an error.

Paolo

 

[thomaso]

4 minutes ago, PaoloT said:

the image has an X on it:

I assume this X is from a previous / another parent Picture Frame (above the Group layer but cropped in this screenshot). Compare the selected layer in this screenshot where the Group thumbnail is missing the squared symbol of its parent Picture Frame.

Don't confuse the hierarchy: A Picture Frame requires exactly 1 layer being nested correctly and only this 1 layer will get the symbol and will profit from the full Picture Frame interface features. Any additional layer, nested directly or inside a further layer, will not show the symbol and will not be affected in the identical way by this parent Picture Frame interface.

5 minutes ago, PaoloT said:

But even what looks linear, and correct, results in an error.

The X is "just" part of the interface, indicating an empty Picture Frame. It will not appear on export or print. So I would not call it an error (in terms of a bug), regardless whether it is caused unintentionally by the app or by the user. (while I am unable yet in V1 to create a situation where this X is caused unintentionally by the app, not me).

Again, can you create a sample document in V1 + upload this (or an .IDML) for further inspection or a possible fix?

[PaoloT]

1 hour ago, thomaso said:

I assume this X is from a previous / another parent Picture Frame (above the Group layer but cropped in this screenshot). Compare the selected layer in this screenshot where the Group thumbnail is missing the squared symbol of its parent Picture Frame.

But I see that the crossed square thumbnail appears next to both picture files, in the example. What does exactly that symbol means? I can't find it in the manual, and I got the impression that it means the image is cropped by the parent frames.

1 hour ago, thomaso said:

The X is "just" part of the interface, indicating an empty Picture Frame. It will not appear on export or print.

No, but it is extremely annoying while editing or previewing. It's as if there is a report of errors in the picture frame. So, I hope the situation I'm seeing is just some but or some operator error from my side, and not an intended behavior of the program.

In any case, here is one of the problematic picture frames in IDML format.

Paolo

 

 

picture-frame-test.zip

[thomaso]

Can you upload the image "audio-out-mp3-speakers.tiff", too?

[PaoloT]

10 minutes ago, thomaso said:

Can you upload the image "audio-out-mp3-speakers.tiff", too?

Yup! I've replaced the zip in the previous message, to avoid a proliferation of attachments.

Paolo

 

[thomaso]

The view with the missing image makes it more obvious: Check the number of Picture Frames + the number of squared thumbnail symbols. There are two Picture Frames that are used as parents of Picture Frames which are redundant. One of them has a shadow assigned, so I deleted its child instead (although this child did show the squared thumbnail symbol as expected). I fixed it simply by dragging a child layer on the name of a parent Picture Frame and then deleted the resulting empty layer. For better overview I also removed the main Layer + the empty Master.

Again, I recommend to consider using the Vector Crop Tool (or a custom shape) instead of a Picture Frame. There is one option in the Picture Frame which makes it more complex than required or wanted in many situations: The "Picture Frame Properties", that require a certain setting for both the scaling + the anchor. Otherwise it will cause unwanted results. You can experience this if you drag in the Layers panel the smaller image on the name of the Picture Frame layer wich has the shadow assigned. Then first the image shows a different detail and needs to get moved back to its initial position within the Picture Frame. The reason is because the used Picture Frames have their properties set differently.

Result 😄

 

I haven't checked in InDesign but I assume the culprit for your confusion is the way how the document was setup in InDesign. Although ID also displays the X on an empty Picture Frame it might react different with a wrongly nested child layer.

picture-frame-test C.afpub

[PaoloT]

2 hours ago, thomaso said:

[…] There are two Picture Frames that are used as parents of Picture Frames which are redundant.

There is a reason for the first "redundant" picture frame in InDesign (CS6), and it is that you can't paste a complex assembly into a group. For this, you have to paste a group into a picture frame.

I don't know the reason for the second "redundant" picture frame, but I guess that this is not something I did intentionally, and is something that InDesign did when I applied an FX, or Publisher did when importing the IDML data.

I've yet to try and see if Publisher can make me avoid the two redundant picture frames. When I will be able to move my work on it, I'd be happy to adapt to a less convoluted workflow.

Something that I hope I can do is using masks in a more sophisticate way than in CS6. As far as I've seen, Publisher should be much more powerful, by integrating more advanced graphic tools.

Thank you for checking.

Paolo

 

[thomaso]

3 hours ago, PaoloT said:

There is a reason for the first "redundant" picture frame in InDesign (CS6), and it is that you can't paste a complex assembly into a group. For this, you have to paste a group into a picture frame.

I don't really understand what you mean. When I open your .IDML in ID it shows a similar confusing complexity like in APub. Also here the Layers panel shows 4 layers named … .tiff, although there are just two images in the layout. The same layers seem to be redundant: the two .tiff layers right above + below the Group layer.

It seems you had created additional rectangles to crop both images. Note, different to APub, in ID every image always has a container frame object that can be used as (parent) masking object – fully without the need to use a separate rectangle or picture frame object. Therefore you need in ID just the Group as an extra layer to allow the two images as one pinning object inside the text frame:

Then APub opens this with the same layer structure & hierarchy but adds the additional Picture Frames because in APub an image layer has no parent container by default (although it may have a stroke assigned). So it looks as expected like this:

picture-frame-test C.idml

[PaoloT]

1 hour ago, thomaso said:

I don't really understand what you mean.

This document is conceived as a master for single sourcing to various file formats. Building an image requires some planning for formats other than PDF.

Try to export it from ID to HTML. If you have a group as the top container, the contained images will be exported as separate elements.

if you have them grouped inside a frame, they will remain a single assembly/complex image. So, what looks like a convoluted way is just a compromise or workaround.

Can't try it at the moment, but it for sure behaves this way with a mix of text and images.

Paolo

[thomaso]

1 minute ago, PaoloT said:

So, what looks like a convoluted way is just a compromise or workaround.

So, – together with the info that an image layer in APub is different from one in ID – this compromise or workaround  appears to be sort of the answer to your question about the X on the Picture Frames that were set on purpose this way in ID.

I don't know the HDML format but it sounds its limitations made you choose this workflow in ID … which then appeared in APub accordingly.

8 hours ago, PaoloT said:

it is extremely annoying while editing or previewing. It's as if there is a report of errors in the picture frame. So, I hope the situation I'm seeing is just some but or some operator error from my side, and not an intended behavior of the program.

If this workflow is a must for you I guess you only can ignore the X in this situation(s). – I'd say it is both: "some operator error from my (your) side" AND "an intended behavior of the program" (to indicate improperly nested objects within a Picture Frame).

[PaoloT]

7 hours ago, thomaso said:

If this workflow is a must for you I guess you only can ignore the X in this situation(s). – I'd say it is both: "some operator error from my (your) side" AND "an intended behavior of the program" (to indicate improperly nested objects within a Picture Frame).

ID doesn't report it as an error, being more tolerant to alternative ways of building that type of block. I don't see particular reasons for not allowing it. And, when Publisher will finally export HTML, maybe it will also be a desired behavior in Publisher. Hard to know if there will be a more direct way of doing this type of things, but I think it is the way Divs work in HTML: you can't leave free-floating images without a container.

Paolo

 

[thomaso]

4 hours ago, PaoloT said:

ID doesn't report it as an error, being more tolerant to alternative ways of building that type of block. I don't see particular reasons for not allowing it. And, when Publisher will finally export HTML, maybe it will also be a desired behavior in Publisher.

Both apps, ID and APub, do not report it as an error, instead both use the X in the interface as an info while the X may get set invisible by the user in both apps with their "preview" display mode and does not get exported/printed in both apps.

One particular reason for differences is the different use of layer structure, hierarchy and handling. Wheres ID offers separate buttons in its toolbar to navigate between parent and child objects APub has buttons to move layers hierarchically – while both features have different approaches. In ID the user needs to interact with the layers panel a lot less than in APub, where the panel is one of the most important interface items. Accordingly, the higher "tolerance" of ID corresponds with higher "flexibility" in APub. For instance, in APub we are enabled to nest several single or grouped layers in one Picture Frame while in ID we are forced to group them all to only 1 before nesting, which forces this additional layers of this thread that appear to be redundant in APub and make you feel an "error".

Therefore a comparison especially of layer handling in both apps must sort of 'fail': the two apps 'simply' base on different concepts regarding layer structure and handling. Personally I appreciate the reduced need to use the layers panel in ID, nevertheless, my individual preference doesn't help me to use APub but I need to understand and follow its rules.

A prophecy about future features like compatibility with other file types or page describing scripts like HDML or HTML and any requirement of being prepared appears useless as long we know neither a schedule for APub nor the development of the aiming format. While for web a roadmap is published (due to its 'public' way of development), I vaguely remember there being statements from Serif moderators that there were no plans for web-based features in Affinity.

[PaoloT]

21 hours ago, thomaso said:

One particular reason for differences is the different use of layer structure, hierarchy and handling.

I appreciate this, and I'm open to changes. Also considering that InDesign is still far from perfect, and development has been stagnating for the latest ten years.

21 hours ago, thomaso said:

A prophecy about future features like compatibility with other file types […] appears useless

Not in my case, since I'm not using Publisher for work and it is still "in perspective". I'm just exploring it to be prepared to switch, in case it will match my requirements. If it will not happen, it will not happen. If it will, I hope to give my small, hopefully useful, contribution so that future versions will go near to what I would like them to be.

Paolo