Re: How to convert a UTF-8 byte offset into an NSString character offset?
What's your next step after doing the UTF8 to UTF16 range conversion? If it's just going to be -[NSString substringWithRange:] then I'd strongly suggest just doing -[NSString initWithBytes:length:encoding:] on the UTF8 string. At least profile it and see what the penalty is. You've already paid the UTF16 to UTF8 conversion price once. It's not clear that going UTF8 to UTF16 again will be a big penalty vs. the range conversion. But profile would show. On Mon, May 5, 2014 at 2:06 PM, Jens Alfke wrote: > How can I map a byte offset in a UTF-8 string back to the corresponding > character offset in the NSString it came from? > > I’m writing an Objective-C wrapper around a C text-tokenizer API that > takes a UTF-8 string as input, and as part of its output returns byte > ranges of words that it found. So my API takes an NSString, converts it to > UTF-8, passes that to the C API, and then gets these byte offsets that it > needs to convert into character offsets in the NSString. > > I’ve looked through both the NSString and CFString APIs and didn’t see > anything relevant to this. I know UTF-8 isn’t rocket science and I could > pretty easily write my own function to scan through it counting characters, > but I suspect I’d run into the differences between Unicode characters and > the UTF-16 code points that NSString actually considers “characters”. I’d > much rather let CF do this for me in an internally-consistent way. > > —Jens > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > > https://lists.apple.com/mailman/options/cocoa-dev/stephen.butler%40gmail.com > > This email sent to stephen.but...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSBrowser tooltips
On May 5, 2014, at 4:58 PM, Paul Wasmund wrote: > I am using an NSBrowser to display items and my code is based on the > ComplexBrowser sample from Apple. This uses browser features introduced in > 10.6 and does not implement a NSMatrix to display columns. The only support I > see for implementing tooltips is > browser:shouldShowCellExpansionForRow:column: which does not allow for a > custom tooltip, only the display of the entire cell contents if the cell > contents doesn't fit in the column. Is there some way of implementing custom > tooltips for any cell in the browser? Well, it's not directly associated with cells, per se, but you can use -[NSView addToolTipRect:owner:userData:] to add a tooltip rect covering the whole browser view (and update it when its bounds change). Set the owner to an object which implements the NSToolTipOwner informal protocol – i.e. the -view:stringForToolTip:point:userData: method. In that method, you can translate from the point to a row and column and return an appropriate string. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSBrowser tooltips
I am using an NSBrowser to display items and my code is based on the ComplexBrowser sample from Apple. This uses browser features introduced in 10.6 and does not implement a NSMatrix to display columns. The only support I see for implementing tooltips is browser:shouldShowCellExpansionForRow:column: which does not allow for a custom tooltip, only the display of the entire cell contents if the cell contents doesn't fit in the column. Is there some way of implementing custom tooltips for any cell in the browser? Paul Wasmund ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to convert a UTF-8 byte offset into an NSString character offset?
On May 5, 2014, at 2:06 PM, Jens Alfke wrote: > How can I map a byte offset in a UTF-8 string back to the corresponding > character offset in the NSString it came from? > > I’m writing an Objective-C wrapper around a C text-tokenizer API that takes a > UTF-8 string as input, and as part of its output returns byte ranges of words > that it found. So my API takes an NSString, converts it to UTF-8, passes that > to the C API, and then gets these byte offsets that it needs to convert into > character offsets in the NSString. > > I’ve looked through both the NSString and CFString APIs and didn’t see > anything relevant to this. I know UTF-8 isn’t rocket science and I could > pretty easily write my own function to scan through it counting characters, > but I suspect I’d run into the differences between Unicode characters and the > UTF-16 code points that NSString actually considers “characters”. I’d much > rather let CF do this for me in an internally-consistent way. I ran into this same problem once, and I don't think there's any way to do it other than scanning through the string. The good news is that the documentation for CFStringGetLength does specifically say that the length returned is in terms of UTF-16 code pairs, so I don't think they can change that implementation detail without breaking the contract. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to convert a UTF-8 byte offset into an NSString character offset?
How can I map a byte offset in a UTF-8 string back to the corresponding character offset in the NSString it came from? I’m writing an Objective-C wrapper around a C text-tokenizer API that takes a UTF-8 string as input, and as part of its output returns byte ranges of words that it found. So my API takes an NSString, converts it to UTF-8, passes that to the C API, and then gets these byte offsets that it needs to convert into character offsets in the NSString. I’ve looked through both the NSString and CFString APIs and didn’t see anything relevant to this. I know UTF-8 isn’t rocket science and I could pretty easily write my own function to scan through it counting characters, but I suspect I’d run into the differences between Unicode characters and the UTF-16 code points that NSString actually considers “characters”. I’d much rather let CF do this for me in an internally-consistent way. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Differences in string handling for NSString and NSAttributedString
On 05 May 2014, at 18:50, Pax <45rpmli...@googlemail.com> wrote: > Oh bloody hell. I must be tired. That's so obvious - and I'm desperately > embarrassed for not taking care of this. Don't look in the archives, I've asked stupider questions :-) Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Differences in string handling for NSString and NSAttributedString
To add an example: Original\nString\nGoes\nHere ^8 ^15 ^20 ^25 Now I insert the first image, say just 1 character: Original\nAString\nGoes\nHere ^8 ^16 ^21 ^26 See how all the insertion offsets would have to change? But since you already have your list of insertion offsets, you'll insert in the wrong spot, and it'll just get worse and worse with each insertion, especially the longer it is. Backwards is not a problem: Original\nString\nGoes\nAHere ^8 ^15 ^20^26 Only the end changes on the first insertion, and on the second: Original\nString\nAGoes\nAHere ^8 ^15^21^27 Only the end and the (already-completed) last insertion location changes. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Differences in string handling for NSString and NSAttributedString
On 5/5/14, 6:27 PM, Pax wrote: I believe that this should cause "IMAGE HERE" to be inserted at specific line endings. However, it often inserts into the middle of a paragraph instead - usually, but not always, close to where it should put the text. Furthermore, the positioning is usually at, or very close, to the correct location for the first instance of image insertion - and it gets progressively less accurate as it gets through the text. Is there some difference between the ways that strings are handled in NSAttributedString and NSString? Could there be some problem with characters like Non-Breaking Space? You should probably reverse the order in which you insert strings/images/stuff. Whenever you insert something, the insert locations that follow this location calculated before inserting a new item will move backwards. A simple way to get around this is to reverse the insert order, starting at the last index and moving towards 0. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Differences in string handling for NSString and NSAttributedString
Oh bloody hell. I must be tired. That's so obvious - and I'm desperately
embarrassed for not taking care of this.
Thank you so much.
On 5 May 2014, at 17:47, Uli Kusterer wrote:
>
> On 05 May 2014, at 18:27, Pax <45rpmli...@googlemail.com> wrote:
>> When I use this with a plain string it appears to work correctly. I can use
>> it to chop up a string into constituent lines as follows (just a test -
>> clearly there are better ways of achieving the same result):
>>
>> NSArray* newLineArray = [StringTools getLocationsOfString:@"\n"
>> inString:[attributedRTFString string]];
>> int oldLoc = 0;
>> for (NSNumber* locNum in newLineArray) {
>> NSLog(@"%@",[[attributedRTFString string]
>> substringWithRange:NSMakeRange(oldLoc, [locNum intValue]-oldLoc)]);
>> oldLoc = [locNum intValue];
>> }
>
> This code just splits the string, but doesn't insert anything.
>
>> This proves, to my satisfaction at least, that the line endings are being
>> identified correctly and in the right place.
>>
>> When I try to use it with the attributed string, rather than the plain text
>> representation of the attributed string, it goes wrong. In the interests of
>> a quick test, I am trying to insert a string rather than an image.
>>
>> NSArray* newLineArray = [StringTools getLocationsOfString:@"\n"
>> inString:[attributedRTFString string]];
>> if (([imageLocations count]>0)&&([newLineArray count]>0)) {
>> for (NSDictionary* imageDetails in imageLocations) {
>> unsigned long loc = [[imageDetails objectForKey:@"image
>> location"]unsignedLongValue];
>> unsigned long locationForInsert = [[newLineArray
>> objectAtIndex:loc]unsignedLongValue];
>> NSAttributedString* testString = [[NSAttributedString
>> alloc]initWithString:@"IMAGE HERE" attributes:nil];
>> [attributedRTFString insertAttributedString:testString
>> atIndex:locationForInsert];
>> }
>> }
>>
>> I believe that this should cause "IMAGE HERE" to be inserted at specific
>> line endings. However, it often inserts into the middle of a paragraph
>> instead - usually, but not always, close to where it should put the text.
>> Furthermore, the positioning is usually at, or very close, to the correct
>> location for the first instance of image insertion - and it gets
>> progressively less accurate as it gets through the text. Is there some
>> difference between the ways that strings are handled in NSAttributedString
>> and NSString? Could there be some problem with characters like Non-Breaking
>> Space?
>
> This actually changes the string by inserting something. The result of the
> insertion is that everything following that string is moved down by the
> length of the inserted string. You need to either adjust the offsets (by
> remembering how many characters you've inserted so far) or avoid touching the
> stuff after the insertion by going backwards over the string.
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Differences in string handling for NSString and NSAttributedString
I have a an NSAttributedString into which I would like to insert images. The
images need to be inserted after specific line endings (I know which line
endings in advance - they've been previously calculated).
I have written a function which returns an array of all line ending locations
(or anything else that you'd care to search for) for a given string:
+(NSArray*)getLocationsOfString:(NSString*)stringToFind
inString:(NSString*)sourceString {
NSMutableArray* returnArray = [[NSMutableArray alloc]init];
@autoreleasepool
{
NSMutableString* sourceToSearch = [[NSMutableString
alloc]initWithString:sourceString];
unsigned long locationIterator=0;
while ([sourceToSearch
rangeOfString:stringToFind].location!=NSNotFound) {
unsigned long foundLocation = [sourceToSearch
rangeOfString:stringToFind].location+1;
[sourceToSearch deleteCharactersInRange:NSMakeRange(0,
foundLocation)];
[returnArray addObject:[NSNumber
numberWithUnsignedLong:foundLocation+locationIterator]];
locationIterator+=foundLocation;
}
}
return returnArray;
}
When I use this with a plain string it appears to work correctly. I can use it
to chop up a string into constituent lines as follows (just a test - clearly
there are better ways of achieving the same result):
NSArray* newLineArray = [StringTools getLocationsOfString:@"\n"
inString:[attributedRTFString string]];
int oldLoc = 0;
for (NSNumber* locNum in newLineArray) {
NSLog(@"%@",[[attributedRTFString string]
substringWithRange:NSMakeRange(oldLoc, [locNum intValue]-oldLoc)]);
oldLoc = [locNum intValue];
}
This proves, to my satisfaction at least, that the line endings are being
identified correctly and in the right place.
When I try to use it with the attributed string, rather than the plain text
representation of the attributed string, it goes wrong. In the interests of a
quick test, I am trying to insert a string rather than an image.
NSArray* newLineArray = [StringTools getLocationsOfString:@"\n"
inString:[attributedRTFString string]];
if (([imageLocations count]>0)&&([newLineArray count]>0)) {
for (NSDictionary* imageDetails in imageLocations) {
unsigned long loc = [[imageDetails objectForKey:@"image
location"]unsignedLongValue];
unsigned long locationForInsert = [[newLineArray
objectAtIndex:loc]unsignedLongValue];
NSAttributedString* testString = [[NSAttributedString
alloc]initWithString:@"IMAGE HERE" attributes:nil];
[attributedRTFString insertAttributedString:testString
atIndex:locationForInsert];
}
}
I believe that this should cause "IMAGE HERE" to be inserted at specific line
endings. However, it often inserts into the middle of a paragraph instead -
usually, but not always, close to where it should put the text. Furthermore,
the positioning is usually at, or very close, to the correct location for the
first instance of image insertion - and it gets progressively less accurate as
it gets through the text. Is there some difference between the ways that
strings are handled in NSAttributedString and NSString? Could there be some
problem with characters like Non-Breaking Space?
Hoping that someone can help!
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
