On Aug 21, 2013, at 10:11 AM, Ken Thomases wrote: > On Aug 21, 2013, at 10:12 AM, Ken Thomases wrote: > >> On Aug 20, 2013, at 10:49 PM, Charles Davis wrote: >> >>> In the Windows world, "Unicode" almost universally means "UTF-16". So, >>> use the well-known UTF-16 type instead of making up our own. >>> >>> I have to wonder if there was a good reason Ken didn't use this >>> initially. >> >> Please hold this patch while I review it. >> >> I think there is a good reason why I didn't use it, but I have to figure it >> out again. :-/ >> >> It has to do with a promised pasteboard type (what Microsoft calls delayed >> rendering) and the conversions to the other text types. I think we need to >> use a custom type to distinguish between being asked for promised data vs. >> being asked for a conversion. > > Well, that wasn't the reason. However, I've found a simpler reason not to > commit this. The data supplied for CF_UNICODETEXT is null-terminated, but > public.utf16-plain-text shouldn't be. (Neither CFString nor NSString treat a > 0x0000 code unit specially. It just ends up part of the string.) Wow, I didn't know that. I guess that makes sense, because NSCFStrings are counted. > > Was there a specific compatibility problem you were trying to solve? Or just > reviewing the code and found this strange and wanted to improve it? I was looking over the patches as you sent them, found this strange, and thought this would improve it. > > If you like, it may make sense to add conversions to public.utf16-plain-text > like those done for public.utf8-plain-text, but the import/export functions > will have to add/remove the terminating null. Sounds good. But it might take me a little while to rework this. I have a bunch of other things going on at the moment. I'll probably miss today's commit wave, but not tomorrow's.
Chip
