Re: Full unicode support for back-xlib (2)

[Fred Kiefer]

Hi Kazu,

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.

Cheers
Fred

Kazunobu Kuriyama wrote:
> Fred Kiefer wrote:
> > <snip>
> > It is even worse, the man page says:
> >
> > BUGS
> >        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, 
> harmless.
>
> > > Though the current code might look a bad programming style, I think
> > > it is the right place to compromise.
> > 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 
> > treatment.
>
>
> 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.
>
> > > 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?)
> > 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. 
>
> 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
> user-configurable.)
> > 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.