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

I'm having the same issue and I feel your pain.

https://community.logos.com/discussion/comment/1168289#Comment_1168289

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

Bob

https://community.logos.com/discussion/comment/1168338#Comment_1168338

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

Confirm same issue. I submitted email to customer support. Waiting on a reply.

Bob

Jack Hairston

https://community.logos.com/discussion/comment/1168338#Comment_1168338

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.

https://community.logos.com/discussion/comment/1169503#Comment_1169503

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.

Are you using Logos 9? If you upgraded from 8, did you get the Full-Feature Upgrade? Also, are you on PC or Mac? I'm on PC. ~Thanks, Chuck

https://community.logos.com/discussion/comment/1169533#Comment_1169533

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.

Graham Criddle

https://community.logos.com/discussion/comment/1169556#Comment_1169556

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

David - I think this demonstrates what you are describing. Is that correct?

I copied the top three lines and then pasted them below.

https://community.logos.com/discussion/comment/1169557#Comment_1169557

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

David - I think this demonstrates what you are describing. Is that correct?

I copied the top three lines and then pasted them below.

Graham - Your example also demonstrates what I described about paragraphs no longer being double-spaced, but instead being slammed together.

https://community.logos.com/discussion/comment/1169557#Comment_1169557

David - I think this demonstrates what you are describing. Is that correct?

Yes, that demonstrates what I am experiencing, among a number of other issues.

I am also finding that when I copy Bible text and paste it into my notes, it gets pasted in with a larger font. I have no idea why that is happening, but it basically breaks my notes altogether.

So currently, as it stands, I cannot create new notes that match my existing note scheme, especially in the desktop app. The mobile app will allow me to perform some deconstructive and reconstructive Rube Goldberg mechanics that result in something somewhat acceptable, if I don't mind pissing away 10-20 times (or more) the amount of time it ought to take. Basically I would have to find a note that has the same presentation characteristics (in other words, an appropriate template) that I have for similar notes, copy and paste that into my new note, then delete all of the data without losing the formatting, and then retyping in word-by-word whatever I want to include. This is stone ages kind of stuff going on here.

https://community.logos.com/discussion/comment/1169690#Comment_1169690

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.

https://community.logos.com/discussion/comment/1174295#Comment_1174295

This has to get fixed

NOW.

All of it...text that gets pasted from a Bible should be the same font size as text that is typed into the text entry field. Right now text copied from inside the app gets pasted into notes in a larger font than the native text font. WHY???????

https://community.logos.com/discussion/comment/1174310#Comment_1174310

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!

https://community.logos.com/discussion/comment/1174310#Comment_1174310

Entirely intolerable. [:@]

https://community.logos.com/discussion/comment/1177271#Comment_1177271

Reformatting information when copied from one note to another is tedious, time-consuming, and interrupts the flow of study. Please, FaithLife, fix this.

J. Remington Bowling

https://community.logos.com/discussion/comment/1177503#Comment_1177503

Seems like Logos is doing some odd formatting syntax, at least with new-line, tab, and block characters. You can try experimenting with this in Word and switching between paste with source formatting and paste as plain text.

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.

Maybe this is due to some side-effect of a pre-processing pipeline on pasted-in text (to check for Bible references?)? Or a patchwork of different formatting syntaxes that the notes feature has used over the years?

SineNomine

https://community.logos.com/discussion/comment/1177978#Comment_1177978

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.

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.

https://community.logos.com/discussion/comment/1177984#Comment_1177984

This thread started in MAY. It is now almost SEPTEMBER. This issue should never have been an issue. It shouldn't be allowed to exist, not even for a day. I can't use this program to accomplish my most basic requirements. I have been creating temporary placeholder memos instead of complete notes because note formatting is shot to hell. FIX THIS PROBLEM.

Do attorneys need to be contacted? Is a class action suit required??? Do I need to request a refund...I mean for the whole $40-50K smack? This is basic fundamental operations that DO NOT WORK. FIX IT.

Philana R. Crouch

