- Interesting indeed, if I export the pgn, "Franﾇa, Elcio" becomes "Franáa, Elcio" so I don't think this is correct either - If I copy "Franﾇa, Elcio" from the Save: Replace game window and paste it in the Header Search window, it won't find any game of him!? - I also found another "funny" name: "Franﾍois Andrﾎ Philidor", I know this player. The pgn will export as "François André Philidor" which is correct. - Using either Lucida Grande or Helvetica fonts doesn't change anything - if I correct "Francois" to "François" in the Save: Replace game window, it will appear correctly in the Game list. - Maybe something is wrong with the base but why should I see Katakana for special characters in the game list?
On 18 mars 09, at 13:54, Joost 't Hart wrote: > Hm, I was pretty careless, I see. > > 1) It is the 'c' (0x63) that is _replaced_ by the 'nou', and > 2) it is in the game list (and not related to spell checking..) > > Sorry for this. > > Still, the pgn export should be able to help you identify whether it > is a data or a font or a scid problem. > > G'luck once more, > Joost. > > >>> <zip> >>> >>>>> 2) In the game list, names with special characters appear with >>>>> Chinese >>>>> (or is it Japanese) characters. >>>>> >>>> I use Helvetica and as far as I could test, special characters >>>> appear as they should, could you be more specific about which >>>> special characters and which font are you using? >>>> >>> I use Lucida Grande for all fonts except for fixed fonts where I >>> use Monaco. >>> Franﾇa, Elcio is a name example. In case that the text doesn't >>> travel well, the character between "Fran" and "a" is funny. >>> >> >> The character that I see in your mail (let's try to be very >> precise) is the Katakana (Japanese, indeed) character NU (pronounce >> "nou" in french). >> >> ============== >> >> ヌ >> >> U+30CC KATAKANA LETTER NU >> >> General Character Properties >> >> In Unicode since: 1.1 >> Unicode category: Letter, Other >> >> Various Useful Representations >> >> UTF-8: 0xE3 0x83 0x8C >> UTF-16: 0x30CC >> >> C octal escaped UTF-8: \343\203\214 >> XML decimal entity: ヌ >> >> ============== >> >> You see this is a multi-byte character. Between the 'n' and the >> 'c', three bytes are inserted, together representing the NU. >> >> The player you talk about seems to be the one identified as follows >> in my ssp file: >> >> Brito, Elcio Eustaquio de Franca #- BRA [2064] 1952 >> = Franca, Elcio Eustaquio de B >> >> >> So actually we should not expect any character between the 'n' and >> the 'c'. Where does it come from? >> >> Let's try to find it. Where do you see this character? >> >> If it is in the old name, check your database. Search for games >> played by 'elcio'. If in the board window the name looks also >> broken, export that game to pgn and check the pgn file with a text >> (or even hex) editor. What do you see? >> >> If it is in the new name, check your ssp file in a text editor. >> What do you see? >> >> If neither of this reveals something, then it is not a data >> problem, and scid probably goes wrong. Otherwise either your >> database (I hope not!) or your ssp file has become corrupted. >> >> G'luck, >> Joost. >> >> > <zip> ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
