Re: [platform-swt-dev] UTF-8 support and compliant components

[Knut Radloff <knut_radloff@xxxxxxxxxx>]

Improving the file encoding support was on the plan for 2.1 but was 
deferred. The plan item references bug 5399.
If you search new and assigned bugs for "encoding" in the summary you will 
find a couple of open problems. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=22488 and 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=36319 may be of interest to 
you.

This particular case is interesting/new. You set the file.encoding on the 
VM command line to make sure the output stream (or console) handles the 
Chinese characters correctly.
Eclipse then picks up the default editor encoding from this file.encoding 
setting. You can go and change the editor preference to ISO8859 or 
whatever you like to use for writing files to work around this. Ultimately 
though you should not have to this.  I entered bug 37107 for this. 
It seems that Debug should be added to the list of components that are 
involved in the plan item.

I'm cross posting to platform-ui-dev since this is not an SWT issue. 
Please continue the discussion on platform-ui-dev.

Knut




Andre John Mas <ajmas@xxxxxxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
04/30/2003 01:06 PM
Please respond to platform-swt-dev

 
        To:     platform-swt-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-swt-dev] UTF-8 support and compliant components



Just noticed a small problem. Now all new files I create appear to
be in UTF-8 format. It would be nice if I could specify the default
encoding used when creating a new file. If it is already there I
couldn't find it.

I am starting to feel that internationalisation and unicode support
should be looked at as an issue in general. This would hopefully
produce a document noting the current limitations and work arounds
and what should be done to make sure that the different scenarios
work properly on various platforms.

Andre

Andre John Mas wrote:
> If forgot something obvious, setting the -D option on the VM of
> the subprocess too. This gets me the following:
> 
>    123-g5Ξ㈯冓
> 
> So it works. Though while the copy and paste shows all the characters
> correctly the last two were represented as boxes in the console, 
> indicative that the font used in the console probably does not
> include the Chinese glyphs.
> 
> I wonder whether it would be possible to use the same sort of logic
> used in the Java API, and also Mozilla, to look in another font for
> the missing glyphs - or maybe this is something that the system should
> be handling?
> 
> A further test show that if you don't set the file encoding used by
> Eclipse to UTF-8, while setting that of the client process, you get
> the following (mangled data):
> 
>    123-g5Ξ㈯冓
> 
> Also, you must set the file encoding used by the child VM as a parameter
> to the VM, doing a System.setProperty() is too late, since the
> output stream has already been initialised.
> 
> Andre
> 
> Andre John Mas wrote:
> 
>> On your suggestion I tried that passing the following parameters:
>>
>>    -vmargs -Dfile.encoding=UTF-8
>>
>> based on the docs at:
>>
>>   http://dev.eclipse.org/help21/index.jsp?topic=
>>     /org.eclipse.platform.doc.user/tasks/running_eclipse.htm
>>
>> but that does not work either. I see that the file encoding is
>> is set to UTF-8 in the 'About Eclipse' window, but this doesn't
>> seem to be affecting the output.
>>
>> Andre
>>
>> Knut Radloff wrote:
>>
>>> The console is using the StyledText widget, I verified that 
>>> StyledText displays the characters correctly when using the same font 
>>> set in the Console.
>>> This doesn't appear to be font related anyway. When I run the same 
>>> println outside Eclipse, on the command line it also does not print 
>>> correctly. It looks like something gets messed up on the way through 
>>> System.out.println. What is the file.encoding VM/system property set 
>>> to? This is displayed as the default text file encoding on the 
>>> Workbench/Editors preference page.
>>> You could try running Eclipse with the vm argument 
-Dfile.encoding=UTF-8
>>>
>>> Knut
>>>
>>>
>>>
>>>
>>> Andre John Mas <ajmas@xxxxxxxxxxxxxxxx>
>>> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
>>> 04/24/2003 04:08 PM
>>> Please respond to platform-swt-dev
>>>
>>> 
>>>         To:     platform-swt-dev@xxxxxxxxxxx
>>>         cc:     Steve_Northover@xxxxxxxxxx
>>>         Subject:        Re: [platform-swt-dev] UTF-8 support and 
>>> compliant components
>>>
>>>
>>>
>>> The font I use is 'Courier New'. I have just looked at the preferences
>>> under 'Workbench -> Fonts' and I see the the 'Debug Console Text Font'
>>> is indeed Courier New. Using Notepad, Wordpad and Character Map I see
>>> that the font is capable of displaying these glyphs.
>>>
>>> I have installed all the possible language settings in Control Panel
>>> -> Regional Options.
>>>
>>> Maybe having someone try a similar test on MacOS X, which I know is 
also
>>> a unicode compliant platform may give some insight.
>>>
>>> regards
>>>
>>> Andre
>>>
[snip]

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev