Re: NSCharacterConversionException

[Richard Frith-Macdonald]

On 30 Jan 2007, at 11:51, Fred Kiefer wrote:

> Patrick schrieb:
> > I am using GNUstep in a C# project.
> > When I try to create an NSFont using a NSString that contains the  
> > following
> > string: 'ＭＳ Ｐ明朝' I get the following exception from the  
> > FontWithNameSize
> > method:
> >
> > <NSException: 5fbe018> NAME:NSCharacterConversionException  
> > REASON:Can't get
> > cString from Unicode string.
> >
> > I simply have no idea what I should do. Any ideas or hints would  
> > be much
> > appreciated!
>
> It surely would help if you would try this in an Objective-C only
> application, but in this specific case it looks like a real GNUstep
> problem. :-)
>
> You did not state the environment you are running on, but from C# and
> the font name I suspect that you are on MS Windows. I would thing that
> the problem you get comes from [Win32FontInfo setupAttributes]  
> where the
> code expects to be able to call cString on the font family name and  
> this
> fails for your Asian font name. Again a full back trace in gdb would
> have been helpful.
> The only solution I can see for this problem, if I did identify it
> correctly, is to switch our whole Win32 code over to use what  
> Microsoft
> calls UNICODE, that is 16 bit w_char instead of char. As I have  
> given up
> Microsoft Windows programming years ago, we will have to look for a  
> new
> volunteer to do this.

I've converted the font handling (I hope) to use the wide version of  
the API.
The new code is in subversion (trunk).  I only addressed the font  
handling code, and there are undoubtedly other areas where unicode we  
still need to convert to unicode.

Incidentally, what Microsoft call UNICODE is pretty much the same as  
what OpenStep/GNUstep/Cocoa calls NSUnicodeStringEncoding.
That is to say it is UTF-16  encoding ... most characters fit in a  
16bit value, but a few take up more room and are represented as  
'surrogate pairs'.  However, the two halves of a surrogate pair are  
usually treated as separate characters.  They are certainly treated  
as such for purposes of determining a string length (which is the  
number of 16bit values in the string).