idokan at gmail.com
Sun Nov 5 10:50:30 CET 2006
On 11/5/06, Tomas Hajny <XHajT03 at mbox.vol.cz> wrote:
> On 3 Nov 06, at 20:32, ik wrote:
> > On 11/3/06, Tomas Hajny <XHajT03 at mbox.vol.cz> wrote:
> > > ik wrote:
> > > > On 11/3/06, Micha Nelissen <micha at neli.hopto.org> wrote:
> > > >> Tomas Hajny wrote:
> > > >> > Does anybody here have an idea how to address that issue in Unix/Linux
> > > >> > environment (like an environment variable similar to TERM, etc.)? I
> > > >> can
> > > >>
> > > >> The part after the dot in $LANG. It's possible though that there is no
> > > >> dot, no idea what to do, maybe assume iso-8859-1 ?
> > > >
> > > > No, that will be really bad idea to assume iso-8859-1 . It really
> > > > depends on the country and language code. For example :
> > > >
> > > > LANG=he_IL.UTF-8
> > > .
> > > .
> > > > If I'll remove the UTF-8 it will be he_IL regardless... but the
> > > > encoding will be iso8859-8 ... If you will place iso8859-1, it will
> > > > stop working .. I mean you could not use the language your system is
> > > > set to.
> > > >
> > > > Any language out there that does not use iso8859-1 will suffer from that
> > > > ...
> > >
> > > We were discussing the default behaviour used if no information about
> > > encoding is available. This only means that those who cannot use the
> > > default (ISO 8859-1) have to make sure to provide the real information,
> > > otherwise it just isn't guaranteed to work correctly. I don't think this
> > > should be a problem, but I'm open to your arguments if you think
> > > otherwise.
> > >
> > > BTW, note that one can always set environment variable even just for a
> > > particular session (e.g. in a shell script starting the particular
> > > binary), so even if it isn't possible to change the default for some
> > > reason (e.g. due to other programs running on the same machine under the
> > > same user), it should be still useable (responding to Marco's comment
> > > about old machines here).
> > The problem is that we do not know if there is some sort of font
> > loaded or not. For example, in my Ubuntu, because in the installation
> > I set up "Hebrew", it configured by default a font for the VT called
> > iso8. But when I'm using X, this fonts does not work for terminals, so
> > I can use terminals such as konsole, mlterm or xterm-unicode (I think
> > some others as well) to display Hebrew characters (don't talk about
> > bi-directional support... that's just too much :)).
> > On my Konsole (kde's terminal), it's the font and a checkbox (inside
> > the program) that tells it to use Hebrew, rather then the locale.
> > That's for example, the way I'm able to translate the Hebrew version
> > of FPC to cp1255 (Windows Hebrew) while I am at UTF-8 charset. I think
> > it is up to the user to set the locale, and if there is no locale,
> > then ASCII is our locale, rather then latin1.
> Well, either ASCII or latin1, the end result is
> the same for you (i.e. Hebrew and other
> characters not working there), isn't it?
First of all it easier to detect ASCII only then latin1/2 etc ...
Because there are only 127 possible chars (well less because you can
see from 32-127), while in latin1, you will see higher values, but it
will take time to understand why you see the *wrong* chars rather then
the correct ones. At least for :)
More information about the fpc-devel