Re: Normalize an NSAttributedString
Re: Normalize an NSAttributedString
- Subject: Re: Normalize an NSAttributedString
- From: Michael Ash <email@hidden>
- Date: Wed, 26 Aug 2009 22:00:18 -0400
On Wed, Aug 26, 2009 at 2:59 PM, Ken Thomases<email@hidden> wrote:
> On Aug 26, 2009, at 1:45 PM, Michael Ash wrote:
>
>> On Wed, Aug 26, 2009 at 1:21 PM, Ken Thomases<email@hidden> wrote:
>>>
>>> I'm well aware of what it means. The question is, which exact operations
>>> on
>>> the mutable string proxy does CFStringNormalize perform. If
>>> CFStringNormalize performs the minimal replace operations to get the
>>> result,
>>> then it will preserve the attributes closely. It's conceivable, though,
>>> that CFStringNormalize uses a side buffer to compute the normalized form
>>> and
>>> then does one big replace of the whole mutable string's range. Or,
>>> anywhere
>>> in between. Like, it might replace a series of precomposed characters
>>> with
>>> their decompositions all with one replace operation. In that case, the
>>> attributes of most of the characters will be lost (replaced with the
>>> attributes of the first character in the replace range).
>>>
>>> So, it's clear that the _strings_ will always have a deterministic value
>>> as
>>> a result of normalization. That's the point of normalization. But the
>>> _attributed strings_ may not.
>>
>> Fair enough. However, as Douglas pointed out, you aren't guaranteed
>> consistent results if you have multiple attributes within a single
>> decomposed character range *anyway*, so you're going to have trouble
>> regardless. Better to avoid that situation altogether.
>
> My point about this lossiness has nothing to do with multiple attributes
> within a single grapheme. The attributes for the entire string may get
> munged.
Finally got it through my thick head. Sorry about that. You are
correct as far as I can see; nothing in the API contract says that it
couldn't just delete the whole string and start anew. This would be
inefficient, and it wouldn't make sense for this to be a
CFMutableString API if that's all it does, but it *could*. The
implementation in CFLite does not do this, but that implementation is
only for NSCFStrings. I don't think the implementation used for custom
NSMutableString subclasses is public, and of course even if it were
there's no guarantee it wouldn't change.
Perhaps the best bet would be to borrow the CFLite implementation,
fixed up to work on an external string, and then you know what the
implementation is and that it does what you need.
Mike
_______________________________________________
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