Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 367809 - [SWT Mac OS X] path.addString does not appear to handle unicode properly
Summary: [SWT Mac OS X] path.addString does not appear to handle unicode properly
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.2   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.8 M5   Edit
Assignee: Silenio Quarti CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-04 00:55 EST by Michel Parisien CLA
Modified: 2012-01-24 13:00 EST (History)
3 users (show)

See Also:


Attachments
A program to replicate the issue (1.55 KB, application/octet-stream)
2012-01-04 01:01 EST, Michel Parisien CLA
no flags Details
Produced shell on Mac OS X Cocoa 64 bit from attached source code (11.48 KB, image/png)
2012-01-04 01:03 EST, Michel Parisien CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Parisien CLA 2012-01-04 00:55:50 EST
Build Identifier: Version: 4.2.0 Build id: I20111209-2100

In an attempt to render Japanese Kanji characters (which are essentially Chinese Han characters) using SWT's Path#addString, I discovered that none of them were rendering properly. As an example, the kanji for the number 5 instead renders as what appears to be "<". Note that this only applies to Path#addString and not to GC#drawString, which renders kanji characters properly.

I will attach a screen shot and the code to reproduce it.

Note that I have attempted to run the code I will attach to this bug on a different platform (Linux x86_64, Version: 3.7.0 Build id: I20110613-1736), and it works properly; that is, both lines show the kanji character, none show the "<". This is therefore almost certainly a platform-specific issue.

Reproducible: Always

Steps to Reproduce:
1. Execute the code I will attach with the SWT library.
2. Observe that the two lines output on the shell which appears do not output the same character; one of them is incorrectly what appears to be "<".
Comment 1 Michel Parisien CLA 2012-01-04 01:01:36 EST
Created attachment 208981 [details]
A program to replicate the issue

Run this with the proper SWT library (I am using cocoa 64 bit).
Comment 2 Michel Parisien CLA 2012-01-04 01:03:46 EST
Created attachment 208982 [details]
Produced shell on Mac OS X Cocoa 64 bit from attached source code

Screenshot of what is produced when the attached source code is run.
Comment 3 Felipe Heidrich CLA 2012-01-11 17:04:44 EST
The problem, I suspect, is that the glyph index for the Kanji character is the index in some other font (not in "Times New Roman"). This happen because of font substitution.

I little research indicates this is indeed the problem:
http://www.cocoabuilder.com/archive/cocoa/171193-nsglyph-from-unicode.html
Comment 4 Silenio Quarti CLA 2012-01-16 10:33:32 EST
Fixed

http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=1bccd9551405353b093a48e5b41738e24b6850d6

While investigating this problem, I found another problem in GC.drawString(). The commit includes a fix for this problem as well. GC.drawString() would not draw the last glyph when using the string below in the sample. The problem is that NSLayoutManager.numberOfGlyphs() returns the wrong number of glyphs if NSLayoutManager.glyphRangeForTextContainer() is not called.

			private static final String s = "\u4E94\u0644\u0632\u0E19\u0E49\u0E33";