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

[Fred Kiefer]

Kazunobu Kuriyama wrote:
> Thank you for reading the code very carefully and extensively.
This is what we should do a lot more, normally we don't have the time 
for it, but this time I owe it to you.

> Fred Kiefer wrote:
>  > <snip>
>  > - As XGFontSetEnumerator is currently not implemented I would remove
>  > all reverences to it.
>
> (Reading references for reverences,)
> At first, I declared XGFontSetEnumerator without implementation, and
> then I got an exception telling me that enumerateFontsAndFamilies should
> be overridden.  So I put the stub of it to make the module work.
> This is the only reason I did it.  If the declaration is unnecessary and
> is the cause of throwing the exception, your suggestion is helpful to make
> the implementation better.

I meant to remove the whole class until there is real code for it.

>  > - My man pages warn about the use of the funtion strtok(). Why not
>  > pass into load_font_set() the NSString and use
>  > [componentsSeparatedByString:] (This method is also use in the
>  > font_chacher.m)?
>
> I guess your man pages tell you that strtok() modifies a given
> original string, replacing a delimiter with a whitespace. Because
> the current implmenetation invokes strtok() against a copy of the
> original string, not the original one, I don't think the warning
> makes the case.

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.
> I intentionally and extensively make use of the C library functions
> over there because of efficiency.  As you can see, we need many
> system calls and communications with the X server there, which
> inevitably and significantly make programs crawl.  If this does
> not make sense, I agree to the opinion that use of NSString would
> be better.

As you said, there are a lot of X calls involced, which may take some 
time, therefor it should not be to bad to work with ObjC objects in the 
rest of the code, as they are most certainly faster than the X calls.
> 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.


>  > In this part of the code I am also a bit unsure about the pieces of
>  > the XLFD that you use and the ones you discard. Could you explain,
>  > document what you do and why? (For example, I would use the family and
>  > discard the foundry, you do the opposit)

> 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.
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.

>  > - What we could also think of is to make the switch between your and
>  > the standard implementation of font handling one at runtime. Allowing
>  > for a simpler transistion without recompiling the backend each time.
>  > See the user default for the use of the XFT fonts.
>  >
>
> I'd like it if the development team would allow me to do so.  I guess we
> need a new boolean user default value, say, GSEnableXFontSet or
> GSXEnableFontSet (or, FontSet may be replaced with MultiByte).
> Could you suggest me a better name?

These two names sound fine for me, the later is perhaps a bit closer to 
what we have there already. Go ahead and add this, but dont forget to 
document it in back/Documentation/Back/DefaultsSummary.gsdoc. I think 
for the start the default should be NO, but we may change this as this 
option gets tested more.

Cheers
Fred