Re: stringWithFormat / Rendering Text (iOS)
Re: stringWithFormat / Rendering Text (iOS)
- Subject: Re: stringWithFormat / Rendering Text (iOS)
- From: James Montgomerie <email@hidden>
- Date: Thu, 24 May 2012 16:24:56 +0100
On 24 May 2012, at 15:36, Manfred Schwind wrote:
>> CGContextShowTextAtPoint(contextRef, 0, 40,
>> [textToDraw UTF8String], [textToDraw length]);
>
> One bug I see here: you're passing a wrong length parameter.
> CGContextShowTextAtPoint expects the length of the char array (number of bytes of the UTF-8 encoded string), but you'e passing the number of Unicode characters in the string. That's not the same; one character may be represented by multiple chars in UTF-8 encoding.
>
> E.g. use it this way:
>
> const char *myUTF8String = [textToDraw UTF8String];
> CGContextShowTextAtPoint(contextRef, 0, 40,
> myUTF8String, strlen(myUTF8String));
That's not true. CGContextShowText... routines expect the length to be in bytes, and the encoding to be what you specified in your CGContextSelectFont call. At the moment, you have a choice between the 8-bit MacRoman, and 'kCGEncodingMacRoman' and the cryptic 'kCGEncodingFontSpecific'. You should never pass UTF-8 text to a CGContextShowText... routine - if there's anything in there that isn't in the intersecting subset of ASCII and MacRoman, you're likely to just get garbled symbols out.
You can pass byte strings that you've converted to MacRoman, but MacRoman encoding represents quite a small subset of Unicode by modern standards - I would not recommend using it.
The CG levels don't do any sort of character to glyph mapping beyond this, so it's /impossible/ to display unicode text with them without parsing the fonts and doing the character to glyph mapping yourself (and then potentially worrying about font substitution if there are no glyphs to represent the characters you want etc...) then using the CGContextShowGlyphs... routines.
Really, just stick to UIKit string drawing, or CoreText if you want more control than that gives you. These frameworks might be more expensive than CoreGraphics in runtime terms, but that's because they're doing all the things that are necessary to render text well nowadays, not because they're inefficient.
Jamie.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden