| View previous topic :: View next topic |
| Author |
Message |
HendrikPon
Agent
Joined: Jan 18, 2009
Posts: 18
|
 Posted: Mon Mar 30, 2009 10:55 am Post subject: Copy range of cell to clipboard |
|
A copy of a rectangular selection of cells of a Calc spreadsheet to the clipboard leads to the following. Using pbpaste in Terminal shows that every row of the selection is terminated by a carriage return \r (checked by executing pbpaste | od -c).
If I do exactly the same thing with Openoffice 3.0.1, then every row is terminated by a linefeed \n.
After pasting, another program did not recognize the rows in the NeoOffice version but did recognize the rows of the OpenOffice version.
Why the difference?
Berend |
|
| Back to top |
|
 |
pluby
The Architect
Joined: Jun 16, 2003
Posts: 11949
|
| Posted: Mon Mar 30, 2009 11:10 am Post subject: |
|
I can reproduce this bug in both NeoOffice 3.0 Patch 0 and NeoOffice 2.2.5 Patch 8 but not in my matching Go-oo builds so this is definitely a bug in our NeoOffice code.
I have created bug 3438 to track our investigation of this bug. Please add yourself to the CC: list in the bug if you would like to track its progress and to get automatically notified when we have a test patch available.
Patrick |
|
| Back to top |
|
|
pluby
The Architect
Joined: Jun 16, 2003
Posts: 11949
|
| Posted: Mon Mar 30, 2009 8:21 pm Post subject: |
|
After looking at the revision logs for NeoOffice's clipboard code this evening, I found the reason that NeoOffice's is replacing newlines with carriage returns when pasting to the clipboard: back in 2004 this behavior fixed a common bug.
Back then, most Mac OS X applications had been moved from Mac Classic to Mac OS X, but many still treated carriage returns as the system newline character (unlike Mac OS X and other Unix variants, Mac Classic always used the carriage return as the newline character). So, to ensure compatibility with most Mac OS X and Mac Classic applications in use at the time, we replaced all newline characters with carriage returns when pasting to the system clipboard.
Now that 4 or 5 years have passed, I think it is pretty safe to assume that this problem does not exist anymore or only exists in a very small number of applications and I will remove this old bug fix.
I will post again when I have a test patch available.
Patrick |
|
| Back to top |
|
|
pluby
The Architect
Joined: Jun 16, 2003
Posts: 11949
|
| Posted: Wed Apr 01, 2009 12:20 pm Post subject: |
|
I think that I have fixed this bug and I have posted links to test patches for both NeoOffice 2.2.5 and NeoOffice 3.0 in my last post in bug 3438.
Can you install the test patch and tell us if the bug is fixed for you?
Patrick |
|
| Back to top |
|
|
HendrikPon
Agent
Joined: Jan 18, 2009
Posts: 18
|
| Posted: Thu Apr 02, 2009 12:03 pm Post subject: |
|
I have just now installed the patch.
And tested it.
Copying and pasting in Terminal with pbpaste and checking with od -c showed that all copied rows are now ended with a \n.
Pasting into the other program and it identified all rows correctly.
It appears to be fixed.
Thanks a lot. Wonderful job.
Berend |
|
| Back to top |
|
|
siderea
Blue Pill
Joined: Apr 10, 2009
Posts: 4
Location: The Netherlands
|
| Posted: Fri Apr 10, 2009 1:51 am Post subject: bug 3438 |
|
After patching NeoOffice 2.2.5. to patch 9, I cannot copy/paste any data from Calc into a "Pro Fit" 6.1.9 datawindow (demo at www.quansoft.com). Reading this discussion I would strongly request to restore things like they were before patch 9 OR at least to keep it the same as in OpenOffice.org.
Before Patch 9 I was able to copy/paste multiple columns from Calc to "Pro Fit", something even OpenOffice.org does NOT handle at all.
I will inform the developers of "Pro Fit" of this issue/bug and tell them to be extremely careful making any changes to their wonderful program because there's obviously no way to predict NeoOffice's future behaviour. |
|
| Back to top |
|
|
James3359
The Merovingian
Joined: Jul 05, 2005
Posts: 685
Location: North West England
|
| Posted: Fri Apr 10, 2009 3:17 am Post subject: |
|
As far as I can tell, both NeoOffice and OpenOffice.org follow what is now standard practice on Mac OSX applications. Previously NO had to modify the OOo behaviour to ensure Mac compatibility. Now the Mac practice has changed and NO no longer has to alter OOo behaviour in order to achieve Mac like behaviour. So NO now does the same as OOo.
It is true that Quansoft are unable to predict NeoOffice's behaviour (and vice versa), but this change is a move towards the current Mac standard (see the helpful Wikipedia New line article), so it would probably be worth Quansoft seeing if they can accommodate data pasted in that format as it is increasingly likely that other applications will provide data in that way. |
|
| Back to top |
|
|
pluby
The Architect
Joined: Jun 16, 2003
Posts: 11949
|
| Posted: Fri Apr 10, 2009 5:51 am Post subject: |
|
| James3359 wrote: | | It is true that Quansoft are unable to predict NeoOffice's behaviour (and vice versa), but this change is a move towards the current Mac standard (see the helpful Wikipedia New line article), so it would probably be worth Quansoft seeing if they can accommodate data pasted in that format as it is increasingly likely that other applications will provide data in that way. |
I agree. The newline character have been the Mac OS X standard since 10.0 and now that Mac OS X has been out for 9 years, so it is a bit unreasonable for other applications to expect carriage returns at this point.
I understand that there are some applications like Quansoft that have been slow to adjust to this 9 year old standard, but such applications are now the exception, not the rule and we generally code NeoOffice to the most commonly used applications on our supported platforms. Frankly, it seems quite unfair to have our code remain non-compliant with the Mac OS X standard for 95% or more of applications just to accomodate the 5% or less of applications that will not comply with a 9 year old standard.
Patrick |
|
| Back to top |
|
|
pluby
The Architect
Joined: Jun 16, 2003
Posts: 11949
|
| Posted: Fri Apr 10, 2009 7:14 am Post subject: |
|
After my last post, I thought about this problem and I think I have been able to fine tune my fix for bug 3428 so that most older applications will get carriage returns while newer applcations will get newlines. I did this by restoring the conversion of newlines to carriage returns but only for the single byte text data flavor as most newer applications use the double byte text or RTF data flavors.
I have verified that with the following test patch, pasting into Quansoft proFit works.
Can anyone install the test patch from the links in my last post in bug 3438 and tell us if the test patch fixes the Quansoft pasting problem without breaking the HendrikPon's bug?
Patrick |
|
| Back to top |
|
|
siderea
Blue Pill
Joined: Apr 10, 2009
Posts: 4
Location: The Netherlands
|
| Posted: Fri Apr 10, 2009 10:20 am Post subject: |
|
In my previous post I referred to the wrong patch number. 9 must be 8.
James3359.
If NeoO moves towards the current OSX standard, that's fine by me. Didn't realize there were still OS9 fixes in NeoO (is it that bad??).
Pluby.
I tried your new NeoO Test Patch 8 but it did not fix my problem.
In the meantime Quansoft replied to my mail and they are not yet certain this problem really exists. And they want me to 'update' the statements I made in my previous post, which I won't. I replied with some screenshots of the problem.
We'll see. We'll post. |
|
| Back to top |
|
|
pluby
The Architect
Joined: Jun 16, 2003
Posts: 11949
|
| Posted: Fri Apr 10, 2009 11:29 am Post subject: |
|
| siderea wrote: | Pluby.
I tried your new NeoO Test Patch 8 but it did not fix my problem. |
I found an error in my test patch so it makes sense that you saw no change in the test patch. I will correct the code, retest, and upload a new test patch today if I can get it to work.
| siderea wrote: | | In the meantime Quansoft replied to my mail and they are not yet certain this problem really exists. And they want me to 'update' the statements I made in my previous post, which I won't. I replied with some screenshots of the problem. |
They are not certain? That is an odd conclusion. Their bug is that they treat newline characters as regular characters instead of what it actually is: a linefeed.
Both Microsoft Office and NeoOffice have no problem recognizing that either newline or carriage return characters signify a linefeed when pasting.
Patrick |
|
| Back to top |
|
|
pluby
The Architect
Joined: Jun 16, 2003
Posts: 11949
|
| Posted: Fri Apr 10, 2009 11:57 am Post subject: |
|
I found that my last test patch does nothing different than the last official patch. Because of a typo on my part, the last test patch converted carriage returns to newlines. Since I want the code to do the opposite, I have corrected my typo in the code and uploaded new test patches.
I have verified that with the following test patch, pasting into Quansoft proFit works.
Can anyone install the test patch from the links in my last post in bug 3438 and tell us if the test patch fixes the Quansoft pasting problem without breaking the HendrikPon's bug?
Patrick |
|
| Back to top |
|
|
siderea
Blue Pill
Joined: Apr 10, 2009
Posts: 4
Location: The Netherlands
|
| Posted: Fri Apr 10, 2009 3:58 pm Post subject: |
|
Have installed and tested NeoOffice-2.2.5-Patch-8-Test-8-Intel.
A copy/paste from Calc to a Pro Fit datawindow now behaves the same as it did with NeoO 2.2.5. patch 0.
This means that Pluby fixed the Quansoft (Pro Fit) pasting problem !!
Many thanks Patrick,
Kirk out. |
|
| Back to top |
|
|
pluby
The Architect
Joined: Jun 16, 2003
Posts: 11949
|
| Posted: Fri Apr 10, 2009 4:24 pm Post subject: |
|
That is good news.
HendrikPon,
Can you install the latest test patch and tell us if the bug is still fixed for you?
Patrick |
|
| Back to top |
|
|
siderea
Blue Pill
Joined: Apr 10, 2009
Posts: 4
Location: The Netherlands
|
| Posted: Mon Apr 13, 2009 1:45 am Post subject: |
|
If have received a response from Quansoft regarding pluby's Patch-8-Test-8. Apart from some technical notes, here's the bottom line:
| Quansoft wrote: |
This makes the bug-fix of pluby exactly the right thing to do: He let neooffice create either one-byte or two-byte text on the clipboard (or both? I don't know), and he is terminating the one-byte text with carriage returns.
He is also terminating the two-byte text with line-feeds, but this does not matter for pro Fit, because both \n and \r are interpreted in the same way for unicode text.
thanks a lot for your feedback!
|
It seems that everybody is happy now.
Rob
Edit by Samwise: fix quote |
|
| Back to top |
|
|
|
