Copy/paste text and pinned images

[Brian_J]

In Affinity Publisher, I used to be able to select a line of text that has a pinned image in front of it, and copy/paste the text and image. This is no longer the case — images that are in front of text are not included in the copy/paste. Pinned images that have characters before them are included; only images in front of text are not included.

I do some work that requires me to copy/paste text with pinned images in front many times, so this is a big problem for me.

Are others experiencing this issue?

Example document attached.

Windows 10 Home 22H2
Affinity 2.3.1.2217

 

 

Example Pinned Image Copy with Text.afpub

[thomaso]

I can't try V2 but there seems to be a simple fix by a slightly adjusted workflow: To ensure that an image as first character of a line gets selected and copied you can extend your selection up to the end of the line before, in your example for instance:

Start to drag-select at the end of the previous line (= place the text cursor at the end of the previous line behind "dog", then hold the shift key, then click behind "dog" of the next line). This results in a selection like this:

Then place the text cursor at the end of the selected line + use "paste". This will insert the paragraph (or line) break + the copied line as wanted. Result after "paste":

[DWright]

I have logged this with our developers

[Brian_J]

Thanks @thomaso. I’ve been making the selection in the way you suggested since the issue started occurring. I perform this type of copy/paste frequently when working with one particular document, so the extra effort it takes to select and then delete the line break in the pasted content is frustrating.

Hopefully the Serif devs can identify and correct the issue.

[thomaso]

7 minutes ago, Brian_J said:

the extra effort it takes to select and then delete the line break in the pasted content is frustrating.

There is nothing extra, it's just a different start position for selection & for pasting: both at the end of a line.

Also you could try if the selection via triple-click in a line works more reliable than dragging.

Nevertheless, maybe I am missing the point in my V1 … since DWright created a bug tag and logged the topic.

[Brian_J]

20 minutes ago, thomaso said:

There is nothing extra, it's just a different start position for selection & for pasting: both at the end of a line.

There are several aspects of selecting a single line that I find quicker and easier than starting the selection at the end of the previous line, and I didn’t previously have to delete a line break after pasting.

Due to the number of times I perform the copy/paste action, relatively minor inconveniences have a fairly significant impact on my workflow.

[thomaso]

2 minutes ago, Brian_J said:

There are several aspects of selecting a single line that I find quicker and easier than starting the selection at the end of the previous line, and I didn’t previously have to delete a line break after pasting.

What are this aspects? If I place the cursor at the end of a line then I get the next line selected by a short move downwards (or: shift + down-arrow key) … whereas if I drag-select a line horizontally I need to care more precise for both the start & end (while this method seemed to cause your issues + this thread).

Same for paste: If I place the cursor at the end of the previous line then I don't have to delete a break because the existing brake just gets replaced by the pasted. Also this gives the choice if I want to create a new line. In your initial video you did create multiple empty paragraph brakes before pasting. Nevertheless, I don't think that pressing the return key before or the delete key after pasting makes a difference in workflow efficiency.

Apart from the drag-select method and the logged issue: Doesn't triple-click (anywhere in a line) work for you to select the entire line? – Or is this a macOS feature only?

[Brian_J]

I hope this issue can be addressed in the next version release.

Thanks Affinity team.

[MikeTO]

+1

I've gotten used to copying the paragraph break from the previous paragraph so the pin will be copied but then I have to delete the paragraph break after pasting.

[Brian_J]

15 minutes ago, MikeTO said:

I've gotten used to copying the paragraph break from the previous paragraph so the pin will be copied but then I have to delete the paragraph break after pasting.

I've been doing that too. A number of the pinned element in my files are in front of the first sentence in a text frame, so I have to create a blank line in front of the text, copy, then delete the blank line... in addition to needing to delete the blank line in the pasted content.

[MikeTO]

It's also misleading because for inline images the image shown as selected is not cut, copied, or deleted.

 

 

[Brian_J]

28 minutes ago, MikeTO said:

It's also misleading because for inline images the image shown as selected is not cut, copied, or deleted.

Yeah, I've run into that too.

[thomaso]

2 hours ago, MikeTO said:

It's also misleading because for inline images the image shown as selected is not cut, copied, or deleted.

Was there any improvement / change to the pinning feature or to nested layer handling in V2 that might have influenced/caused these oddities?

[MikeTO]

1 hour ago, thomaso said:

Was there any improvement / change to the pinning feature or to nested layer handling in V2 that might have influenced/caused these oddities?

There may have been a bug fix to something similar, like anchors at the start of a paragraph. I don't really recall.