[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Full unicode support for back-xlib (2)
Re: Full unicode support for back-xlib (2)
Sat, 19 Jul 2003 13:06:47 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204
we now have reached a disagreement and need some more views on the
remaining problems. Perhaps Nicola, Adam, Wim or Alex could join in and
state their views on the use font sets.
I am away for a few days anyway.
Kazunobu Kuriyama wrote:
Fred Kiefer wrote:
It is even worse, the man page says:
Never use these functions. If you do, note that:
These functions modify their first argument.
These functions cannot be used on constant strings.
The identity of the delimiting character is lost.
The strtok() function uses a static buffer while
parsing, so it's not thread safe. Use strtok_r() if
this matters to you.
I don't think that this could cause any harm in your case, still I
would avoid it.
Taking all the points above into consideration, I did it. Hopefully,
I was also worried about the special treatment you do for missing add
styles, as I can tell from the fonts installed on my machine almost
any part of a XLFD may be missing, this should not cause any special
Though the current code might look a bad programming style, I think
it is the right place to compromise.
I simply need to distinguish the token '--' from the token '-'. It
could be written in a more generalized way,
but it would results in over-engineering.
You can't use the return value of XGFontName() directly to load multiple
fonts with XCreateFontSet() because
XGFontName() is biased in favor of European fonts (see below). The code
which looks special to you absorbs
this GNUstep's specialization.
Are you saying that for Asian fonts there is no such thing as a font
family? Or do they just have different names not Helvetica, which is
what I would expect.
As for the latter question: People can't expect every font on the earth
has the family property called 'Helvetica', 'Courier' or something
else which is taken for granted in Latin characters, while they can find
fonts with the foundry property such as 'Adobe' and 'fixed'.. The
current implementation reflects this reality.
(Because I thought this was a common knowledge, I didn't document
it in detail. This gives another example that people always think
their own ways as 'the' standard, doesn't this?)
I didn't say Asian fonts have no font family. When I checked the state
of the internal variables of GNUstep
related to fonts, I found that it exclusively uses Helvetica, Courier or
something like that. You'll never
find Japanese Helvetica, Chinese Courier, Korean Times, Thai Utopia, ...
(If I remember correctly,
Alexander Malmberg once told us in discuss-gnustep that he considered to
make the family specification
We seem to have a real problem here. On my machine I have about 10
different fonts from Adobe installed (of course each with dozens of
styles and sizes). They have a totally different appearance and I
never would want to mix them when displaying a string. Whereas I would
not mind to mix Helvetica coming from different sources.
Your current implementation of building up font sets would be rather
unusable for any European language user (probably even for US
Americans, but you never can tell), as this would merge fonts that
don't belong together.
Don't worry. The X server tries loading two or more fonts only if it
needs to do so. This is done based on
the locale in use.
- Full unicode support for back-xlib (2), Kazunobu Kuriyama, 2003/07/16
- Re: Full unicode support for back-xlib (2), Fred Kiefer, 2003/07/17
- Re: Full unicode support for back-xlib (2), Kazunobu Kuriyama, 2003/07/17
- Re: Full unicode support for back-xlib (2), Fred Kiefer, 2003/07/18
- Re: Full unicode support for back-xlib (2), Kazunobu Kuriyama, 2003/07/18
- Re: Full unicode support for back-xlib (2),
Fred Kiefer <=
- Re: Full unicode support for back-xlib (2), Kazunobu Kuriyama, 2003/07/19
- Re: Full unicode support for back-xlib (2), Adam Fedor, 2003/07/20
- Full unicode support for back-xlib(4) (was Re: Full unicode support for back-xlib (2)), Kazunobu Kuriyama, 2003/07/22
- Re: Full unicode support for back-xlib(4) (was Re: Full unicode support for back-xlib (2)), Adam Fedor, 2003/07/23