Jump to content
You must now use your email address to sign in [click for more info] ×

How to shift data within table?


Recommended Posts

Hi there,

please have a look at the attached illustration. Suppose you want to insert the letter B in the cell right to the cell containing A and for that purpose shift the contents of all other cells by one cell, without growing or shrinking the table itself:

Table.png.64914f8e76ac9dc61abfb749be5597e1.png

Is there a way to achieve that, preferably all at once? Whenever I try to select, cut, and paste cells, the table will grow (see below). I know you can go the tedious way, cut and paste H to cell <3,2>, then G to <3,1>, then E, F to <2,2>, <2,3> respectively, then D to <2,1>, and finally C to <1,3>. That is, you can proceed row-wise, but honestly, this is very cumbersome, when you have tables with lots of data, where you just want to insert and shift cell contents. So please, if someone had a solution to this problem, I’d be more than happy to know.

Alex

 

Link to comment
Share on other sites

I don’t think you can do this with tables – functionality is primarily limited to ‘static’ data – but the (new for 1.9.x) Data Merge functionality should probably be able to do what you want.
There are already a few videos showing how to use data merge in different circumstances.
(I haven’t used it myself so I can’t help much further than offering it as something to look at.)

Link to comment
Share on other sites

Thank you Garry, for your answer! 🙂

I’ll check whether data merge can help in this instance, but … hmm … to my understanding, this is such a basic operation, it should be possible without going through data merge or similar. I feel it should be a matter of cut and paste. I fear you are right, Publisher will always grow the table instead of just pasting the contents into the selected cells. If that’s the case, I think I will have to post this as a feature request. 🙁

Link to comment
Share on other sites

A long time ago I used InDesign to create an annual calendar with a lot of dates, which was to be used in the next year. Of course, all days had to be shifted by one cell. The data merge made this very easy, should be no different in Publisher.

Link to comment
Share on other sites

You’re welcome @A_B_C

I think the Table functionality was created as it was so that we had something that was good enough for most non-complex purposes.
This meant that we had something usable early rather than having to wait much longer for something way more sophisticated.
Publisher is still very young so we can probably expect more functionality to be added in stages, but feel free to add a feature request.

If you do want to add a feature request, please take time to consider what would happen when, for example, you have merged cells. What would “shift the contents of all other cells by one cell, without growing or shrinking the table itself” actually mean in this situation?

By way of demonstration, in my attached image, if you wanted to add a new cell between E and F, what would happen to L after G moves down and to the left, forcing K to move down and to the left of the next row, meaning that K and L together are now longer than the row?
Or would only the contents of the cells move? And how would that be affected by the different sizes of the cells if, for example, some rows were shallower?
I know you might not have merged cells in your work but the software has to work with them so it needs to know what to do.

Also, Data Merge is a very young function in Publisher so if it doesn’t do exactly what you want today it might do at some point in the future; the developers are working very hard to push the applications forward where they can.

Screenshot 2021-05-10 135731.png

Link to comment
Share on other sites

4 hours ago, GarryP said:

What would “shift the contents of all other cells by one cell, without growing or shrinking the table itself” actually mean in this situation?

Same question for a table when each of its cells already has content -- what happens to the content of the last cell?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

I guess merged cells should be considered single cells, as far as their content is concerned. You would count row-wise top to bottom, each row from left to right (at least in LTR script contexts). Vertically merged cells might also find their logical place in the counting sequence then. And if there are not enough cells, then Publisher could either add a new row or truncate the clipboard contents to the available number of cells.

But before we get into “What happens, if …” questions, please take a look at the video I shared at the beginning of this thread. Does the result of my pasting operation seem logical or desirable from a usability point of view? — Regardless of which cells I select before pasting, Publisher just appends the entire table (except for cell A, which wasn’t copied to the clipboard) starting from the first cell of the selection I made. If I was actually interested in getting this result, I would just grow the table manually and make a different selection. I think Publisher should honor the selections I make before pasting contents to a table.

 

Paste.thumb.png.aa566ae6108e0892c1c2e4c1f038e0f7.png

Link to comment
Share on other sites

