Re: What happened to the fonts?
Marc Aurele La France wrote: OK. This makes some sense to me. But should something like this be done to all affected locates? Yes. The same problem exists for all other locales (at least for 'iso8859 like' one-byte encodings). I made changes for all such locales and commited them. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
On Wed, 2 Feb 2005, Ivan Pascal wrote: Marc Aurele La France wrote: OK. This makes some sense to me. But should something like this be done to all affected locates? Yes. The same problem exists for all other locales (at least for 'iso8859 like' one-byte encodings). I made changes for all such locales and commited them. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
Marc Aurele La France wrote:
I don't know enough about this stuff to answer. Perhaps someone else will,
and deal with http://www.mail-archive.com/devel%40xfree86.org/msg06114.html.
In the meantime I've backed out the change that's causing this.
I investigated this issue.
In one of next messages Barry Scott mentioned
I recall I was seeing code behind XutfTextExtents fail to
return any info without the patch - I think it was Xutf8TextExtents.
Therefore I guess he has problem with Xutf8* ouput functions in non-UTF8
locale. And it is a real issue. These functions don't work without changes
he proposed. But after such changes Xmb* output functions don't work.
Obviously, there is some difference in the interpretation of XLC_LOCALE data
between these two families (Xutf8* and Xmb*).
The traditional iso2022 based font system requires that any input string
be separated into portions where all chars belong to one charset.
Corresponded converters cut out such portions from a text, label them with
charset name and pass to the next procedure that finds an appropriate font
for this portion drawing.
XLC_LOCALE file contains 'codeset' and 'fontset' records. The 'codeset' records
describe rules for distinguishing chars of different charsets and chaset names
suitable for each type of chars. The 'fontset' records just defines pairs
'charset name' - 'font encoding name' that tell what font should be used
for each charset (the string labeled with this chaset name).
What we see in iso8859-15 locale file (and in many other one-byte encoding
locales)?
There are two codeset records
cs0 { sideGL:Default
..
ct_encoding ISO8859-15:GL; ISO8859-1:GL }
cs1 { sideGR:Default
..
ct_encoding ISO8859-15:GR }
and two fontset records
fs0 { charset { nameISO8859-1:GL }
font{ primary ISO8859-15:GL
} }
fs1 { charset { nameISO8859-15:GR }
font{ primary ISO8859-15:GR } }
The second records in both pairs is the simplest case. The codeset record says
that all 'right side' chars (codes 127) belongs to the right side of
ISO8859-15 charset and the fontset record says that the text portion labeled
with 'right side of ISO8859-15 charset' can be drawn with some ISO8859-15
encoded font.
The first fontset record is simple too. It says that 'ISO8859-1 left side'
labeled string can be writen with ISO8859-15 encoded font.
But the first codeset record is more complex. It contains two charset names
for the same kind of chars ('left side', i.e. codes 128). And Xutf8* and
Xmb* functions use different names from this pair. (I know why, and can
explain. But here I omit those details.)
Thus if one wants to output simple ASCII string like 'abcd', the 'mb' converter
labels it as 'ISO8859-1: GL' whereas the 'utf8' converter labels it as
'ISO8859-15:GL'.
And if the fontset record looks like 'charset: ISO8859-1 - font: ISO8859-15'
the second step procedure successfuly finds appropriate font for 'mb' converter
output string but can do nothing for 'utf8' converter output. And after Barry's
changes we got a reverse situation: the first fontset record became
'charset: ISO8859-15 - font: ISO8859-15' that means that 'utf8' converter
output has appropriate font but there is nothing useful for the 'mb' converter
results.
The worst thing is that there is significant difference in these converters
internals and if even we force the 'utf8' converter to choose ISO8859-1
charset we will not get the the behavior similar to 'mb' converters one.
In this case the 'utf8' converter makes the 'right side' chars labeled with
ISO8859-1:GR (execept the Euro sign). But such name also has not appropriate
chaset-font pair among fontset records.
I would suggest a simple workaround: instead of changing the first fontset
record add a similar one but with another charset name. I.e. the fontset
section of XLC_LOCALE will look like:
fs0 { charset { nameISO8859-1:GL }
font{ primary ISO8859-15:GL }}
fs1 { charset { nameISO8859-15:GR }
font{ primary ISO8859-15:GR }}
fs2 { charset { nameISO8859-15:GL }
font{ primary ISO8859-15:GL }}
In such case the first record would satisfy Xmb* functions and the third record
would make Xutf8* functions happy.
(Of course, I tested this solution. It works.)
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
On Tue, 1 Feb 2005, Ivan Pascal wrote:
Marc Aurele La France wrote:
I don't know enough about this stuff to answer. Perhaps someone else will,
and deal with http://www.mail-archive.com/devel%40xfree86.org/msg06114.html.
In the meantime I've backed out the change that's causing this.
I investigated this issue.
In one of next messages Barry Scott mentioned
I recall I was seeing code behind XutfTextExtents fail to
return any info without the patch - I think it was Xutf8TextExtents.
Therefore I guess he has problem with Xutf8* ouput functions in non-UTF8
locale. And it is a real issue. These functions don't work without changes
he proposed. But after such changes Xmb* output functions don't work.
Obviously, there is some difference in the interpretation of XLC_LOCALE data
between these two families (Xutf8* and Xmb*).
The traditional iso2022 based font system requires that any input string
be separated into portions where all chars belong to one charset.
Corresponded converters cut out such portions from a text, label them with
charset name and pass to the next procedure that finds an appropriate font
for this portion drawing.
XLC_LOCALE file contains 'codeset' and 'fontset' records. The 'codeset' records
describe rules for distinguishing chars of different charsets and chaset names
suitable for each type of chars. The 'fontset' records just defines pairs
'charset name' - 'font encoding name' that tell what font should be used
for each charset (the string labeled with this chaset name).
What we see in iso8859-15 locale file (and in many other one-byte encoding
locales)?
There are two codeset records
cs0 { sideGL:Default
..
ct_encoding ISO8859-15:GL; ISO8859-1:GL }
cs1 { sideGR:Default
..
ct_encoding ISO8859-15:GR }
and two fontset records
fs0 { charset { nameISO8859-1:GL }
font{ primary ISO8859-15:GL
} }
fs1 { charset { nameISO8859-15:GR }
font{ primary ISO8859-15:GR } }
The second records in both pairs is the simplest case. The codeset record says
that all 'right side' chars (codes 127) belongs to the right side of
ISO8859-15 charset and the fontset record says that the text portion labeled
with 'right side of ISO8859-15 charset' can be drawn with some ISO8859-15
encoded font.
The first fontset record is simple too. It says that 'ISO8859-1 left side'
labeled string can be writen with ISO8859-15 encoded font.
But the first codeset record is more complex. It contains two charset names
for the same kind of chars ('left side', i.e. codes 128). And Xutf8* and
Xmb* functions use different names from this pair. (I know why, and can
explain. But here I omit those details.)
Thus if one wants to output simple ASCII string like 'abcd', the 'mb' converter
labels it as 'ISO8859-1: GL' whereas the 'utf8' converter labels it as
'ISO8859-15:GL'.
And if the fontset record looks like 'charset: ISO8859-1 - font: ISO8859-15'
the second step procedure successfuly finds appropriate font for 'mb' converter
output string but can do nothing for 'utf8' converter output. And after Barry's
changes we got a reverse situation: the first fontset record became
'charset: ISO8859-15 - font: ISO8859-15' that means that 'utf8' converter
output has appropriate font but there is nothing useful for the 'mb' converter
results.
The worst thing is that there is significant difference in these converters
internals and if even we force the 'utf8' converter to choose ISO8859-1
charset we will not get the the behavior similar to 'mb' converters one.
In this case the 'utf8' converter makes the 'right side' chars labeled with
ISO8859-1:GR (execept the Euro sign). But such name also has not appropriate
chaset-font pair among fontset records.
I would suggest a simple workaround: instead of changing the first fontset
record add a similar one but with another charset name. I.e. the fontset
section of XLC_LOCALE will look like:
fs0 { charset { nameISO8859-1:GL }
font{ primary ISO8859-15:GL }}
fs1 { charset { nameISO8859-15:GR }
font{ primary ISO8859-15:GR }}
fs2 { charset { nameISO8859-15:GL }
font{ primary ISO8859-15:GL }}
In such case the first record would satisfy Xmb* functions and the third record
would make Xutf8* functions happy.
(Of course, I tested this solution. It works.)
OK. This makes some sense to me. But should something like this be done to
all affected locates?
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta
Re: What happened to the fonts?
On Tue, 1 Feb 2005, Marc Aurele La France wrote:
On Tue, 1 Feb 2005, Ivan Pascal wrote:
Marc Aurele La France wrote:
I don't know enough about this stuff to answer. Perhaps someone else
will,
and deal with
http://www.mail-archive.com/devel%40xfree86.org/msg06114.html.
In the meantime I've backed out the change that's causing this.
I investigated this issue.
In one of next messages Barry Scott mentioned
I recall I was seeing code behind XutfTextExtents fail to
return any info without the patch - I think it was Xutf8TextExtents.
Therefore I guess he has problem with Xutf8* ouput functions in non-UTF8
locale. And it is a real issue. These functions don't work without
changes
he proposed. But after such changes Xmb* output functions don't work.
Obviously, there is some difference in the interpretation of XLC_LOCALE
data
between these two families (Xutf8* and Xmb*).
The traditional iso2022 based font system requires that any input string
be separated into portions where all chars belong to one charset.
Corresponded converters cut out such portions from a text, label them with
charset name and pass to the next procedure that finds an appropriate font
for this portion drawing.
XLC_LOCALE file contains 'codeset' and 'fontset' records. The 'codeset'
records
describe rules for distinguishing chars of different charsets and chaset
names
suitable for each type of chars. The 'fontset' records just defines pairs
'charset name' - 'font encoding name' that tell what font should be used
for each charset (the string labeled with this chaset name).
What we see in iso8859-15 locale file (and in many other one-byte encoding
locales)?
There are two codeset records
cs0 { sideGL:Default
..
ct_encoding ISO8859-15:GL; ISO8859-1:GL }
cs1 { sideGR:Default
..
ct_encoding ISO8859-15:GR }
and two fontset records
fs0 { charset { nameISO8859-1:GL }
font{ primary ISO8859-15:GL
fs1 { charset { nameISO8859-15:GR }
font{ primary ISO8859-15:GR } }
The second records in both pairs is the simplest case. The codeset record
says
that all 'right side' chars (codes 127) belongs to the right side of
ISO8859-15 charset and the fontset record says that the text portion
labeled
with 'right side of ISO8859-15 charset' can be drawn with some ISO8859-15
encoded font.
The first fontset record is simple too. It says that 'ISO8859-1 left side'
labeled string can be writen with ISO8859-15 encoded font.
But the first codeset record is more complex. It contains two charset
names
for the same kind of chars ('left side', i.e. codes 128). And Xutf8* and
Xmb* functions use different names from this pair. (I know why, and can
explain. But here I omit those details.)
Thus if one wants to output simple ASCII string like 'abcd', the 'mb'
converter
labels it as 'ISO8859-1: GL' whereas the 'utf8' converter labels it as
'ISO8859-15:GL'.
And if the fontset record looks like 'charset: ISO8859-1 - font:
ISO8859-15'
the second step procedure successfuly finds appropriate font for 'mb'
converter
output string but can do nothing for 'utf8' converter output. And after
Barry's
changes we got a reverse situation: the first fontset record became
'charset: ISO8859-15 - font: ISO8859-15' that means that 'utf8' converter
output has appropriate font but there is nothing useful for the 'mb'
converter
results.
The worst thing is that there is significant difference in these converters
internals and if even we force the 'utf8' converter to choose ISO8859-1
charset we will not get the the behavior similar to 'mb' converters one.
In this case the 'utf8' converter makes the 'right side' chars labeled with
ISO8859-1:GR (execept the Euro sign). But such name also has not
appropriate
chaset-font pair among fontset records.
I would suggest a simple workaround: instead of changing the first fontset
record add a similar one but with another charset name. I.e. the fontset
section of XLC_LOCALE will look like:
fs0 { charset { nameISO8859-1:GL }
font{ primary ISO8859-15:GL }}
fs1 { charset { nameISO8859-15:GR }
font{ primary ISO8859-15:GR }}
fs2 { charset { nameISO8859-15:GL }
font{ primary ISO8859-15:GL }}
In such case the first record would satisfy Xmb* functions and the third
record
would make Xutf8* functions happy.
(Of course, I tested this solution. It works.)
OK. This makes some sense to me. But should something like this be done to
all affected locates?
I meant locales, not locates.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
Re: What happened to the fonts?
On Fri, 28 Jan 2005, Marc Aurele La France wrote:
On Fri, 28 Jan 2005, Mark Vojkovich wrote:
I tried tracing twm when it is drawing fonts. I don't really
understand the font paths very well, but it looks like it never
even draws anything. It looks like:
_XomGetFontSetFromCharSet returns NULL so
_XomConvert returns -1 so
_XomGenericDrawString doesn't draw anything
I walked through the loop in _XomGetFontSetFromCharSet.
There are two fontsets (ie. font_set_num = 2). Both have only
one charset. Neither matches the one passed to _XomGetFontSetFromCharSet.
(gdb) p font_set[0]
$62 = {id = 0, charset_count = 1, charset_list = 0x80910d8,
font_data_count = 1, font_data = 0x80916b0,
font_name = 0x8091ea0
-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso88
59-15, info = 0x0, font = 0x80919c0, side = XlcGL, is_xchar2b = 0,
substitute_num = 1, substitute = 0x80916d0, vpart_initialize = 0,
vmap_num = 0, vmap = 0x80916f0, vrotate_num = 1, vrotate = 0x8091700}
(gdb) p font_set[1]
$63 = {id = 1, charset_count = 1, charset_list = 0x80910a8,
font_data_count = 1, font_data = 0x8091720,
font_name = 0x8091edd
-adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso88
59-15, info = 0x0, font = 0x8091c30, side = XlcGR, is_xchar2b = 0,
substitute_num = 0, substitute = 0x8091740, vpart_initialize = 0,
vmap_num = 0, vmap = 0x8091750, vrotate_num = 0, vrotate = 0x0}
(gdb) p *font_set[0].charset_list
$72 = 0x8084848
(gdb) p *font_set[1].charset_list
$73 = 0x8082698
(gdb) p charset
$64 = 0x8081e80
(gdb) p *charset
$65 = {name = 0x807f238 ISO8859-1:GL, xrm_name = 1,
encoding_name = 0x807f108 ISO8859-1, xrm_encoding_name = 2, side = XlcGL,
char_size = 1, set_size = 94, ct_sequence = 0x807f245 \e(B,
string_encoding = 1, udc_area = 0x0, udc_area_num = 0, source = CSsrcStd}
(gdb)
I'm not really sure what to do with this information.
Ummm. See if changing line 19 of
/usr/X11R6/lib/X11/locale/iso8859-15/XLC_LOCALE to read ...
nameISO8859-1:GL
... instead of ...
nameISO8859-15:GL
... fixes the problem. Be mindful of tabs.
Yes it does. Twm has fonts again. So does fvwm2. Is the
locale file broken or something else that's making a bad assumption?
Mark.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
On Sat, 29 Jan 2005, Mark Vojkovich wrote:
On Fri, 28 Jan 2005, Marc Aurele La France wrote:
On Fri, 28 Jan 2005, Mark Vojkovich wrote:
I tried tracing twm when it is drawing fonts. I don't really
understand the font paths very well, but it looks like it never
even draws anything. It looks like:
_XomGetFontSetFromCharSet returns NULL so
_XomConvert returns -1 so
_XomGenericDrawString doesn't draw anything
I walked through the loop in _XomGetFontSetFromCharSet.
There are two fontsets (ie. font_set_num = 2). Both have only
one charset. Neither matches the one passed to _XomGetFontSetFromCharSet.
(gdb) p font_set[0]
$62 = {id = 0, charset_count = 1, charset_list = 0x80910d8,
font_data_count = 1, font_data = 0x80916b0,
font_name = 0x8091ea0 -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso88
59-15, info = 0x0, font = 0x80919c0, side = XlcGL, is_xchar2b = 0,
substitute_num = 1, substitute = 0x80916d0, vpart_initialize = 0,
vmap_num = 0, vmap = 0x80916f0, vrotate_num = 1, vrotate = 0x8091700}
(gdb) p font_set[1]
$63 = {id = 1, charset_count = 1, charset_list = 0x80910a8,
font_data_count = 1, font_data = 0x8091720,
font_name = 0x8091edd -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso88
59-15, info = 0x0, font = 0x8091c30, side = XlcGR, is_xchar2b = 0,
substitute_num = 0, substitute = 0x8091740, vpart_initialize = 0,
vmap_num = 0, vmap = 0x8091750, vrotate_num = 0, vrotate = 0x0}
(gdb) p *font_set[0].charset_list
$72 = 0x8084848
(gdb) p *font_set[1].charset_list
$73 = 0x8082698
(gdb) p charset
$64 = 0x8081e80
(gdb) p *charset
$65 = {name = 0x807f238 ISO8859-1:GL, xrm_name = 1,
encoding_name = 0x807f108 ISO8859-1, xrm_encoding_name = 2, side = XlcGL,
char_size = 1, set_size = 94, ct_sequence = 0x807f245 \e(B,
string_encoding = 1, udc_area = 0x0, udc_area_num = 0, source = CSsrcStd}
(gdb)
I'm not really sure what to do with this information.
Ummm. See if changing line 19 of
/usr/X11R6/lib/X11/locale/iso8859-15/XLC_LOCALE to read ...
name ISO8859-1:GL
... instead of ...
name ISO8859-15:GL
... fixes the problem. Be mindful of tabs.
Yes it does. Twm has fonts again. So does fvwm2. Is the
locale file broken or something else that's making a bad assumption?
I don't know enough about this stuff to answer. Perhaps someone else will,
and deal with http://www.mail-archive.com/devel%40xfree86.org/msg06114.html.
In the meantime I've backed out the change that's causing this.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
I tried tracing twm when it is drawing fonts. I don't really
understand the font paths very well, but it looks like it never
even draws anything. It looks like:
_XomGetFontSetFromCharSet returns NULL so
_XomConvert returns -1 so
_XomGenericDrawString doesn't draw anything
I walked through the loop in _XomGetFontSetFromCharSet.
There are two fontsets (ie. font_set_num = 2). Both have only
one charset. Neither matches the one passed to _XomGetFontSetFromCharSet.
(gdb) p font_set[0]
$62 = {id = 0, charset_count = 1, charset_list = 0x80910d8,
font_data_count = 1, font_data = 0x80916b0,
font_name = 0x8091ea0 -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso88
59-15, info = 0x0, font = 0x80919c0, side = XlcGL, is_xchar2b = 0,
substitute_num = 1, substitute = 0x80916d0, vpart_initialize = 0,
vmap_num = 0, vmap = 0x80916f0, vrotate_num = 1, vrotate = 0x8091700}
(gdb) p font_set[1]
$63 = {id = 1, charset_count = 1, charset_list = 0x80910a8,
font_data_count = 1, font_data = 0x8091720,
font_name = 0x8091edd -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso88
59-15, info = 0x0, font = 0x8091c30, side = XlcGR, is_xchar2b = 0,
substitute_num = 0, substitute = 0x8091740, vpart_initialize = 0,
vmap_num = 0, vmap = 0x8091750, vrotate_num = 0, vrotate = 0x0}
(gdb) p *font_set[0].charset_list
$72 = 0x8084848
(gdb) p *font_set[1].charset_list
$73 = 0x8082698
(gdb) p charset
$64 = 0x8081e80
(gdb) p *charset
$65 = {name = 0x807f238 ISO8859-1:GL, xrm_name = 1,
encoding_name = 0x807f108 ISO8859-1, xrm_encoding_name = 2, side = XlcGL,
char_size = 1, set_size = 94, ct_sequence = 0x807f245 \e(B,
string_encoding = 1, udc_area = 0x0, udc_area_num = 0, source = CSsrcStd}
(gdb)
I'm not really sure what to do with this information.
Mark.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
On Fri, 28 Jan 2005, Mark Vojkovich wrote:
I tried tracing twm when it is drawing fonts. I don't really
understand the font paths very well, but it looks like it never
even draws anything. It looks like:
_XomGetFontSetFromCharSet returns NULL so
_XomConvert returns -1 so
_XomGenericDrawString doesn't draw anything
I walked through the loop in _XomGetFontSetFromCharSet.
There are two fontsets (ie. font_set_num = 2). Both have only
one charset. Neither matches the one passed to _XomGetFontSetFromCharSet.
(gdb) p font_set[0]
$62 = {id = 0, charset_count = 1, charset_list = 0x80910d8,
font_data_count = 1, font_data = 0x80916b0,
font_name = 0x8091ea0 -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso88
59-15, info = 0x0, font = 0x80919c0, side = XlcGL, is_xchar2b = 0,
substitute_num = 1, substitute = 0x80916d0, vpart_initialize = 0,
vmap_num = 0, vmap = 0x80916f0, vrotate_num = 1, vrotate = 0x8091700}
(gdb) p font_set[1]
$63 = {id = 1, charset_count = 1, charset_list = 0x80910a8,
font_data_count = 1, font_data = 0x8091720,
font_name = 0x8091edd -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso88
59-15, info = 0x0, font = 0x8091c30, side = XlcGR, is_xchar2b = 0,
substitute_num = 0, substitute = 0x8091740, vpart_initialize = 0,
vmap_num = 0, vmap = 0x8091750, vrotate_num = 0, vrotate = 0x0}
(gdb) p *font_set[0].charset_list
$72 = 0x8084848
(gdb) p *font_set[1].charset_list
$73 = 0x8082698
(gdb) p charset
$64 = 0x8081e80
(gdb) p *charset
$65 = {name = 0x807f238 ISO8859-1:GL, xrm_name = 1,
encoding_name = 0x807f108 ISO8859-1, xrm_encoding_name = 2, side = XlcGL,
char_size = 1, set_size = 94, ct_sequence = 0x807f245 \e(B,
string_encoding = 1, udc_area = 0x0, udc_area_num = 0, source = CSsrcStd}
(gdb)
I'm not really sure what to do with this information.
Ummm. See if changing line 19 of
/usr/X11R6/lib/X11/locale/iso8859-15/XLC_LOCALE to read ...
nameISO8859-1:GL
... instead of ...
nameISO8859-15:GL
... fixes the problem. Be mindful of tabs.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
Marc Aurele La France wrote: On Tue, 25 Jan 2005, Marc Aurele La France wrote: > On Thu, 20 Jan 2005, Mark Vojkovich wrote: >> On Thu, 20 Jan 2005, Marc Aurele La France wrote: >>> On Thu, 20 Jan 2005, Bukie Mabayoje wrote: Mark Vojkovich wrote: > I synced up and built and now, though the server starts fine, > apps can't get any fonts. Window managers claim they can't find > fontsets like fixed so menus and such have no text in them. > xfontsel seems to work though. Anyone know what's going on? > It's like the fonts.alias isn't being read anymore. I can > see fixed in the fonts.alias and I can see the corresponding > font in the fonts.dir and I can see that the font file exists > and can verify that the server acknowledged that font path. I am looking into a similar problem too, when xfs is not running. >>> I've been able to make the fontset message appear with a simple test case >>> (holding down the control key and pressing any mouse button while the >>> pointer >>> is in an xterm). >> I don't see that message with xterm. TWM menus don't work though. >> But, if I run TWM remotely from another machine it works. I think >> that implies that it's a problem with the local libraries. Another >> data point, is a test app that opens "fixed" seems to work fine, so >> it's not the case that aliases are broken in general - just in some >> cases. >> Bukie, how long have you been seeing this problem? I updated >> yesterday and saw it for the first time. The last time I updated >> was Nov 26. so that gives a pretty large window. It was reported in the xfree86 by someone else earlier this month. And I was able to reproduce it using their Linux distribution. I can't test it in red hat because Red hat always start xfs when running X. So I am currently trying to debug it using debian. The fact is X should run without xfs running. > Mark (and anyone else, of course), > Please tell me whether the attached patch fixes (your version of) the > problem. Umm. That's not right. Further investigation shows the xterm behaviour I was seeing was due to an NLS configuration error. Also, the TWM menus I see look as expected. Can you narrow down this problem a bit more? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax: 1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel Sorry, I my mail system crashed and I lost some mail. That is why I didn't respond to your message.
Re: What happened to the fonts?
On Tue, 25 Jan 2005, Marc Aurele La France wrote: Mark (and anyone else, of course), Please tell me whether the attached patch fixes (your version of) the problem. No, it does not. Mark. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
On Thu, 20 Jan 2005, Mark Vojkovich wrote: On Thu, 20 Jan 2005, Marc Aurele La France wrote: On Thu, 20 Jan 2005, Bukie Mabayoje wrote: Mark Vojkovich wrote: I synced up and built and now, though the server starts fine, apps can't get any fonts. Window managers claim they can't find fontsets like fixed so menus and such have no text in them. xfontsel seems to work though. Anyone know what's going on? It's like the fonts.alias isn't being read anymore. I can see fixed in the fonts.alias and I can see the corresponding font in the fonts.dir and I can see that the font file exists and can verify that the server acknowledged that font path. I am looking into a similar problem too, when xfs is not running. I've been able to make the fontset message appear with a simple test case (holding down the control key and pressing any mouse button while the pointer is in an xterm). I don't see that message with xterm. TWM menus don't work though. But, if I run TWM remotely from another machine it works. I think that implies that it's a problem with the local libraries. Another data point, is a test app that opens fixed seems to work fine, so it's not the case that aliases are broken in general - just in some cases. Bukie, how long have you been seeing this problem? I updated yesterday and saw it for the first time. The last time I updated was Nov 26. so that gives a pretty large window. Mark (and anyone else, of course), Please tell me whether the attached patch fixes (your version of) the problem. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. Mark.diff.gz Description: Binary data
Re: What happened to the fonts?
I am looking into a similar problem too, when xfs is not running. Mark Vojkovich wrote: I synced up and built and now, though the server starts fine, apps can't get any fonts. Window managers claim they can't find fontsets like fixed so menus and such have no text in them. xfontsel seems to work though. Anyone know what's going on? It's like the fonts.alias isn't being read anymore. I can see fixed in the fonts.alias and I can see the corresponding font in the fonts.dir and I can see that the font file exists and can verify that the server acknowledged that font path. Mark. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
On Thu, 20 Jan 2005, Bukie Mabayoje wrote: Mark Vojkovich wrote: I synced up and built and now, though the server starts fine, apps can't get any fonts. Window managers claim they can't find fontsets like fixed so menus and such have no text in them. xfontsel seems to work though. Anyone know what's going on? It's like the fonts.alias isn't being read anymore. I can see fixed in the fonts.alias and I can see the corresponding font in the fonts.dir and I can see that the font file exists and can verify that the server acknowledged that font path. I am looking into a similar problem too, when xfs is not running. I've been able to make the fontset message appear with a simple test case (holding down the control key and pressing any mouse button while the pointer is in an xterm). I've also tried this with a build where CHANGELOG 264 is backed out and it still happens so something else is causing this. CHANGELOG 264 is 264. In font handling, avoid potential security issues related to wrap-around of memory allocation requests (Marc La France). Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
What happened to the fonts?
I synced up and built and now, though the server starts fine, apps can't get any fonts. Window managers claim they can't find fontsets like fixed so menus and such have no text in them. xfontsel seems to work though. Anyone know what's going on? It's like the fonts.alias isn't being read anymore. I can see fixed in the fonts.alias and I can see the corresponding font in the fonts.dir and I can see that the font file exists and can verify that the server acknowledged that font path. Mark. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
