Created attachment 114314 [details] Sample File produced in Excel 4.0 format. Hi, We are using a crm software that uses a converter producing xls reports in Excel 4.0 format (At least that is what Excel 2003 says while trying to save it.) The file is opened by Libreoffice with a bug that some Turkish characters are not being displayed correctly. In Excel 2003 , the file opens without any character problems. If need anymore info, please ask me. Thanks, Burak
Please attach a screenshot from excel and LO to see where is difference. Thank you.
Created attachment 114323 [details] View of file opened by LibreOffice
Created attachment 114324 [details] View of file opened by Excel 2003
Created attachment 114325 [details] File opened by Excel 2003 and saved in Excel 2003 xls format. Can be opened by LO without any character problems.
Created attachment 114327 [details] printscreen from excel2010 In excel 2010 are characters also not correct. https://en.wikipedia.org/wiki/Microsoft_Excel#Excel_4.0_.281992.29 Excel 4.0 (1992) Leaving unconfirmed, I have not excel2003.
I can see characters are correct on windows 2010. ?? Maybe it is because the fonts or font substitutions are not installed for Turkish language in your computer. Can you open the 4th in the attachment list correctly ? If works fine in LO because it is Excel 2003 format. Can you see letters fine using that file? I also suspect this is because of non-unicode Turkish font characters. In Excel 4.0, there probably was no Unicode support. So when opening the file , if there is no non-unicode Turkish fonts installed in OS , you might not see them. There is probably some non-unicode conversion being made wrong so that Turkish characters are displayed wrongly.
Created attachment 114329 [details] View of 1st sample file by Office Starter 2010. Fonts displayed correctly.
(In reply to Burak Ural from comment #6) Hello, > I can see characters are correct on windows 2010. ?? > > Maybe it is because the fonts or font substitutions are not installed for > Turkish language in your computer. My language is not Turkish > Can you open the 4th in the attachment list correctly ? I can see file "Turkish character 2003.xls" correct in excel2010 and LO 4.4.1.2 (letter Ş) > If works fine in LO because it is Excel 2003 format. Can you see letters > fine using that file? Yes
In this case, my best guess is that there is a non-unicode conversion problem in LO , concerning non-unicode Excel documents. I remember that using old formats like excel 95 was causing troubles while I was using openoffice.org , I guess this bug still comes from the past. I had a macro that was converting letters automatically when the documents opened... After Excel 97/2000/2003 format such problems did not existed anymore due to unicode support. Well it would be nice if this conversion bug can be fixed... Regards, Burak
On pc Debian x86-64 with master sources updated yesterday, I noticed this console log (5 times) sc/source/filter/excel/xistream.cxx:736: read less bytes than requested
TESTING with 4.4.2.2 + Ubuntu 14.04 (In reply to raal from comment #5) > Created attachment 114327 [details] > printscreen from excel2010 > > In excel 2010 are characters also not correct. Maybe there's an issue in Excel 2010 as well? Ideally, we'd be able to open the file in LibreOffice either way. The screenshots of the file in LibreOffice match up with my testing. If it's not a matter of missing/substituted fonts, then it appears to be an implementation issue. Status -> NEW
This file seems to have CODEPAGE record which equals to 1252 (Latin I), and LO honors it, so NOTOURBUG I believe.
(In reply to Maxim Monastirsky from comment #12) > This file seems to have CODEPAGE record which equals to 1252 (Latin I), and > LO honors it, so NOTOURBUG I believe. (And adding the ability to choose the encoding is already covered by Bug 35208, so the same way I could close it as a duplicate of Bug 35208.)
The workaround in Bug 35208 solves this one too. *** This bug has been marked as a duplicate of bug 35208 ***
*** This bug has been marked as a duplicate of bug 37408 ***
This should follow the default document language setting now. *** This bug has been marked as a duplicate of bug 132796 ***