Bug 39124 - Copying a Base table to Calc uses wrong codepage for paste
Summary: Copying a Base table to Calc uses wrong codepage for paste
Status: RESOLVED DUPLICATE of bug 126940
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.1 release
Hardware: x86 (IA32) Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 106969 (view as bug list)
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2011-07-10 20:52 UTC by Oleg
Modified: 2019-08-16 06:12 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
it shows Adobe Captivate (2.43 MB, application/zip)
2011-07-10 20:54 UTC, Oleg
Details
Test data exchange calc->base->calc (11.34 KB, application/zip)
2011-07-12 18:25 UTC, Oleg
Details
not solved (55.12 KB, image/jpeg)
2016-06-16 01:26 UTC, kartis56
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oleg 2011-07-10 20:52:38 UTC
In program CALC I took some cells in a clipboard. In program Base I have inserted a clipboard on bookmark Tables. I have created the new table "Table 1", have opened it. There there is data from CALC. I have closed this table. For this table I have chosen from the context menu Copy and have inserted in CALC. In CALC there was data from BASE with an error in the text coding. I use Russian version LibreOffice, code page 1251.
Comment 1 Oleg 2011-07-10 20:54:44 UTC
Created attachment 48948 [details]
it shows Adobe Captivate

unpack, start libreoffice-calc-base.htm
Comment 2 tester8 2011-07-11 12:43:19 UTC
Rainer, please check it.
Comment 3 Rainer Bielefeld Retired 2011-07-11 21:56:07 UTC
Unfortunately base is not my forte, but let's see. Oleg's great movie might help. May be it's a problem with the not very mature LibO codepage detection?

@Oleg:
Can you please attach an additional test kit with source document and result? that would ease testing for a Base beginner like me.
Comment 4 Oleg 2011-07-12 18:25:34 UTC
Created attachment 49030 [details]
Test data exchange calc->base->calc

see video
Comment 5 Rainer Bielefeld Retired 2011-07-12 22:59:15 UTC
[Reproducible] with "LibreOffice 3.4.1  - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:103)]" 

I did some further investigations, for that I saved reporter's CALC source column as a .csv (codepage 1251). When I want to get the same result like reporter saw with copy table / paste to CALC opening the .csv, I have to select a codepage "System" when I open .csv. That codepage is not available when I create the .csv

Copy Base Table / Paste to Writer works without problems, the contents column looks at least very similar to the Base Table, but it's not identical

Original Contents: бвгдеёжзиклмопрст
Writer Result:     бвгдеёжзиклмопрст
Wrong CALC result: бâãäå¸æçèêëìîïðñò

If my results are correct, copy Base Table / Paste to CALC wrongly changes Codepage to "System" - what ever that might mean.
Because paste to WRITER works fine, I currently see that as a CALC problem, but I may be wrong.

My be some further investigations by experts for Base and/or Base will be useful?

@Oleg:
Please contribute information concerning your
- OS WIN  Version and localization
- LibO Localization 

