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.) 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? 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. -Ken
