Problem description: When pasting a string with double quotes, the quotes where ignored in previous versions. In 4.1.0.1rc they are not. Steps to reproduce: 1. copy "essai" 2. paste in calc Current behavior: the cell contains "essai" Expected behavior: the celle should be essai Operating System: Windows 7 Version: 4.1.0.1 rc Last worked in: 4.0.4.2 release
Hi Danny, Thanks for the report. I see the behaviour in 4.1.0rc1, but in 4.0.4 and 3.6.6 the behaviour is the same. In any case on Ubuntu.... So ?? Regards, Cor
The same with Mageia. But I'm using W7 at office and before 4.1 all was same as with Excel (quotes ignored), that's why I named it a regression.
I was unable to recreate this bug. I tested in LO 4.0.4.2 , LO 4.1.0.1 and Excel 2010. Each time I copied "essai" and then pasted "essai". "essai" appeared in the cell after each paste. Used: WIN 8 x86_64
If you simply paste the copied text, it will indeed contain the double quotes. That is because copying from browser copies with formatting, and paste by default chooses formatted text. But if you choose Paste Special -> Plain Text, it will be pasted without quotes. (I tested with 3.6.3.2)
I am using Office2003 and the copy was made within scite or any other editor. In previous versions (and we are using LO/OO for a long time) the paste in calc ignores the double quotes " as does Office2003. No Office2010 for verifying.
I can confirm the described behavior. In Excel 2010 when copying "essai" from a plain-text document and pasting that text in a spreadsheed only essai appears. That behavior does indeed not occur when copying the text from a browser. When doing the same using LO 4.1.0.1 "essai" appears in the cell despite being copied from a plaintext document. Setting to NEW. OS to ALL. But I'm not sure if this is really a bug? Maybe it's rather a bug with MS Office? In my opinion if you copy paste something and the content you copied does arrive as copied that's not really a bug is it? Can a dev elaborate on this? Maybe NOTABUG?
The double quotes are used to identify the content as a string. It is difficult to import data automatically without such a pseudo-formatting.
(In reply to comment #4) > But if you choose Paste Special -> Plain Text, it will be pasted without > quotes. (I tested with 3.6.3.2) Where in the summary/title of this bug, or in the initial description, is stated that paste as plain text is involved?
(In reply to comment #6) > I can confirm the described behavior. You do not ... > In Excel 2010 when copying "essai" from a plain-text document and pasting > that text in a spreadsheed only essai appears. That behavior does indeed not > occur when copying the text from a browser. Because we test LibreOffice here, not excel :)
As it is now, will close this as WorksForMe. Just waiting for some decent information...
Cor, (In reply to comment #8) > Where in the summary/title of this bug, or in the initial description, is > stated that paste as plain text is involved? The OP seems to have forgotten to mention this; or doesn't know these technical details. This led to inability of triagers to reproduce the stated behavior. I gave missed information; confirmed behavior in older LO versions. The triage work consists partly in helping users to describe problems clearer, or sometimes do it for them; what do you find wrong here? (In reply to comment #9) Then Wilhelm confirms the current state in LO 4.1 (taking the new information into account), and its divergence with MS Excel (this was mentioned by OP in Comment 2). What could be so bad here, that you chose to ignore the third paragraph of Comment 6 and state that Wilhelm talked about Excel only? The abovementioned data confirms the OP observation; the only piece left is decision on is it a problem or intended change, and thus should it be fixed or not. Probably you need some more information, then please ask for it. I'm afraid you had a bad day. :) Take it easy!
Hi Mike, (In reply to comment #11) > I'm afraid you had a bad day. :) Take it easy! Hmm, that goes without a saying :) To be more precise: I'm a bit too tired currently to try to do the right interpretation of comments. Triaging of comments on reports that need to be triaged ... :) So pls, when someone finds that a summary is not precise, incomplete: update it. Handy for all that search issues, start working on a specific one etc. usw. OK, apologies for sounding a bit harsh before. I can confirm this one :) (And indeed: is it intended, and improvement, or a regression ??)
Could it be Commit 9dba77d1b5bb2d513e8d6b67c83dc6e858e35f66? Just in case, I CC Eike Rathke (the author of said commit). Eike, could you please advise on this problem?
Pasting a single line as unformatted text shall paste all text in the clipboard and not attempt to automatically modify content. Earlier versions did that, which was wrong and even lead to erroneous behavior like pasting "foo" bar baz resulted in foo only.
Well... I see it a good option to treat a string containing two and only two double quotes at the very start and at the very end of the text as a special case. This would enable the scenario that OP described - when a string to be pasted that otherwise would be treated as a number, or a date/time, etc. If such a check would exist, the mentioned "foo" bar baz string would be treated as the one that must go as is - containing spaces, and "123" would become string 123, not number. However, another option for OP could be not to enclose the copied text in quotes, but adding single apostrophe in front of such "numbers". The decision made by Eike has the advantage that it makes the paste operation consistent, and there will be no surprise when one gets different results copying the same text from plain-text editor or from web page.
The advantage of the double quote solution for identifying strings is that it was supported by the two office suites used in our enterprise. Sure I can use a single quote with LO, but since >LO 3.3 I had to replace it after pasting because it appears in the cell.
And the treatment of double quotes is also used when opening csv files.
(In reply to comment #15) > I see it a good option to treat a string containing two and only two double > quotes at the very start and at the very end of the text as a special case. Not sufficient. Consider "foo" bar "baz" that then would result in foo" bar "baz Even worse with "foo" "bar" "baz" to become foo" "bar" "baz > This would enable the scenario that OP described - when a string to be > pasted that otherwise would be treated as a number, or a date/time, etc. If > such a check would exist, the mentioned "foo" bar baz string would be > treated as the one that must go as is - containing spaces, and "123" would > become string 123, not number. Remember that this is about clipboard content, so why not just select and copy 123 instead of "123"? (In reply to comment #17) > And the treatment of double quotes is also used when opening csv files. With which you get a dialog where you can tweak things, no hidden automatic processing. This dialog btw is also presented when pasting clipboard content that consists of more than one line.
(In reply to comment #18) > (In reply to comment #15) > > I see it a good option to treat a string containing two and only two double > > quotes at the very start and at the very end of the text as a special case. > > Not sufficient. Consider > "foo" bar "baz" > that then would result in > foo" bar "baz > Even worse with > "foo" "bar" "baz" > to become > foo" "bar" "baz Sufficient :) You misread my sentence: "Two and only two". It means that if a double quote happens in between, the check fails.
(In reply to comment #18) > Remember that this is about clipboard content, so why not just select and > copy 123 instead of "123"? Calc is used as the frontend for requests on databases. Some fields in the database are strings but exclusively written with numbers (ex. goods identification for french government) like 0124578. When such a field is not typed as string it comes as 124578 in Calc. I have a lot of this exemples. > > > (In reply to comment #17) > > And the treatment of double quotes is also used when opening csv files. > > With which you get a dialog where you can tweak things, no hidden automatic > processing. This dialog btw is also presented when pasting clipboard content > that consists of more than one line. But when accepting the default, the double quotes where ignored. I've mentionned this "bug" because it differs from versions before. You can consider that it should be as it is yet, but I think all data imports (paste from an other source or cvs files) should have the same treatment.