@Kohei:
Please feel free to reassign if it’s not your area or if provided information is not sufficient.
Comment 6 Oleg 2011-07-13 08:50:56 UTC
(In reply to comment #5)
> [Reproducible] with "LibreOffice 3.4.1  - WIN7  Home Premium (64bit) German UI
> [OOO340m1 (Build:103)]" 
> 
> I did some further investigations, for that I saved reporter's CALC source
> column as a .csv (codepage 1251). When I want to get the same result like
> reporter saw with copy table / paste to CALC opening the .csv, I have to select
> a codepage "System" when I open .csv. That codepage is not available when I
> create the .csv
> 
> Copy Base Table / Paste to Writer works without problems, the contents column
> looks at least very similar to the Base Table, but it's not identical
> 
> Original Contents: бвгдеёжзиклмопрст
> Writer Result:     бвгдеёжзиклмопрст
> Wrong CALC result: бâãäå¸æçèêëìîïðñò
> 
> If my results are correct, copy Base Table / Paste to CALC wrongly changes
> Codepage to "System" - what ever that might mean.
> Because paste to WRITER works fine, I currently see that as a CALC problem, but
> I may be wrong.
> 
> My be some further investigations by experts for Base and/or Base will be
> useful?
> 
> @Oleg:
> Please contribute information concerning your
> - OS WIN  Version and localization
> - LibO Localization 
> 
> @Kohei:
> Please feel free to reassign if it’s not your area or if provided information
> is not sufficient.
I have tried to work with MS Office. As a result I think that an error in BASE and WRITER. Both of them use the old agreement on text transformations. Only they understand each other. Investigations are not required any more
Comment 7 Björn Michaelsen 2011-12-23 13:25:36 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 8 Oleg 2011-12-23 19:47:53 UTC
- OS WIN  Version and localization: Windows 7 Enterprise SP1 Russian
- LibO Localization: Russian
Comment 9 QA Administrators 2015-04-19 03:20:54 UTC Comment hidden (obsolete)
Comment 10 Oleg 2015-04-20 12:23:22 UTC
(In reply to QA Administrators from comment #9)
I tried to execute the test on LibreOffice 4.4.1. Error is preserved. My personal computer hat Microsoft Windows 7 SP1.
Comment 11 kartis56 2016-06-10 19:14:30 UTC
this bug is present

at ja-jp, Win8.1 Pro, LibreOffice 5.1.3.2 x64
Comment 12 Oleg 2016-06-13 21:40:30 UTC
LibreOffice version is 5.0.5.2 on Wondows 7 corporate edition in this case works correctly
Comment 13 steve 2016-06-14 09:24:41 UTC
Since there is no specific commit fixing this issue, setting to WORKSFORME. FIXED is used only when a commit exists.
Comment 14 kartis56 2016-06-16 01:26:42 UTC
Created attachment 125681 [details]
not solved

it's not solved in ja-JP x64
either 5.0.6.3 nor 5.1.3.2
Comment 15 Buovjaga 2016-10-21 16:53:50 UTC
Correcting status to NEW.
Comment 16 Alex Thurgood 2017-04-06 09:49:38 UTC
*** Bug 106969 has been marked as a duplicate of this bug. ***
Comment 17 Michail Pappas 2017-04-06 09:58:10 UTC
Jumping in from Bug 106969, on which I have provided test files. Summarizing, affected platforms are:

- both Windows Xp and 10
- both 32 and 64 bit
- LibreOffice still 5.2.6.2
- Locale Greek (el_GR), codepage 1253 I believe

Interesting observations:

- Dragging a Base table to an empty Calc worksheet does *not* reproduce the issue. Copying and pasting does
- Copying and pasting affects the the transferred table data, but *not* the table field names (essentially, the first line of the resulting spreadsheet data).

I have submitted test files *and* screenshots of how these files look on my platforms.
Comment 18 Michail Pappas 2017-04-06 09:59:59 UTC
(In reply to Michail Pappas from comment #17)
> I have submitted test files *and* screenshots of how these files look on my
> platforms.
... on bug 106969.
Comment 19 Alex Thurgood 2017-04-06 10:38:37 UTC
@Eike : any idea why with drag and drop the code page is interpreted correctly, but not copy and paste (Ctrl-C/Ctrl-V or via Edit menu) ? Are different parts of the code responsible for interpreting the codepages ?
Comment 20 QA Administrators 2018-06-04 02:34:42 UTC Comment hidden (obsolete)
Comment 21 Julien Nabet 2018-06-04 07:13:13 UTC
Any update with a recent LO version (eg 6.0.4 or 5.4.7 for conservative users)?
Indeed, tdf#37859 seems a dup of this one.
Comment 22 QA Administrators 2018-12-03 13:13:53 UTC Comment hidden (obsolete)
Comment 23 Oleg 2018-12-04 02:41:09 UTC
...
> If the bug is present, please leave a comment that includes the information
> from Help - About LibreOffice.
...
Bug is present. Infomation About LibreOffice:
Version: 6.1.3.2 (x64)
Comment 24 Mike Kaganski 2019-08-16 06:12:26 UTC

*** This bug has been marked as a duplicate of bug 126940 ***