'Paste and Match Style' Does not work when multiple rows are pasted to the last formatted row of another table

When I copy multiple rows to the last row of another table using 'Paste and Match Style' under edit, the newly created rows to accommodate the multiple rows do not 'Match Style'. The last row in which the pasting happens, however, maintains the Style.

If I create another row below the pasted content and paste another set of multiple rows using the 'paste and match style' feature, the pasted content matches the style of the last Pasted Row. And all the newly created rows follow the style of the copied table.

This happens for Date formats and Number formats.

Anybody else has encountered this same issue?

How do I better solve this?

MacBook Pro 16″, macOS 12.3

Posted on Mar 21, 2022 3:43 AM

Reply
Question marked as Top-ranking reply

Posted on Mar 21, 2022 11:36 AM

Try this order of operations:


  • Count the number of rows you will copy and paste into the receiving table.
  • At the receiving table, add as many rows as needed to accommodate the data to be pasted in.
  • Select the rows in the source table and Copy.
  • Select (single click) the top left cell of the rows where the data is to be pasted.
  • In the Edit menu, choose Paste and Match Style.


Regards,

Barry

Similar questions

10 replies
Question marked as Top-ranking reply

Mar 21, 2022 11:36 AM in response to kranthikatikala

Try this order of operations:


  • Count the number of rows you will copy and paste into the receiving table.
  • At the receiving table, add as many rows as needed to accommodate the data to be pasted in.
  • Select the rows in the source table and Copy.
  • Select (single click) the top left cell of the rows where the data is to be pasted.
  • In the Edit menu, choose Paste and Match Style.


Regards,

Barry

Mar 22, 2022 1:50 AM in response to kranthikatikala

"Whether it's a bug or feature, the community has to decide.👍🏽"


Members of the community may have the opinion that it is a 'bug' or that it is 'a feature", but t;s the application's development team that gets to make the decision.



"It definitely is a bug for me as it adds more steps for me which the app could automatically take care."


That "it adds more steps 'for me'" might make it a "bad design", but doesn't make it a "bug."


But back to the topic of discussion.


"Paste and Match Style" means paste the data and apply the style set for this type of data at this location. f you copy a set of Date and Time values formatted to display January 14 2022 as 2022-01-14, then use Paste and Match Style to paste those dates into a range of cells set to display Date and Time values in the format 14 Jan, 2022 and to not display the time part, the date copied as February 2 2022, when pasted into those cells will take on the format set in the receiving cell and display as 02 Feb, 2022.


In the case you describe—pasting multiple rows of date and time values into the last row of a table—those D&T values pasted into the last row will take on the format already set for that rowset for that row. But the rest of the D & T values are being pasted into newly created rows,and those new rows are created by the need for rows to contain those dates, NOT by the user manually adding rows to the table. With such a creation it is plausable to suggest that no specific format has been set for D&T values in cells in the added rows that can be expected to be filled with D&T values.


With that in mind, having an "automatic" data format set for those cells a plausible outcome.


Recommended procedure:

Add the rows manually, then select the cells and format them as you want them to display, then use Paste and Match Style to paste the D&T values into those rows.


Regards,

Barry

Mar 22, 2022 5:10 AM in response to Barry

It is inconsistent with all the other methods of adding new rows, and even with itself. They all bring the format along.

  • Table->Add Row Below,
  • Drag down on the circle at the bottom of the column of row numbers,
  • Right click then Add Row Below,
  • Change the number of rows in the Table tab of the sidebar
  • Regular Pasting and Paste and Match Style, too, in the columns that did not get pasted into.


The only columns that don't maintain their style in new rows are the ones that get pasted into.


Because I brought the normal Paste operation into this conversation:

With the normal Paste operation you expect the cell format to get overwritten but it is not exactly that way. If the recipient cells have a data format and the copied data is "automatic", the data format of the recipient cells is maintained. The other cell characteristics (color, borders, etc) get overwritten but the data format does not. But when Paste requires it to add new rows, the data format of the new rows becomes "automatic", just like what is happening with Paste and Match Style.

Mar 23, 2022 2:28 AM in response to Barry

I really appreciate your commitment. I'm with you bro.



In the case you describe—pasting multiple rows of date and time values into the last row of a table—those D&T values pasted into the last row will take on the format already set for that rowset for that row. But the rest of the D & T values are being pasted into newly created rows,and those new rows are created by the need for rows to contain those dates, NOT by the user manually adding rows to the table. With such a creation it is plausable to suggest that no specific format has been set for D&T values in cells in the added rows that can be expected to be filled with D&T values.


One of the main uses of having different tables is to isolate formatting.

When a new row is added to a table, the formatting of the previous row is continued.

When some data is copied to paste in a particular table, that too using 'paste and match style', I expect that the formatting, even though lossy, should adhere to the destination formatting. You are saying that:

and those new rows are created by the need for rows to contain those dates, NOT by the user manually adding rows to the table

When new rows are created just for accomodating copied contents, the destination formatting need to be given priority when the data is pasted using 'paste and match style'. The destination formatting is defined by the last row and therefore, when new rows are added, the last row's formatting needs to be given priority, even though lossy, as the user has requested that way of formatting.

In this particular case, there are two options for formatting.

  1. Origin formatting - which is given priority if normally pasted.
  2. Destination formatting - which should be given priority if 'paste and match formatting' is used.



Recommended procedure:
Add the rows manually, then select the cells and format them as you want them to display, then use Paste and Match Style to paste the D&T values into those rows.


This is how I'm working now.


Mar 21, 2022 6:11 PM in response to kranthikatikala

I see what you mean by the new rows do not "maintain the style" but I am not seeing "the last row in which the pasting happens, however, maintains the Style". What I am seeing is only the existing rows maintain the style, no new rows do.


I can't say whether it is wrong or right; a bug or just inconsistent. If you manually add rows to the bottom of a table, they get the same style as the last row. If the rows get added when using "Paste and Match Style", they get the default style. Seems a little inconsistent and worth reporting to Apple via Numbers->Provide Numbers Feedback.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

'Paste and Match Style' Does not work when multiple rows are pasted to the last formatted row of another table

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.