Nice; I totally forgot about rangeOfComposedCharacterSequenceAtIndex.
If the user's encoding doesn't support the character he'll get a
warning at save time, right?
On Jan 13, 2008, at 5:29 PM, Christiaan Hofman wrote:
> Try my commit just now, I think that should fix this problem.
>
> Christiaan
>
> On 14 Jan 2008, at 1:55 AM, Adam R. Maxwell wrote:
>
>> We just got a bug report on the following author name:
>>
>> Čharœ̄nwong, Phisit and Diskul, Subhadradis
>>
>> which likely won't come through in the message. Anyway, there's a
>> dipthong oe with a combining macro over it. We convert that to
>> {\oe}x where x is the macron. When reading the file back in, it
>> appears to be a } with a macron over it, which is obviously wrong.
>>
>> At present, we just don't support characters that can't be
>> precomposed, and we don't have a graceful way of handling them.
>>
>> In copyStringByTeXifyingString I added another check
>>
>> if ([finalCharSet characterIsMember:ch] || [[NSCharacterSet
>> nonBaseCharacterSet] characterIsMember:ch]){
>>
>> tmpConv = [[NSMutableString alloc]
>> initWithCharactersNoCopy:&ch length:1 freeWhenDone:NO];
>>
>> // try the dictionary first
>> if((TEXString = [texifyConversions
>> objectForKey:tmpConv])){
>> [convertedSoFar replaceCharactersInRange:NSMakeRange
>> ((idx + offset), 1) withString:TEXString];
>> // we're adding length-1 characters, so we have to
>> make sure we insert at the right point in the future.
>> offset += [TEXString length] - 1;
>>
>> // fall back to Unicode decomposition/conversion of the
>> mutable string
>> } else if(convertComposedCharacterToTeX(tmpConv,
>> baseCharacterSetForTeX, accentCharSet, texifyAccents)){
>> [convertedSoFar replaceCharactersInRange:NSMakeRange
>> ((idx + offset), 1) withString:tmpConv];
>> // we're adding length-1 characters, so we have to
>> make sure we insert at the right point in the future.
>> offset += [tmpConv length] - 1;
>>
>> }
>> [tmpConv release];
>> }
>>
>> which causes an attempt to convert the macron alone, but that fails
>> since convertComposedCharacterToTeX() doesn't know what to do with
>> it and we don't have another else condition as a fallback.
>>
>> Personally I'm reasonably certain that this won't affect me, and
>> even if it does I'll fix it manually. Still, the fact remains that
>> we're writing stuff we can't read in, and that's bad. Any ideas?
>> I don't see an easy fix for this, and I don't want to rewrite
>> character conversion again.
>>
>>
>> --
>> adam
>>
>> <enc2.bib>
>> ----------------------------------------------------------------------
>> ---
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/
>> marketplace_______________________________________________
>> Bibdesk-develop mailing list
>> Bibdesk-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Bibdesk-develop mailing list
> Bibdesk-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
