(Again) Text copied out of long-text field has doubled line-break characters

[Maxim_KM]

I dunno why previous topic with this subject is closed. Issue exists and annoys.

Let me explain. I have Long Line columns with RTF enabled.

If I activate(click) on cell but DON’T go to Edit mode(when there is caret and can select parts of the text) and COPY value(Cmd + C) - I receive text wrapped in quotes("):

If I activate EDIT mode for cell(when the caret is on) and select all text and press Cmd + C - I receive DOUBLED LINE-BREAK strings:

In Both cases, it’s not what I intended to receive and my teammates need either remove doubled line breaks or remove quotes around.

Please investigate and provide solution asap.

Best regards, Maks.

[ScottWorld]

Welcome to the community, @Maxim_KM! Please report this issue to support@airtable.com, to make sure they’re aware of it.

[Bill_French]

Maxim_KM:

In Both cases, it’s not what I intended to receive

Right - these outcomes are less than ideal and can be very annoying to users. However, it’s possible what you and your team are experiencing is environmental, not Airtable.

Have you experimented with the copy buffers you are employing?

• There are many copy buffers; cmd-c, right-click-copy, [browser] edit-copy, etc.

• There are many browsers; each handle copy paste in their own ways.

• As you point out, there are also different contexts for each buffer; edit mode, display mode, end even other contexts such display in iFrame, etc.

• There are also the interpretations made on the paste side; some apps interpret CR + LF differently, and some copy operations transform CR + LF into CR + CR.

• Then there are the nuances of rich text; Airtable implements a unique flavor of Markdown (not HTML) and paste targets are free to do the same. Slack, for instance supports a completely non-standard Markdown unlike Airtable.

• We cannot rule out the influence of browsers and unique interpretations for copy and paste events across the multiple buffers.

• Lastly, we cannot easily predict how long-line texts are created; newline keyboard entry using option-return vs cmd-return insert very different character sequences. Is the content manually typed or is the content imported with new-line sequences?

Given all the variations and underlying machinery at work, it’s not surprising to encounter unexpected or undesireable outcomes. But it’s also unreasonable to expect any single vendor to behave with perfect precision with every paste target which leads me to ask - what are you pasting your content into and what method are you using? Is it…

• Cmd-v?
• Right-click-paste with formatting?
• Right-click-paste without formatting?
• Browser menu option Edit | Paste with formatting?
• Browser menu option Edit | Paste without formatting?

As you can see, despite the three-factorial options on the copy side (i.e., 27 variants), there are many more variants on the paste side.

My hunch is there’s a way for your team to perform copy-paste processes with success; you just haven’t found the one that works with all factors considered.

[Maxim_KM]

Hi Bill, thank you for your long text. Easy to read. I am a programmer by myself and I understand all variations. But the copying of text from Google Sheets never gives doubled line-breaks.

In controversy, I tried almost all suggested by you(even before you proposed) with Airtable and it always gives doubled line-breaks if we all copy from edit(Cmd+A, Cmd+C, or context menus).

I am sure they can avoid \n\n in about to be copied data.

Best regards, Maks

[Maxim_KM]

And in addition, I don’t understand what gives \n\n for compatibility. Users will have in the worst case one line-break? One line inputs will ignore any \n even if you use 3 or 4 in a row.
That leaves us, with real multiline inputs. Where it will annoy with doubled line-break texts.

[Bill_French]

Maxim_KM:

thank you for your long text.

Yeah, apologies. It would have been far shorter if I had more time. :winking_face:

Maxim_KM:

I don’t understand what gives \n\n for compatibility.

Indeed, this is nonsensical. However, (as evidenced by my post) I always take caution when asserting what is actually creating this pattern. As you point out, it doesn’t make any sense to do this, which is why I am at least reluctant to say that Airtable is doing it intentionally.

I believe the two characters are misinterpreting CR + LF to mean LF + LF, but I’m not in a position to fully identify the cause. @ScottWorld may have been right all along - get Airtable support involved and maybe @Kasra would have a moment to comment.

[Maxim_KM]

Or maybe they would have some User Preferences where we can define ways to copy out texts from tables. Simple “Maximize RTF compatibility with various edit fields when exporting”(draft naming) will do the job perfectly. It’s turned on by default so it’s safe for all users.
But when we need to copy-paste hundreds of cells(into illustrator or photoshop), this setting will save thousands of men-hours.

P.S. And you know, I even can’t think of how scripts(Apps) can help here. Only some intermediary window(or web service) which will replace \n\n with \n. But it’s additional 5-10 clicks of mouse/keys for each cell(oh, and need to write dedicated service)

[Justin_Barrett]

A long text field with rich text enabled treats line breaks in a different way. Each line isn’t just a “normal” line of text. It’s treated as a paragraph, a fact that is reinforced by the paragraph symbol appearing on the left as you’re editing the field’s contents. My guess is that the extra line break is added to copied data to make the paragraph separation clear. If you disable rich text formatting for that field, the extra line break won’t be there when you copy the text and paste it elsewhere.

With some editors that use similar paragraph styling, you can force a normal line break by typing Shift-Enter, but this doesn’t work with Airtable’s rich-text-enabled long text fields. It appears that if you want control over the line spacing, you can’t also have rich text.