Issue 108388 - Native language characters are not inserted properly
Summary: Native language characters are not inserted properly
Status: UNCONFIRMED
Alias: None
Product: Internationalization
Classification: Code
Component: ui (show other issues)
Version: OOO320m9
Hardware: All Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-17 11:40 UTC by lobayeasmeen
Modified: 2014-06-14 20:24 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Characters are nor inserted preoperly (127.73 KB, image/jpeg)
2010-01-19 04:31 UTC, lobayeasmeen
no flags Details
attempt to reproduce (77.00 KB, application/vnd.oasis.opendocument.presentation)
2014-06-14 20:24 UTC, j19sch
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description lobayeasmeen 2010-01-17 11:40:38 UTC
* Comments in Impress

1. Select [Tools] -> [Options] -> [User Data], and enter First, Last name and
Initial

2. Open Impress Document

3. Choose [Insert] -> [Comment]

4. Insert comment in native language characters

5. Choose [View] -> [Comment] repeatedly

6. Click arrow button in Comment window and select "Delete Comment" 

In step4 "Native language characters are not inserted properly, characters been
showing as boxes."
Comment 1 stefan.baltzer 2010-01-18 14:32:53 UTC
Please answer some questions to circle this in:
(1) What characters from what language? - Please attach an .odt file containing
these or name their Unicode positions.
(2) What font is capable to display them?
(3) When reopening the Tools-Options-General-User Data dialog, are the
characters displayed correctly?
Comment 2 lobayeasmeen 2010-01-19 04:29:04 UTC
Sba,
Here are the answers of your query.
(1)This problem is with Bengali (bn) and none of the characters are showing. I
have added an screenshot as attachment.
(2) Mukti,MuktiNarrow,SolaimanLipi,"Lohit Bengali",Vrinda fonts are used to
display them.
(3) When reopening the Tools-Options-General-User Data dialog, the
characters are displayed correctly.
Comment 3 lobayeasmeen 2010-01-19 04:31:43 UTC
Created attachment 67284 [details]
Characters are nor inserted preoperly
Comment 4 j19sch 2014-06-14 20:24:57 UTC
Created attachment 83559 [details]
attempt to reproduce

Unable to reproduce in AOO4.1.0
Build: AOO410m18(Build:9764)  -  Rev. 1589052
OS: Win7 Professional SP1 (OS language: English; Location: Netherlands)

Pre-conditions:
1) Windows Input Language is 'Bengali (Bangladesh)' with keyboard 'Bengali'
2) Bengali font available in Windows: Mukti Narrow
3) OpenOffice Language settings: Default languages for documents - CTL: Bengali (Bangladesh)

As can be seen in the attached file 'Issue108388_Bengali_MuktiNarrow.odp', I tried the following:
1) type a space then text in comment, text box or Options > User Data (slide 1)
2) type text not preceded by space in comment, text box, note (slide 2)
3) type text not preceded by space in Options > User Data (slide 3)
Language settings and font are as described in the Pre-conditions.

With 1) I was able to reproduce boxes in the comment as per the original bug report. However, comparing screenshots it looks to me that in the orignally screenshot, the first character in the comment is not a space. So I don't think I reproduced the actual bug.
Also note that with 2) and 3) I was able to produce a box being displayed in the comment and in the User Data by entering only one character. However, this doesn't match the original report either as that had several characters inserted into the comment.

Based on my test it seems that OpenOffice handles Bengali (and perhaps other complex scripts (http://en.wikipedia.org/wiki/Complex_Text_Layout) too) in two different manners:
- In text boxes and notes the first character entered is displayed. When the second character is entered, the characters are combined if needed. If the first character is a space, this is not an issue.
- In comments and the User Data fields a square is displayed instead of the actual first character. When the second character is entered, the characters are combined if needed. If the first character is a space, character interpretation fails.

I have no idea to what degree the above is related to the original bug report, as I was not able to exactly reproduce the original report. I had to prepend a space to the text in a comment field to get multiple boxes to display.
Secondly, I see no difference in behaviour between the comments and the User Data, while the original reporter did.