Now, since the Full Feature Upgrade to Logos 9, when I copy-paste from one note to another, pasting strips carriage returns, slamming paragraphs together with no double-spacing between them.

Thanks for reporting this. I was able to reproduce the issue with double spacing and created a case.

https://community.logos.com/discussion/comment/1178101#Comment_1178101

Now, since the Full Feature Upgrade to Logos 9, when I copy-paste from one note to another, pasting strips carriage returns, slamming paragraphs together with no double-spacing between them.

Thanks for reporting this. I was able to reproduce the issue with double spacing and created a case.

Thank you. A fix soon would be most welcome. Thanks again.

https://community.logos.com/discussion/comment/1178105#Comment_1178105

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

https://community.logos.com/discussion/comment/1188409#Comment_1188409

Bump

https://community.logos.com/discussion/comment/1188409#Comment_1188409

Bump

https://community.logos.com/discussion/comment/1188409#Comment_1188409

Bumping as a reminder

MJ. Smith

https://community.logos.com/discussion/comment/1188409#Comment_1188409

Philana normally will update this thread when it is fixed. Because we do not know what code is being worked on for other projects or precisely how the code is packaged, we are in no position to assume the relationship between releases and patches for this specific issue. There are almost never any updates on the status until it appears in the beta change notes.

https://community.logos.com/discussion/comment/1195502#Comment_1195502

Thanks MJ. Pardon the repeated posts that was not my intention. Not sure if it's related to my cookies but it never posted my first reply after I submitted it for some reason.

https://community.logos.com/discussion/comment/1195502#Comment_1195502

This has gone on for months now and is a real downer to productivity. It seems that a word processing change like this should be a relatively minor fix.

https://community.logos.com/discussion/comment/1195651#Comment_1195651

Well over a year and this PRODUCTIVITY KILLER still remains active and unresolved. Class action, anyone?

J. Remington Bowling

https://community.logos.com/discussion/comment/1195651#Comment_1195651

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.

https://community.logos.com/discussion/comment/1216670#Comment_1216670

The thing is, it worked in Logos 8 Notes. The whole point of the software is to enhance study flow and make it more efficient, not divert attention and waste time with the mundane task of reformatting something I already formatted when I originally wrote it!

https://community.logos.com/discussion/comment/1216680#Comment_1216680

EXACTLY!! And it's for this reason...we already HAD the features and utility we desired, needed, and used on a daily basis that was part of an entrenched workflow, and we had these basic, work-a-day functions ripped from our lives...that I feel like FL should have literally stopped the production line on everything else until this issue was resolved.

https://community.logos.com/discussion/comment/1216748#Comment_1216748

Agreed!

https://community.logos.com/discussion/comment/1216757#Comment_1216757

Should a new thread be started in the Logos 10 forum since it appears that this bug is also included in the new release?

https://community.logos.com/discussion/comment/1230074#Comment_1230074

Was just coming here to announce this continuation of failure. Utterly disappointing. I may just hold off on making my $6000 purchase of L10 until this is fixed. Besides the failure to preserve formatting, material copied from my preferred Bible does not retain footnotes or citation details. I checked in Settings for a means of including these features, but found nothing. FOR OVER A DOZEN YEARS THIS WORKED CONSISTENTLY UNTIL L9. Please fix these issues.

SineNomine

https://community.logos.com/discussion/comment/1231084#Comment_1231084

Besides the failure to preserve formatting, material copied from my preferred Bible does not retain footnotes or citation details.

Perhaps a new thread about that issue will get Faithlife's attention.

https://community.logos.com/discussion/comment/1234136#Comment_1234136

Besides the failure to preserve formatting, material copied from my preferred Bible does not retain footnotes or citation details.

Perhaps a new thread about that issue will get Faithlife's attention.

I posted something in the Logos Desktop forum. Let's see what happens.

https://community.logos.com/discussion/comment/1234177#Comment_1234177

I'm not a Desktop beta user but I did take a peek at the next release and it appears that issue is finally fixed!

https://wiki.logos.com/Logos_23.0_Beta_1

Looking forward to when it finally reaches public release!