Bug 106969 - Importing a Base table to Calc shows garbled characters (Windows)
Summary: Importing a Base table to Calc shows garbled characters (Windows)
Status: RESOLVED DUPLICATE of bug 39124
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.6.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-05 10:22 UTC by Michail Pappas
Modified: 2017-04-06 11:10 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
Test database (3.51 KB, application/vnd.sun.xml.base)
2017-04-05 10:22 UTC, Michail Pappas
Details
Resulting spreadsheet with pasted info (10.26 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-04-05 10:23 UTC, Michail Pappas
Details
Table content (from database), in Greek (22.97 KB, image/png)
2017-04-05 10:24 UTC, Michail Pappas
Details
Spreadheet content, Greek characters from 2nd row unreadable (73.34 KB, image/png)
2017-04-05 10:24 UTC, Michail Pappas
Details
Screenshot of Greek char representation after copying to Calc (701.63 KB, image/png)
2017-04-06 07:13 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michail Pappas 2017-04-05 10:22:46 UTC
Created attachment 132345 [details]
Test database

Libreoffice on Windows 10 64-bit, also tested on Windows XP 32-bit, both on Greek locale and Greek versions of Libreoffice still 5.2.6.2

I have filed this as LibO Calc issue, since there was nothing general. Could be Java- or Base-related too.

I wanted to export some database tables to spreadsheets. I have attached an example test.odb base, as well as a screenshot of what the single table of this database contains, as base.png.

I copy the table (right-click on table name, from the table list abd select "copy". I create a new LibO calc document and select paste. 

The end result is shown in the attached calc.png file. Text fields are shown with gibberish characters.

Two important remarks:

1) If you closely examine calc.png, you'll observe that the very first line, which contains the table field names, is displayed correctly in Greek.

If instead of LibO calc I select an empty Libo write document to paste into, characters display just fine in Greek!

2) If you examine the ODS file screenshot, you'll see that column legends (that is, the base field names) are *correctly* displayed in Greek. But not the actual data, which seems quite puzzling to me!
Comment 1 Michail Pappas 2017-04-05 10:23:21 UTC
Created attachment 132346 [details]
Resulting spreadsheet with pasted info
Comment 2 Michail Pappas 2017-04-05 10:24:08 UTC
Created attachment 132347 [details]
Table content (from database), in Greek
Comment 3 Michail Pappas 2017-04-05 10:24:57 UTC
Created attachment 132348 [details]
Spreadheet content, Greek characters from 2nd row unreadable
Comment 4 Alex Thurgood 2017-04-06 07:12:52 UTC
Works for me on OSX 10.12.3 and

Version: 5.2.6.2
Build ID: a3100ed2409ebf1c212f5048fbe377c281438fdc
Threads CPU : 8; Version de l'OS :Mac OS X 10.12.3; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group


see enclosed screenshot

Is this a Win only problem ?
Comment 5 Alex Thurgood 2017-04-06 07:13:54 UTC
Created attachment 132362 [details]
Screenshot of Greek char representation after copying to Calc
Comment 6 Alex Thurgood 2017-04-06 07:17:43 UTC
For the test, I tried both Copy/Paste via the menu / keyboard shortcuts, and drag and drop from Base to Calc.
Comment 7 Michail Pappas 2017-04-06 07:18:13 UTC
(In reply to Alex Thurgood from comment #4)
> Is this a Win only problem ?

Beats me, perhaps someone with a different (or Greek) locale on Windows can add to this issue his/her own findings.

And, BTW, I saw that you've changed the issue subject; it is not a Windows 10-only issue, it also affects my Windows XP installations.
Comment 8 Michail Pappas 2017-04-06 07:26:06 UTC
(In reply to Alex Thurgood from comment #6)
> For the test, I tried both Copy/Paste via the menu / keyboard shortcuts, and
> drag and drop from Base to Calc.

I was not aware that it was possible to copy/paste here with drag and drop. Results:

* With drag and drop to empty Calc: SUCCESS
* With copy from base and normal paste to empty Calc: FAIL
* With copy from base and special paste (either RTF or HTML) to empty Calc: FAIL
Comment 9 Alex Thurgood 2017-04-06 09:34:42 UTC
(In reply to Michail Pappas from comment #8)


> I was not aware that it was possible to copy/paste here with drag and drop.
> Results:
> 
> * With drag and drop to empty Calc: SUCCESS
> * With copy from base and normal paste to empty Calc: FAIL
> * With copy from base and special paste (either RTF or HTML) to empty Calc:
> FAIL

This rings a bell, as in, I think it has been reported already, so possible duplicate, but would need to check.
Comment 10 Michail Pappas 2017-04-06 09:39:15 UTC
(In reply to Alex Thurgood from comment #9)
> This rings a bell, as in, I think it has been reported already, so possible
> duplicate, but would need to check.

I see, I was not able to find something when searching.

OT a bit, but since the bug affects 32-bit Windows (XP) as well, should perhaps Hardware be set to "All" instead of "x86-64 (AMD64)"?
Comment 11 Alex Thurgood 2017-04-06 09:42:06 UTC
Possible DUP of bug 39124 ?
Comment 12 Michail Pappas 2017-04-06 09:47:37 UTC
(In reply to Alex Thurgood from comment #11)
> Possible DUP of bug 39124 ?

I believe so, from what I've read there. 

So, how does one proceed? Close this one as a DUP and proceed there?
Comment 13 Alex Thurgood 2017-04-06 09:49:38 UTC
Yep, don't worry, I'll do it.

*** This bug has been marked as a duplicate of bug 39124 ***
Comment 14 Alex Thurgood 2017-04-06 09:52:23 UTC
(In reply to Michail Pappas from comment #12)
> (In reply to Alex Thurgood from comment #11)
> > Possible DUP of bug 39124 ?
> 
> I believe so, from what I've read there. 
> 
> So, how does one proceed? Close this one as a DUP and proceed there?

It would be a good idea to add your findings re 5262 to bug 39124 too, as the report keeps getting automatic queries to set to WFM or resolved, when quite clearly it isn't (at least not for JP or GR).
Comment 15 Michail Pappas 2017-04-06 11:10:09 UTC
(In reply to Alex Thurgood from comment #14)
> It would be a good idea to add your findings re 5262 to bug 39124 too, as
> the report keeps getting automatic queries to set to WFM or resolved, when
> quite clearly it isn't (at least not for JP or GR).
Done! If you think I should add something more, I'd be happy to do so, just let me know what to add.