Interesting.
After watching the video I don’t know if that is what I would expect or not.
On the one hand it seems weird that it works that way but, on the other hand, it looks like it might be useful.

Another similar question is, if you select the cells from the table and copy, and then select the same cells but in a different order, how would you expect the cells to be pasted? Should they be pasted in ‘order-of-cell-selection’ or ‘order-of-cell-position’?
I guess that someone in the development team has already made decisions as to how it will work, so that it will work, but I have no idea why they made the decisions in the way they made them.

As for R C-R’s question, that’s interesting too, in a similar way.
Say that the user specifies that the table is of a certain size. If a paste command then means that the table needs to grow then should that happen or should the software not override the user’s initial size specification. Which user action is ‘king’, the initial sizing or the paste action? And what happens to the ‘extra’ cells if the table should not grow in size?

I haven’t got an answer to any of these questions; I can imagine each way being either useful or troublesome depending on what I might want at the time.

There’s definitely more to think about here but I’m not sure that I’m one of the people who should be thinking about it as I don’t use the table functionality enough to have a set opinion.
Either way, someone needs to make a decision and then that decision needs to documented so that users know what will happen.

Link to comment
Share on other sites

Thank you for your answer, Garry. 😀

It takes me wonder that nobody really seems to be bothered by this. Let me provide an even simpler example. In the following table, try copying Green to Blue, then Red and to Yellow.

Table.png.367504b424acd1a435d7d0dae9d74d99.png

The results are unexpected, at least to me. Copying Green to Blue works nicely. But you cannot select the red cells, copy them (or their contents plus attributes) to the clipboard, then select the yellow cells, and paste. The result is highly unexpected, and highly unusable, if you ask me. 😕

Link to comment
Share on other sites

The problem seems to be this. As soon as a “line break” (transition to different row) is involved, copying and pasting cell contents (plus cell attributes) doesn’t work anymore. Which is kind of odd, I think. Sure, tables are two-dimensional arrays, so you probably can’t expect that you should be able to copy and replace as you would do with strings or sequences of similar kinds.

On the other hand, for entering data into a table or even stepping through cell contents, why does Affinity Publisher treat the entire table as a long one-dimensional sequence of cells that can be stepped through by repeatedly pressing the Tab key? That’s handy, of course, but the same ordering logic should also be applied when you replace cell contents. The Tab-ordering should be decisive for copy & paste operations.

 

Link to comment
Share on other sites

Your ‘copy/paste red over yellow’ video looks very much like unexpected behaviour to me.
Or, to put it another way, I don’t know why anyone would expect it to do that.
I’m not entirely sure what’s happened but it looks wrong to me, and I would say it’s a good candidate for a bug report unless anyone can give a good explanation of it.

Link to comment
Share on other sites

1 hour ago, GarryP said:

I don’t know why anyone would expect it to do that.

Glad that you see it the same way as I do, Garry. I honestly don’t understand why it was implemented this way. And it’s the same principle that makes my initial example fail. 🙁

Link to comment
Share on other sites

  • Staff

I suspect this is due to what we are able to put on the clipboard, unless I've missed a trick Excel is giving me an error when I try copy cells from different rows/columns (like the red cells in the above example).

I can get this logged as an improvement however and see if we can do a bit better

Serif Europe Ltd. - www.serif.com

Link to comment
Share on other sites

You know, Jon, that would be awesome. Think of the following use scenario. I’m currently writing a documentation for a corporate font we’ve been developing over the last year, and I decided to use Publisher for that purpose. Of course, our documentation has to include glyph tables. Before submitting the font, we got the request to insert some additional glyphs at certain places in the font, thereby getting our glyph indices shifted. You can easily imagine how difficult it is to update any index-based glyph tables in Publisher. You have to copy and paste row-wise, starting from the end of the table, until you reach the cell where to insert the new glyph. Not sure if data merge would help in this case, as there are lots of unencoded glyphs in the font that are usually substituted in by OpenType features and entered into my table from the Glyph Browser of Publisher.

For all of these difficulties, I made the suggestion in the other thread. It would be great, if you could do better than most of the other DTP apps out there. Thank you! 😀

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.