Re: [Fonts]Re: [I18n]Using current locale in font selection

2002-07-10 Thread Owen Taylor


Keith Packard [EMAIL PROTECTED] writes:

 Agreed; this choice was somewhat rhetorical in nature...
 
 b)  use $LANG or $LC_CTYPE?
 
If this road is taken, it has to be determined which env.
  variables have to be refered to in what order. AFAIK, SUS and POSIX say
  that it's implementation-dependent.
 
 Too bad the POSIX spec is closed so I can't check.  I've decided to go 
 ahead and do this and follow the glibc convention; that's based on the 
 principle of least surprise -- it would be very surprising to users when 
 the same font name generated different results in different applications.

[offtopic] Actually, the latest version of the POSIX/Single Unix spec
is freely available online, though it can be a little hard to find.

 http://www.unix-systems.org/version3/online.html

(registration is involved, which gives you an URL you can bookmark.)

As far as the question at hand; I think that giving up and using a
default value or no value is fine if setlocale() hasn't been
called. But I don't see any problems with checking
LC_ALL/LC_CTYPE/LANG... it might be a nice touch.

Regards,
Owen
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



Re: [Fonts]Re: [I18n]Using current locale in font selection

2002-07-10 Thread Keith Packard


Around 4 o'clock on Jul 10, Owen Taylor wrote:

 As far as the question at hand; I think that giving up and using a
 default value or no value is fine if setlocale() hasn't been
 called. But I don't see any problems with checking
 LC_ALL/LC_CTYPE/LANG... it might be a nice touch.

Given that POSIX specifies the order in which these are used, and given 
that all of my test programs don't call setlocale, I've added the trivial 
code to fetch from the environment.

Keith PackardXFree86 Core TeamHP Cambridge Research Lab


___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



Re: [Fonts]Re: [I18n]Using current locale in font selection

2002-07-09 Thread Keith Packard


Around 13 o'clock on Jul 9, Erik van der Poel wrote:

 Not that you need any more input to make this decision, but there is
 some precedent to go with LC_CTYPE too: the X Consortium went with that
 for both text output and keyboard input in their i18n work circa X11R5.

Ok, so now what do I do with applications which haven't called 
setlocale (LC_ALL, )?  Do I:

a)  call setlocal (LC_ALL, ) myself?
b)  use $LANG or $LC_CTYPE?
c)  Ignore the locale information and leave the
font language preference unset?

Keith PackardXFree86 Core TeamHP Cambridge Research Lab


___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



Re: [Fonts]Re: [I18n]Using current locale in font selection

2002-07-09 Thread Jungshik Shin




On Tue, 9 Jul 2002, Keith Packard wrote:

 Ok, so now what do I do with applications which haven't called
 setlocale (LC_ALL, )?  Do I:

   a)  call setlocal (LC_ALL, ) myself?

  I'm afraid this can have an unexpected side effect, which could
surprise/upset some application program developers.

   b)  use $LANG or $LC_CTYPE?

  If this road is taken, it has to be determined which env.
variables have to be refered to in what order. AFAIK, SUS and POSIX say
that it's implementation-dependent. Since XF86 is used with many OS',
it'd be best to follow the 'local' convention. Then, I don't know how
to figure it out without calling setlocale(LC_CTYPE,). In case of Glibc,

If $LC_ALL is set, use it
else if $LC_CTYPE is set, use it
else if $LANG is set,  use it.

   c)  Ignore the locale information and leave the
   font language preference unset?

  This might well be the best course along with documenting
that setlocale() should be called to make font matching/selection locale
dependent or that better still is to explicitly provide lang info when
invoking font selection APIs.

  Jungshik

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



[Fonts]Re: [I18n]Using current locale in font selection

2002-07-08 Thread Owen Taylor


Keith Packard [EMAIL PROTECTED] writes:

 Much as I hate the C locale model, I'm wondering if I shouldn't use the 
 current locale as a language hint where applications don't provide 
 explicit language information when selecting fonts.  This would make
 the generic aliases (like sans-serif) pick a font appropriate for the 
 locale instead of some random font most likely suitable for Latin 
 languages.
 
 Or would this only lead to confusion and chaos?

I think this is right; it's the only way that we'll get reasonably
consistent font choice between places where there is a heavyweight
system on top of Xft. (Pango, Mozilla, etc) and places that are
using Xft directly.

My language hack did this; feel free to use the code below if
it helps. 

Regards,
Owen


--- fontconfig/src/fccfg.c.langtag  Fri Jun 21 02:14:45 2002
+++ fontconfig/src/fccfg.c  Mon Jun 24 14:09:35 2002
@@ -23,6 +23,7 @@
  */
 
 #include fcint.h
+#include locale.h
 
 FcConfig*_fcConfig;
 
@@ -1059,6 +1060,50 @@
FcPatternDel (p, object);
 }
 
