Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 367809

Summary:

[SWT Mac OS X] path.addString does not appear to handle unicode properly

Product:

[Eclipse Project] Platform

Reporter:

Michel Parisien <codingkriggs>

Component:

SWT

Assignee:

Silenio Quarti <Silenio_Quarti>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

eclipse.felipe, remy.suen, Silenio_Quarti

Version:

4.2

Target Milestone:

3.8 M5

Hardware:

Macintosh

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Attachments:

Description	Flags
A program to replicate the issue	none
Produced shell on Mac OS X Cocoa 64 bit from attached source code	none

Description Michel Parisien

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

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

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

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

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";