Thomas Zander <[EMAIL PROTECTED]> writes:
> > You can specify "en_US.UTF-8" as your locale. Which implies to me that
> > xterm can recognize, from its environment, the encoding, and act
> > accordingly.
>
> Hope you aren't using the locale standard 'Variation' variable for
> that; in most europe
Thomas Zander <[EMAIL PROTECTED]> writes:
> Not true; the locale is nothing more then a pointer to the i18n and l10n
> specific for that person using the computer.
> Naturally the l10n implies certain things like currency, date format etc.
> The nl_NL@EURO has a variant to change one aspect of the
"Mike A. Harris" <[EMAIL PROTECTED]> writes:
> >And, yes, of course xterm should start up in utf-8 mode if the locale
> >encoding is UTF-8.
>
> Thanks, that was my original conclusion also. I had just
> wondered why it doesn't. Just an xterm bug I guess.
Recent xterm versions do exactly that.
Thomas Zander <[EMAIL PROTECTED]> writes:
> I am wondering how xterm should handle different shells (using screen for
> example). The perfect-world-solution would be to ask the bash its env-var
> at every printf, but that may prove to not really be feasable..
xterm can be switched from and to utf
Paul Flinders <[EMAIL PROTECTED]> writes:
> I have a record of one patch from Gerd Knorr (then
> [EMAIL PROTECTED]) which was the "PPC port",
Still reading here :)
Merging this stuff into fsf gdb is fine with me.
Gerd
___
Dev
Hi,
The X-Server crashes with a segfault due to a NULL pointer dereference,
perfectly reproducable with a certain X client (mtt -- motif teletext
decoder). Stacktrace below. Setting Option "no_accel" workarounds
this. Hardware is a i386 machine with a Matrox G200. Anyone has a
quick idea wha
>I believe this can only happen if your font render is broken.
> These are fixed fonts. It should be impossible that there is no
> data in those pointers.
>
>Is this recent source code?
Yes. static server build from yesterdays cvsup.
> There have been bugs of this sort
> fixed in the
> > There have been bugs of this sort
> > fixed in the font renderers not long before 4.3. Though maybe
> > more exist. If this is easily reproducible I suspect you'll
> > find that it only happens with the freetype or xtt renders.
>
> It likely is the bitmap renderer, but I'll try without freet
On Fri, Mar 28, 2003 at 11:12:33AM +0100, Gerd Knorr wrote:
> > It likely is the bitmap renderer, but I'll try without freetype.
>
> Font data comes from the fontserver. More gdb debugging:
When I disable the font server and let XFree86 render the fonts instead
it works j