+static const FcChar8 canon_map[256] = {
+   0,   0,   0,   0,   0,   0,   0,   0,0,   0,   0,   0,   0,   0,   0,   0, 
+   0,   0,   0,   0,   0,   0,   0,   0,0,   0,   0,   0,   0,   0,   0,   0, 
+   0,   0,   0,   0,   0,   0,   0,   0,0,   0,   0,   0,   0,  '-',  0,   0, 
+   0,   0,   0,   0,   0,   0,   0,   0,0,   0,   0,   0,   0,   0,   0,   0, 
+   0,  'a', 'b', 'c', 'd', 'e', 'f', 'g',  'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
+  'p', 'q', 'r', 's', 't', 'u', 'v', 'w',  'x', 'y', 'z',  0,   0,   0,   0,  '-',
+   0,  'a', 'b', 'c', 'd', 'e', 'f', 'g',  'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
+  'p', 'q', 'r', 's', 't', 'u', 'v', 'w',  'x', 'y', 'z',  0,   0,   0,   0,   0
+};
+   
+static FcChar8 *
+FcGetDefaultLanguage (void)
+{
+FcChar8 *locale;
+FcChar8 *result;
+FcChar8 *p, *q;
+
+locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);
+result = malloc (strlen (locale + 1));
+if (!result)
+   return 0;
+
+p = locale;
+q = result;
+while (*p)
+{
+   FcChar8 value;
+
+   if (*p == '.' || *p == '@')
+   break;
+
+   value = canon_map[*p];
+   if (value)
+   *(q++) = value;
+
+   p++;
+}
+
+*q = 0;
+
+return result;
+}
+
 FcBool
 FcConfigSubstitute (FcConfig   *config,
FcPattern   *p,
@@ -1070,7 +1115,8 @@
 FcTest *t;
 FcEdit *e;
 FcValueList*l;
-
+FcValue v;
+
 if (!config)
 {
config = FcConfigGetCurrent ();
@@ -1078,6 +1124,18 @@
return FcFalse;
 }
 
+if (FcPatternGet (p, language, 0, v) == FcResultNoMatch)
+{
+   FcChar8 *language;
+
+   language = FcGetDefaultLanguage ();
+   if (!language)
+   return FcFalse;
+   
+   FcPatternAddString (p, language, language);
+   free (language);
+}
+
 st = (FcSubState *) malloc (config-maxObjects * sizeof (FcSubState));
 if (!st  config-maxObjects)
return FcFalse;
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



Re: [Fonts]Re: [I18n]Using current locale in font selection

2002-07-08 Thread Erik van der Poel

Owen Taylor wrote:
 
 +locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);
 +result = malloc (strlen (locale + 1));

Should be strlen(locale) + 1.

Erik
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



[Fonts]Re: [I18n]Using current locale in font selection

2002-07-08 Thread Keith Packard


Around 14 o'clock on Jul 8, Owen Taylor wrote:

 +locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);

Don't you mean LC_MESSAGES?  If so, I think we should be able to use this 
return value almost raw; stripping out the language and territory codes and
passing them in as FC_LANG, right?

(no case conversion is necessary, FC_LANG comparisons are already case 
insensitive).

Keith PackardXFree86 Core TeamHP Cambridge Research Lab


___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



[Fonts]Re: [I18n]Using current locale in font selection

2002-07-08 Thread Jungshik Shin




On Mon, 8 Jul 2002, Keith Packard wrote:


 Around 14 o'clock on Jul 8, Owen Taylor wrote:

  +locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);

 Don't you mean LC_MESSAGES?

  I believe it should be LC_CTYPE. Some people like me
have the following because English menu and (error) messages are easier
to understand than not-so-good translation.


  LC_CTYPE=ko_KR.eucKR
  LC_MESSAGES=C
  LC_PAPER=en_US   # because the US doesn't use ISO std. paper size
  .

  or

  LC_CTYPE=ko_KR.UTF-8
  LC_MESSAGES=en_US.UTF-8
  LC_PAPER=en_US.UTF-8
  .


 If so, I think we should be able to use this
 return value almost raw; stripping out the language and territory codes and
 passing them in as FC_LANG, right?

  Did you mean that only codeset part is relevant here and we can
go without relying on lang and territory codes? The codeset  doesn't
carry any lang-specific information if UTF-8 locale is used.

   Jungshik

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



[Fonts]Re: [I18n]Using current locale in font selection

2002-07-08 Thread Owen Taylor


Keith Packard [EMAIL PROTECTED] writes:

 Around 14 o'clock on Jul 8, Owen Taylor wrote:
 
  +locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);
 
 Don't you mean LC_MESSAGES?  If so, I think we should be able to use this 
 return value almost raw; stripping out the language and territory codes and
 passing them in as FC_LANG, right?

Interesting question... My opinion is that LC_CTYPE is right... if
someone does something like:

 LANG=ja_JP.UTF-8 LC_MESSAGES=en_US.UTF-8 

They typically mean I want to process Japanese text, but show me
messages in English. 

We should then be picking fonts that work well for Japanese.

It's very seldom that anybody would have a LC_MESSAGES value that
wasn't displayable in their LC_CTYPE; that would be nonsensical...

LC_CTYPE is defined by POSIX to specify Character classification and
case conversion, while LC_MESSAGES is Formats of informative and
diagnostic messages and interactive responses. Neither is an exact
match here, but I'd argue that the typical use of mixed locales 
makes LC_CTYPE more useful.

 (no case conversion is necessary, FC_LANG comparisons are already case 
 insensitive).

This is code taken from GTK+ ... case conversions were mostly for
elegance, so that the form returned by get_default_lang() matched the
canonical form of the Pango language tags.

Regards,
Owen
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts