Copy-Paste from One Note to Another Does Not Preserve Carriage Returns Since Full Feature Upgrade to

Chuck said:

I appreciate the confirmation that someone else out there has run into this issue also. At this juncture, I wonder if FaithLife is going to respond. ~ch

When I try to reproduce the issue, I cannot see what you see. Even complex text (indented paragraphs, bullet lists) are reproduced correctly. I'm sorry that I cannot help.

I am having similar issues. In the desktop app, if I open an already created note, copy an entry that has pre-formated indentions, and then repaste it back into the note below the original entry, the copied entry loses the indentions. Major BUG. Thankfully, I am not having a similar issue in the mobile app.

I would post a pic, but apparently my security software updated and now I am not able to make screen grabs; I just get blank screens. Frustrating, especially since I can't find any place to disable this action.

I am having a multiplicity of Notes bugs occur in both the desktop app and the mobile app. One thing is that they don't seem to have the same functionality. I notice in the mobile app that even though the text entry window uses a sans serif font, in some of my notes what appears in the pop-up is a serif font and sometimes it is a sans serif font. No clue what causes that variation.

I was hoping to see this get fixed, given the updates that were pushed these past few weeks but doesn’t appear so. I’m still experiencing this bug.

I was hopeful that the recent release of Logos 9.7 would've addressed this issue since the release notes page states "improved note text editing performance" but I was mistaken. Still having the same copy and paste problem. Maybe next time!

J. Remington Bowling said:

Tabs aren't preserved as part of the source formatting, they are preserved in the plain text. Block indentation seems to behave as if it's an html wrapper, the source formatting preserves it, but you only get a closing tag if you end with a new-line. Plain text converts it to four spaces. Two consecutive new-line characters are not preserved in the source formatting, but are preserved in the plain text.

The notes feature in Logos doesn't preserve block characters. It doesn't preserve any line that consists only of a new-line character (why double, triple, etc. line-breaks aren't preserved). It converts tabs to spaces, and doesn't convert a single space unless the line ends with a new-line character. If you use more than one space character, it will carry over without the new-line character, but cut the number of spaces in half if it's an even number of spaces: 2 becomes 1, 4 becomes 2, and so on. And reduces it by an increasing number if its odd.

J. Remington Bowling said:

Or a patchwork of different formatting syntaxes that the notes feature has used over the years?

To me it sounds like a patchwork of different features and bug fix attempts implemented by different programmers over a long period of time.

Any updates on a solution? There's been a number of releases since its been acknowledged but no fix yet. Thanks. 

Bump

These sorts of things might seem like a small, easy fix (and maybe it is in this case but is getting knocked down the priority list for various reasons) but having dealt with character encoding some for hobby projects... I found it to have a lot more complexity than I would have thought.

OP says "carriage returns" aren't preserved. On Unix, I don't think carriage return (\r or 0x0d) is common, but I think I've read in the past that Windows does tend to insert it, followed by the new line character (\n or 0x0a) when a user presses 'enter'. I wrote a small program in Rust that grabs what's on the system clipboard (it's just a couple lines of code with clipboard crate) and print out the hex values.

When I copied some text from Logos notes on Windows that had line breaks, the carriage returns and line breaks were in fact there. There were some other things there too in some of the copies (like non-breaking white space) and stripping out the carriage returns and simply having the new line character in the text seemed to fix the issue when pasting the content back into a Logos note. But then my short program didn't preserve the superscript unicodes and even a cursory thought of how I might do that and then the other issues I might run into with a program dealing with Greek, Latin, etc. and I noped-out.

Anyway, maybe it's not the copy-out that's the problem, but more specifically the paste in portion of what Logos is doing.