En l'instant précis du 02/06/07 09:03, Mark Wedel s'exprimait en ces termes:
(OT: Did not post for a long time, hello to everyone) > #3 probably makes the most sense, and at least for the gtk2 client, looks > like > it would actually be handled properly (as the message generated on the wine > bottle is about invalid utf8 character). > > Also, I'm not sure how easy #2 is - it is easy from a person writing the > maps > or archetypes, but as demonstrated, pretty much all clients would have to do > special string handling. > Well, it's just a 256 entries table to convert those character to destination system. > #3 does make it harder for people putting the strings in (I'd think the map > editors could try to do the right thing in those cases and covert ISO 8859 15 > characters to unicode) > At least for java editor, it's not a problem. Java natively supports UTF-8 strings. On the onther hand, java does not support easily iso-8859-1 or iso-8859-15. Java supports UTF-8 and US-ASCII, the other encoding formats support is platform dependent. > So I'd vote unicode. I'd suspect that for clients that don't support utf8, > things won't really be any more broken than right now - the client would > display > a funky character instead of the correct one. But I don't believe that would > break any portion of the clients or protocol. > Here is how some special utf-8 characters looks like when drawn in iso-8859-1 utf-8 stored string: é - à - µ - ù - € iso-8859-1 read string: é - à - µ - ù - ⬠Nothing very critical i think... > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire