Please make copying and pasting within tables more useful

[A_B_C]

Hi there,

we’ve had some discussion about unexpected behaviour when copying and pasting data from selected table cells to other selected table cells in Affinity Publisher. Please have a look at the discussion in this thread:

• https://forum.affinity.serif.com/index.php?/topic/141854-how-to-shift-data-within-table/

To my mind, the current behaviour of the application is unfortunate. I would suggest to change it according to the following rule:

• Make the tab key sequence the natural order for pasting cell contents from the clipboard to selected cells.

Currently, we can step through an entire table by repeatedly pressing the tab key. After having placed the cursor in the top left cell of a table, we will never have to use a different key in order to reach each cell of the table, regardless of the ways in which cells are merged. That provides a natural linear order for any subset of cells belonging to a table.

Now, suppose you select m cells c_1, …, c_m, adjacent or not, merged cells counted as a single cell, from a table and copy the cell contents to the clipboard. Then it seems natural to assume that if you select a different set of n cells p_1, …, p_n and paste the clipboard contents, the selected cells will be filled with the clipboard contents according to some natural ordering. And the most natural ordering seems to be the tab ordering mentioned earlier. That is, if < is the linear tab ordering, and 

• m = n

as well as

• c_1  <  c_2  <  …  <  c_m

and

• p_1  <  p_2  <  …  <  p_n

are true, you would expect that c_i gets pasted to p_i for i = 1, …, m. But that is currently not the case. Rather, we see the following behavior, which is not only unexpected, but rather useless in practice (my use of the keyboard shortcuts Cmd+C and Cmd+V is not shown in the video):

 

Now, in the formal description above, there is still the possibility of m ≠ n, that is, m < n or n < m. But these cases do not really present a problem. 

• In the first case, that is, when the copied cell sequence c_1, …, c_m is shorter than the target sequence p_1, …, p_m, …, p_n, the cells p_(m+1), …, p_n can just be left unchanged when the clipboard contents are pasted.
• In the second case, when the copied cell sequence c_1, …, c_n, …, c_m is longer than the target sequence p_1, …, p_n, the cells c_(n+1), …, c_m can just be left unpasted.
• If no cell is selected for pasting, either a new table could be created, or pasting could be declared to be impossible, depending on the developers’ preference.

To sum up, I can really see no point in preserving the current behavior. If I actually wanted to achieve what is shown in the second part of my video above, I could always grow the table manually before pasting the contents of the red cells and make an appropriate target selection according to the method outlined in this post. That would be much more logical than the way things are set up at the moment.

Thank you for considering. 🙂

Alex

 

 

[A_B_C]

Nobody else here trying to copy and paste within tables? 🥺