At 10:42 AM +0800 9/29/05, [EMAIL PROTECTED] wrote:
Hmm, looks like one of our Teutonic friends has been using their crazy
non-standard extensions to the Latin alphabet again. ;-)
Put
# -*- coding: latin-1 -*-
in the top line and Python should be happy.
re Non-ASCI etc
Pardon my uncertainty here, but I was wondering at what level (OS
configuration, dependency configuration, GNUmed-proper configuration
etc) encoding must be specified and in what situations.
Is this type of issue considered a configuration issue rather than a
dependency?
Is it an issue that affects only program code and not data, and/or is
it any problem if data is at one stage stored in the backend under
one encoding scheme, and is later retrieved from a machine or its
software that have been (re)configured to a different encoding scheme?
I noticed during installation with an Etch testing disk --- which I
aborted/overwrote with Sarge... I was just making sure whether a
problem originated from a corrupted image --- that (is it) kernel
2.6x will offer support for UTF-8.
Will that solve any of the problems (recognizing that the answer
might apply only to OS/distros that support UTF-8) or would it be
co-dependent on the packages (wxPython, Python) also having to
support UTF-8 which they may not do?
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel