From vivek@lantana.tenet.res.in Tue Jun 3 01:40:39 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 8939618A4D for ; Tue, 3 Jun 2003 01:40:34 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h535df530262 for ; Tue, 3 Jun 2003 11:09:44 +0530 Subject: utf-8 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-huysmgQWAktM7Ldxz9Kk" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jun 2003 11:10:40 +0530 Message-Id: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-huysmgQWAktM7Ldxz9Kk Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi In Pango, the strings are stroed in the UTF-8 standard. But, while i read the characters as integer, it gives some negative values. For example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the case for all the characters. How can I get the exact UTF-8 value ? I get the above values in Pango-context.c and shape.c with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-huysmgQWAktM7Ldxz9Kk Content-Type: text/html; charset=utf-8 Hi
  In Pango, the strings are stroed in the UTF-8 standard.  But, while i read the characters as integer, it gives some negative values. For example,  -32 -92 -107 is stored there for Devanagari 'ka'. This is the case for all the characters. How can I get the exact UTF-8 value ?  

I get the above values in Pango-context.c and shape.c

with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-huysmgQWAktM7Ldxz9Kk-- From nlevitt@computer.cc.columbia.edu Tue Jun 3 01:48:16 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id 90CD518135 for ; Tue, 3 Jun 2003 01:48:16 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19N4eS-0005OJ-00; Tue, 03 Jun 2003 01:48:04 -0400 Date: Tue, 3 Jun 2003 01:48:04 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: utf-8 Message-ID: <20030603054804.GI20359@columbia.edu> References: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Use g_utf8_get_char_validated or g_utf8_get_char to get the unicode character. You are looking at the byte values, which are not generally useful. If you are sure you want the UTF-8 bytes, you might want to cast to guchar if you want the unsigned values. gtk-list or gtk-app-devel-list would be better for this type of question. Noah On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while i > read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the > case for all the characters. How can I get the exact UTF-8 value ? > > I get the above values in Pango-context.c and shape.c > > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda From vivek@lantana.tenet.res.in Tue Jun 3 02:18:40 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 76639183C4 for ; Tue, 3 Jun 2003 02:18:35 -0400 (EDT) Received: from lantana.iitm.ernet.in (lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h536J4C23735 for ; Tue, 3 Jun 2003 11:49:04 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h536Hl531438 for ; Tue, 3 Jun 2003 11:47:47 +0530 Subject: Re: utf-8 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-D2E9hJukNaaTHzX9XosU" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jun 2003 11:48:47 +0530 Message-Id: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-D2E9hJukNaaTHzX9XosU Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Naoh. I have one more doubt. If we give 8bit value in the input (gtk), whether it is converted to UTF-8, before it gets stored ? Can we store the 8-bit value as it is (instead of converting to UTF-8) in GTK applications ? with regards vivek On Tue, 2003-06-03 at 11:18, Noah Levitt wrote: Use g_utf8_get_char_validated or g_utf8_get_char to get the unicode character. You are looking at the byte values, which are not generally useful. If you are sure you want the UTF-8 bytes, you might want to cast to guchar if you want the unsigned values. gtk-list or gtk-app-devel-list would be better for this type of question. Noah On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while i > read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the > case for all the characters. How can I get the exact UTF-8 value ? > > I get the above values in Pango-context.c and shape.c > > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-D2E9hJukNaaTHzX9XosU Content-Type: text/html; charset=utf-8 Thanks Naoh.
   I have one more doubt.  If we give 8bit value in the input (gtk), whether it is converted to UTF-8, before it gets stored ? Can we store the 8-bit value as it is (instead of converting to UTF-8) in GTK applications ?

with regards
vivek

On Tue, 2003-06-03 at 11:18, Noah Levitt wrote: 
Use g_utf8_get_char_validated or g_utf8_get_char to get the
unicode character. You are looking at the byte values, which
are not generally useful.

If you are sure you want the UTF-8 bytes, you might want to
cast to guchar if you want the unsigned values.

gtk-list or gtk-app-devel-list would be better for this type
of question.

Noah

On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote:
> Hi
>   In Pango, the strings are stroed in the UTF-8 standard.  But, while i
> read the characters as integer, it gives some negative values. For
> example,  -32 -92 -107 is stored there for Devanagari 'ka'. This is the
> case for all the characters. How can I get the exact UTF-8 value ?   
> 
> I get the above values in Pango-context.c and shape.c
> 
> with regards
> vivek
> -- 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
> Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> All condemnation of others really condemns ourselves - Swami Vivekananda
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda

--=-D2E9hJukNaaTHzX9XosU-- From nlevitt@computer.cc.columbia.edu Tue Jun 3 02:52:52 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id C4FF318110 for ; Tue, 3 Jun 2003 02:52:52 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19N5XT-0006CR-00; Tue, 03 Jun 2003 02:44:55 -0400 Date: Tue, 3 Jun 2003 02:44:55 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: utf-8 Message-ID: <20030603064455.GA23823@columbia.edu> References: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: I don't understand the question at all. (8bit value? input? converted? stored? What do you mean by these?) Noah On Tue, Jun 03, 2003 at 11:48:47 +0530, Viveka Nathan K wrote: > Thanks Naoh. > I have one more doubt. If we give 8bit value in the input (gtk), > whether it is converted to UTF-8, before it gets stored ? Can we store > the 8-bit value as it is (instead of converting to UTF-8) in GTK > applications ? > > with regards > vivek > From morwen@evilmagic.org Tue Jun 3 12:14:12 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail1-gui.server.ntli.net (mail1-gui.server.ntli.net [194.168.222.13]) by mail.gnome.org (Postfix) with ESMTP id 2CA1818285 for ; Tue, 3 Jun 2003 12:14:12 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mail1-gui.server.ntli.net (Post.Office MTA v3.1 release PO203a ID# 0-33929U70000L2S50) with ESMTP id AAA12970; Tue, 3 Jun 2003 17:14:00 +0100 Subject: Re: utf-8 From: Abigail Brady To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org In-Reply-To: <1054618844.955.31.camel@dodo.lli.tenet.res.in> References: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Content-Type: text/plain Organization: Message-Id: <1054656653.17407.4.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 17:10:53 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Tue, 2003-06-03 at 06:40, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while > i read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is > the case for all the characters. How can I get the exact UTF-8 value > ? I don't see why this is a surprise at all to you - that IS the correct UTF-8 encoding for KA. (E0, A4, 95, treated as 8-bit twos complement is -32 -92 -107). Perhaps you misunderstand UTF-8 or C. What are you expecting to see? -- Abi From vantr@touchtunes.com Tue Jun 3 10:39:54 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.touchtunes.com (operator.touchtunes.com [207.96.182.163]) by mail.gnome.org (Postfix) with ESMTP id 7C8E7184F5; Tue, 3 Jun 2003 10:39:54 -0400 (EDT) Received: from touchtunes.com (vantr.touchtunes.com [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 59921159E4; Tue, 3 Jun 2003 10:11:04 -0400 (EDT) Message-ID: <3EDCA50F.7030008@touchtunes.com> Date: Tue, 03 Jun 2003 09:39:27 -0400 From: Tristan Van Berkom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "B. Souliotis" Cc: gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org, gtk-list-request@gnome.org Subject: Re: Making Signal For A Widget. References: <3EDC8E7E.4010901@beta-cae.gr> In-Reply-To: <3EDC8E7E.4010901@beta-cae.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: You might do well to note also that gtkwidget.c is like a HUB for all theese events. As input, you get your GdkEvents and as output, you have a bunch of basic signals that are "emmited" at the GtkWidget level and handlers are "implemented" by various subclasses. you should probably read this: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Event-Structures.html#GdkEventButton when a "clicked" signal is emitted (by the GtkButtonClass); the mouse button has already been "released". now wether you mean the "Left button", the "button down" or "button press" by "First" is an entirely different question. Hope this helps, -Tristan From vivek@lantana.tenet.res.in Thu Jun 5 01:52:53 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id AEBEE18237 for ; Thu, 5 Jun 2003 01:52:44 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h555pP531885 for ; Thu, 5 Jun 2003 11:21:30 +0530 Subject: compiling gtk program From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-rozlI9E79IeeDf+2jH1O" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Jun 2003 11:22:49 +0530 Message-Id: <1054792374.916.23.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-rozlI9E79IeeDf+2jH1O Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi.. I took the sample program given in GTK documentation (helloworld.c) and I compiled it. It gives the error as : : /usr/include/gtk-1.2/glib/gtypes.h:41: syntax error before "typedef" : : /usr/include/gtk-1.2/glib/garray.h:32: parse error before "G_BEGIN_DECLS" /usr/include/gtk-1.2/glib/garray.h:34: syntax error before "typedef" : : what is that 'G_BEGIN_DECLS' I went through that gtypes.h.. there it is like as follows. What should I do to compile the program ? : : #include G_BEGIN_DECLS /* Provide type definitions for commonly used types. typedef char gchar; typedef short gshort; : : -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-rozlI9E79IeeDf+2jH1O Content-Type: text/html; charset=utf-8 Hi..
  I took the sample program given in GTK documentation (helloworld.c) and I compiled it.
It gives the error as

:
:
/usr/include/gtk-1.2/glib/gtypes.h:41: syntax error before "typedef"
:
:
/usr/include/gtk-1.2/glib/garray.h:32: parse error before "G_BEGIN_DECLS"
/usr/include/gtk-1.2/glib/garray.h:34: syntax error before "typedef"
:
:

what is that 'G_BEGIN_DECLS'

I went through that gtypes.h.. there it is like as follows.  What should I do to compile the program ?

:
:
#include <glibconfig.h>

G_BEGIN_DECLS

/* Provide type definitions for commonly used types.
typedef char   gchar;
typedef short  gshort;
:
: 

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-rozlI9E79IeeDf+2jH1O-- From vivek@lantana.tenet.res.in Thu Jun 5 07:17:43 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 069B818130 for ; Thu, 5 Jun 2003 07:17:39 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h55BGS511062 for ; Thu, 5 Jun 2003 16:46:31 +0530 Subject: pango ? From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-KgCMtsNS3UFlBsYuXcN4" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Jun 2003 16:47:56 +0530 Message-Id: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-KgCMtsNS3UFlBsYuXcN4 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi.. I am going to create one application in GTK with pango. In the normal program, if it contains the English string in the following label, button = gtk_button_new_with_label ("Hai!"); It displayed correctly. If i replace the string with 'UTF-8' characters, it didn't display anything. What should I add to display the UTF-8 characters using pango? Thanking you with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-KgCMtsNS3UFlBsYuXcN4 Content-Type: text/html; charset=utf-8 Hi..
 
  I am going to create one application in GTK with pango. In the normal program, if it contains
the English string in the following label,
  button = gtk_button_new_with_label ("Hai!");
  It displayed correctly.

If i replace the string with 'UTF-8' characters, it didn't display anything.
What should I add to display the UTF-8 characters using pango?

Thanking you
with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-KgCMtsNS3UFlBsYuXcN4-- From nlevitt@computer.cc.columbia.edu Thu Jun 5 11:28:12 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id 0476E18216 for ; Thu, 5 Jun 2003 11:28:12 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19Nwel-0006kJ-00; Thu, 05 Jun 2003 11:27:59 -0400 Date: Thu, 5 Jun 2003 11:27:59 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: pango ? Message-ID: <20030605152759.GA25898@columbia.edu> References: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Either it wasn't valid UTF-8 or you don't have fonts with the characters you were trying to draw. Noah On Thu, Jun 05, 2003 at 16:47:56 +0530, Viveka Nathan K wrote: > Hi.. > > I am going to create one application in GTK with pango. In the normal > program, if it contains > the English string in the following label, > button = gtk_button_new_with_label ("Hai!"); > It displayed correctly. > > If i replace the string with 'UTF-8' characters, it didn't display > anything. > What should I add to display the UTF-8 characters using pango? > > Thanking you > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda From vivek@lantana.tenet.res.in Fri Jun 6 02:59:00 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 0603A18121 for ; Fri, 6 Jun 2003 02:58:58 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h566wjQ04641; Fri, 6 Jun 2003 12:28:47 +0530 Subject: gtk program compilation error. From: Viveka Nathan K To: gtk-i18n-list@gnome.org Cc: cyrille@chepelov.org, nlevitt@columbia.edu Content-Type: multipart/alternative; boundary="=-H3/KZLLR0Pn0k2xeOhCD" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jun 2003 12:28:47 +0530 Message-Id: <1054882734.913.7.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-H3/KZLLR0Pn0k2xeOhCD Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Noah and Cyrille.. Now I installed gtk+-2.0 and compiled my program. Now it says the error as /tmp/ccNUHBNN.o: In function `main': /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:62: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:65: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:74: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:81: undefined reference to `g_type_check_instance_cast' /tmp/ccNUHBNN.o:/home/smilax2/vivekanathan/gtk/helloworld.c:81: more undefined references to `g_type_check_instance_cast' follow collect2: ld returned 1 exit status Before this, it said errors on some header files as 'No such file or directory'. I copied those files in the location as it needed. Now I dont know what to do for the above problem. Can you help me ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-H3/KZLLR0Pn0k2xeOhCD Content-Type: text/html; charset=utf-8 Thanks Noah and Cyrille..

Now I installed gtk+-2.0 and compiled my program.
Now it says the error as

/tmp/ccNUHBNN.o: In function `main':
/home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:62: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:65: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:74: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:81: undefined reference to `g_type_check_instance_cast'
/tmp/ccNUHBNN.o:/home/smilax2/vivekanathan/gtk/helloworld.c:81: more undefined references to `g_type_check_instance_cast' follow
collect2: ld returned 1 exit status 
Before this, it said errors on some header files as 'No such file or directory'.
I copied those files in the location as it needed.  Now I dont know what to do
for the above problem.  Can you help me ?
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-H3/KZLLR0Pn0k2xeOhCD-- From cyrille@chepelov.org Fri Jun 6 04:26:44 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chepelov.net1.nerim.net (chepelov.net1.nerim.net [62.212.101.212]) by mail.gnome.org (Postfix) with ESMTP id 4FFEE18363 for ; Fri, 6 Jun 2003 04:26:44 -0400 (EDT) Received: from muscat-eth0.intra.chepelov.org ([2001:7a8:29d4:0:2a0:24ff:fea6:57a0] helo=muscat.intra.chepelov.org) by chepelov.net1.nerim.net with esmtp (Exim 3.35 #1 (Debian)) id 19OCaP-0005bp-00; Fri, 06 Jun 2003 10:28:33 +0200 Received: from cyrille by muscat.intra.chepelov.org with local (Exim 3.36 #1 (Debian)) id 19OCYP-0006tQ-00; Fri, 06 Jun 2003 10:26:29 +0200 Date: Fri, 6 Jun 2003 10:26:29 +0200 To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: gtk program compilation error. Message-ID: <20030606082629.GA26487@chepelov.org> Mail-Followup-To: Viveka Nathan K , gtk-i18n-list@gnome.org References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1054882734.913.7.camel@dodo.lli.tenet.res.in> X-Face: "99`N"mZV/:OLp[>#d3R;u.!ivtwAEpIQDL8rD#;L3Wm)~^)Uv=#;S!LZf1y8oRY7J#JR\Lr{*4Cn*32C89ln>0~5~tm--}j%hvhj+vtW> Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Le Fri, Jun 06, 2003, à 12:28:47PM +0530, Viveka Nathan K a écrit: > Thanks Noah and Cyrille.. > > Now I installed gtk+-2.0 and compiled my program. > Now it says the error as > > /tmp/ccNUHBNN.o: In function `main': > /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to > `g_type_check_instance_cast' What arguments did you give to ld ? did you pass `pkg-config --libs gtk+-2.0` ? > Before this, it said errors on some header files as 'No such file or directory'. > I copied those files in the location as it needed. Now I dont know what to do > for the above problem. Can you help me ? What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0` ? -- Cyrille -- From vivek@lantana.tenet.res.in Fri Jun 6 05:03:28 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 8E68D184D4 for ; Fri, 6 Jun 2003 05:03:25 -0400 (EDT) Received: from lantana.iitm.ernet.in (lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h56942C22089 for ; Fri, 6 Jun 2003 14:34:02 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h56931Q08465; Fri, 6 Jun 2003 14:33:01 +0530 Subject: Re: gtk program compilation error. From: Viveka Nathan K To: Cyrille Chepelov Cc: gtk-i18n-list@gnome.org In-Reply-To: <20030606082629.GA26487@chepelov.org> References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> <20030606082629.GA26487@chepelov.org> Content-Type: multipart/alternative; boundary="=-/KP8l3ifKKUoAc1WvTY5" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jun 2003 14:33:04 +0530 Message-Id: <1054890184.939.13.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-/KP8l3ifKKUoAc1WvTY5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Cyrille.. Its working now. I compiled the source previously as gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags`=20 `gtk-config --libs` now, as I did as you told. Its going on and working properly :) Thank you once again On Fri, 2003-06-06 at 13:56, Cyrille Chepelov wrote: Le Fri, Jun 06, 2003, =E0 12:28:47PM +0530, Viveka Nathan K a =E9crit: > Thanks Noah and Cyrille.. >=20 > Now I installed gtk+-2.0 and compiled my program. > Now it says the error as >=20 > /tmp/ccNUHBNN.o: In function `main': > /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined referenc= e to > `g_type_check_instance_cast' =20 What arguments did you give to ld ? =20 did you pass `pkg-config --libs gtk+-2.0` ? =20 =20 > Before this, it said errors on some header files as 'No such file or= directory'. > I copied those files in the location as it needed. Now I dont know = what to do > for the above problem. Can you help me ? =20 What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0`= ? =20 -- Cyrille =20 --=20 =20 --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D=20 Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D All condemnation of others really condemns ourselves - Swami Vivekananda --=-/KP8l3ifKKUoAc1WvTY5 Content-Type: text/html; charset=utf-8 Thanks Cyrille.. Its working now.

I compiled the source previously as
gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags`  `gtk-config --libs`

now, as I did as you told. Its going on and working properly :)
Thank you once again

On Fri, 2003-06-06 at 13:56, Cyrille Chepelov wrote: 
Le Fri, Jun 06, 2003, à 12:28:47PM +0530, Viveka Nathan K a écrit:
>    Thanks Noah and Cyrille..
> 
>    Now I installed gtk+-2.0 and compiled my program.
>    Now it says the error as
> 
>    /tmp/ccNUHBNN.o: In function `main':
>    /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to
>    `g_type_check_instance_cast'

What arguments did you give to ld ?

did you pass `pkg-config --libs gtk+-2.0` ?


>  Before this, it said errors on some header files as 'No such file or directory'.
>  I copied those files in the location as it needed.  Now I dont know what to do
>  for the above problem.  Can you help me ?

What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0` ?

	-- Cyrille

-- 

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-/KP8l3ifKKUoAc1WvTY5-- From cyrille@chepelov.org Fri Jun 6 05:48:33 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chepelov.net1.nerim.net (chepelov.net1.nerim.net [62.212.101.212]) by mail.gnome.org (Postfix) with ESMTP id BB4A3184D4 for ; Fri, 6 Jun 2003 05:48:32 -0400 (EDT) Received: from muscat-eth0.intra.chepelov.org ([2001:7a8:29d4:0:2a0:24ff:fea6:57a0] helo=muscat.intra.chepelov.org) by chepelov.net1.nerim.net with esmtp (Exim 3.35 #1 (Debian)) id 19ODre-0005qM-00; Fri, 06 Jun 2003 11:50:26 +0200 Received: from cyrille by muscat.intra.chepelov.org with local (Exim 3.36 #1 (Debian)) id 19ODpd-0006hx-00; Fri, 06 Jun 2003 11:48:21 +0200 Date: Fri, 6 Jun 2003 11:48:21 +0200 To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: gtk program compilation error. Message-ID: <20030606094821.GA25745@chepelov.org> Mail-Followup-To: Viveka Nathan K , gtk-i18n-list@gnome.org References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> <20030606082629.GA26487@chepelov.org> <1054890184.939.13.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1054890184.939.13.camel@dodo.lli.tenet.res.in> X-Face: "99`N"mZV/:OLp[>#d3R;u.!ivtwAEpIQDL8rD#;L3Wm)~^)Uv=#;S!LZf1y8oRY7J#JR\Lr{*4Cn*32C89ln>0~5~tm--}j%hvhj+vtW> Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Le Fri, Jun 06, 2003, à 02:33:04PM +0530, Viveka Nathan K a écrit: > I compiled the source previously as > gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags` `gtk-config > --libs` Oh, I see. No wonder you had gtk 1.2 files coming in; gtk-config is for the 1.2 versions. Happy to know it's working now. -- Cyrille -- From otaylor@redhat.com Mon Jun 9 01:04:55 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 037D218169; Mon, 9 Jun 2003 01:04:54 -0400 (EDT) Received: from vpn50-35.rdu.redhat.com (vpn50-35.rdu.redhat.com [172.16.50.35]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5954sK32431; Mon, 9 Jun 2003 01:04:54 -0400 Subject: Pango-1.2.3 released From: Owen Taylor To: gnome-announce-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org Content-Type: text/plain Organization: Message-Id: <1055135072.1665.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 09 Jun 2003 01:04:32 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Pango-1.2.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.2/ As compared to Pango-1.2.1 (Pango-1.2.2 was a short-lived release and never announced), this release contains various bug fixes, a large speedup to layout with the Xft and FT2 backends (as much as 5 times faster for short strings), and new shapers to allow Indic and Thai to be used with the FT2 backend. About Pango =========== Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most usage so far as been in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+ 2. Pango is designed to be modular; the core Pango layout can be used with four different font backends: - Core X windowing system fonts - Client-side fonts on X using the Xft2 library - Direct rendering of scalable fonts using the FreeType library - Native fonts on Microsoft platforms Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango-1.2 ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango depends on version 2.2.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of Changes in Pango 1.2.2 ================================== * Fix operation with --disable-debug [Jeff Waugh] * Improve handling of ink rectangle extents for empty runs * Fix problem with keynav at line boundaries for RTL text [Matthias Clasen] Overview of Changes in Pango 1.2.2 ================================== * Cache fontsets for the Xft and FT2 backends, a large speedup for short strings [Owen Taylor, Soeren Sandmann] * Make built in rendering functions, especially the FT2 one, work more like the GDK implementation [Sven Neumann] * Add an indic-ft2 module [Kapil Chowskey], Add a thai-ft2 module [Theppitak Karoonboonyanan] * Optimize pango_x_render() by drawing multiple character with a single request when possible [Morten Welinder] * Change the handling of attributes that cover only partial glyphs [Owen, Taneem Ahmed, Sunil Mohan Adapa] * Fix problems with Arial Unicode and the Opentype code [Owen, Noah Levitt] * Fix common crash for fonts missing a GDEF table * Fix common portability problem with informative output at end of configure. * Build cleanups and fixes [Tim Mooney, Chris Ross, Akira Tagoh, Will Partain, James Su] * Miscellaneous bug fixes and cleanups [Simon Budig, Rick Jones, Noah, Padraig O'Briain, Benjamin Otte, Andrey Panov, Federic Zhang] * Documentation fixes [Tim, Sven] Owen Taylor 9 June 2003 From sky@icqus.dyndns.org Mon Jun 9 16:32:24 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from icqus.dyndns.org (12-215-147-200.client.mchsi.com [12.215.147.200]) by mail.gnome.org (Postfix) with ESMTP id 67E75187AD for ; Mon, 9 Jun 2003 16:32:24 -0400 (EDT) Received: from icqus.dyndns.org (sky@localhost.my.domain [IPv6:::1]) by icqus.dyndns.org (8.12.9/8.12.9) with ESMTP id h59KWNpp005422 for ; Mon, 9 Jun 2003 16:32:23 -0400 (EDT) Received: (from sky@localhost) by icqus.dyndns.org (8.12.9/8.12.9/Submit) id h59KU0bD021164 for gtk-i18n-list@gnome.org; Mon, 9 Jun 2003 16:30:00 -0400 (EDT) Date: Mon, 9 Jun 2003 16:30:00 -0400 (EDT) From: Teardrop Sky Message-Id: <200306092030.h59KU0bD021164@icqus.dyndns.org> To: gtk-i18n-list@gnome.org Subject: unicode fonts Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: i had a question about unicode fonts that i posted to gtk-list, but i just discovered this list and realized it had been more appropriate here, but in short i'm looking for examples of unicode code written for gtk+2. (specifically with greek and hebrew fonts, but anything to sift through would be welcome) links or short examples, whatever. thanks :) ~sky From vivek@lantana.tenet.res.in Tue Jun 10 08:40:48 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id F3849180EE for ; Tue, 10 Jun 2003 08:40:45 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5ACea804262 for ; Tue, 10 Jun 2003 18:10:39 +0530 Subject: compiling gtk+-2.2.1 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-ttvrksX/Kvt+Z581nOPE" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Jun 2003 18:10:54 +0530 Message-Id: <1055248857.10655.3.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-ttvrksX/Kvt+Z581nOPE Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii I am upgrading the gtk (which is available with RH 8.0) to gtk+-2.2.1. After completing the make and make install, While starting the gnome-session, I got the following error. gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name This lib is linked with the lib which is currently created as follows lrwxrwxrwx 1 root root 25 Jun 10 17:55 /usr/lib/libgdk-x11-2.0.so.0 -> libgdk-x11-2.0.so.0.200.1 What should I do ? with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-ttvrksX/Kvt+Z581nOPE Content-Type: text/html; charset=utf-8 Hii
I am upgrading the gtk (which is available with RH 8.0) to gtk+-2.2.1. After completing the make and make install,  While starting the gnome-session, I got the following error.

gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name

This lib is linked with the lib which is currently created as follows
lrwxrwxrwx    1 root     root           25 Jun 10 17:55 /usr/lib/libgdk-x11-2.0.so.0 -> libgdk-x11-2.0.so.0.200.1

What should I do ?

with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-ttvrksX/Kvt+Z581nOPE-- From vivek@lantana.tenet.res.in Thu Jun 12 04:35:17 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id EFFD318D26 for ; Thu, 12 Jun 2003 04:35:14 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5C8Yk830183 for ; Thu, 12 Jun 2003 14:04:48 +0530 Subject: [Fwd: Use of Bonobo (fwd)] From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-v4j5dv3CjxL1ERGc2Gfa" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 12 Jun 2003 14:05:32 +0530 Message-Id: <1055406934.20734.4.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-v4j5dv3CjxL1ERGc2Gfa Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii all, Can anyone please tell me what is the role of Bonobo object in gedit? with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-v4j5dv3CjxL1ERGc2Gfa Content-Type: text/html; charset=utf-8 
Hii all,
	Can anyone please tell me what is the role of Bonobo object in gedit?

with regards
vivek
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-v4j5dv3CjxL1ERGc2Gfa-- From chutz@gg3.net Sat Jun 14 04:00:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from tiger.gg3.net (142.13.111.219.st.bbexcite.jp [219.111.13.142]) by mail.gnome.org (Postfix) with SMTP id 855E618512 for ; Sat, 14 Jun 2003 04:00:29 -0400 (EDT) Received: (qmail 23398 invoked by uid 0); 14 Jun 2003 08:00:28 -0000 Received: from tiger.gg3.net (10.0.0.9) by 0 with SMTP; 14 Jun 2003 08:00:28 -0000 Received: from lion.gg3.net (10.0.0.2) by tiger.gg3.net (tmda-ofmipd) with ESMTP; Sat, 14 Jun 2003 17:00:27 +0900 Received: by lion.gg3.net (sSMTP sendmail emulation); Sat, 14 Jun 2003 17:00:27 +0900 Date: Sat, 14 Jun 2003 17:00:27 +0900 To: gtk-i18n-list@gnome.org Subject: Regarding selection of alternate fonts (with untagged text) Message-ID: <20030614080027.GA4590%chutz@gg3.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.5.4i-ja.1 From: Georgi Georgiev Mail-Followup-To: gtk-i18n-list@gnome.org X-Delivery-Agent: TMDA/0.74 (Citation) X-Primary-Address: chutz@gg3.net Reply-To: Georgi Georgiev Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello list, I have a question/problem which was partially answered at http://www.pango.org/font-selection.shtml (I hope this is the right list to post my question to). My question is related to language auto-tagging and the selection of an alternate font that Pango makes in different locales. My problem is that basically, it chooses different fonts for Cyrillic text when LC_ALL is set to bg_BG or ja_JP. There were a few interesting posts I found in the mailing list archive, but the talk being too broad, I had trouble understanding if this problem is being tackled or not. Here goes a more detailed description of what I mean. What happens is that I for example have my locale set to ja_JP. Actually it is only LC_CTYPE=ja_JP LC_COLLATE=ja_JP LC_MONETARY=ja_JP and the rest LC_*=C (LC_ALL is unset). I need the few ja_JP because I want to be able to properly display Japanese in all applications, but I prefer to read messages in English. I also need it for Japanese input. However, I sometimes also work with Cyrillic (actually pretty often). What happens when Pango is asked for a font that does not have the Cyrillic characters is that it of course does that auto-tagging and substitution (I guess) and hands me a different font that has the characters that I need. In my /etc/fonts/fonts.conf I have the following: sans-serif Bitstream Vera Sans Arial Verdana Nimbus Sans L Luxi Sans Helvetica Kochi Gothic AR PL KaitiM GB AR PL KaitiM Big5 Baekmuk Dotum SimSun When I run a program with LC_ALL=bg_BG, Cyrillic is displayed in Arial. However, when I run it with LC_ALL=ja_JP I see Cyrillic displayed in Kochi Gothic (meaning ugly, square letters). I am also attaching two small screenshots to illustrate what I mean. So my question is, how do I make Pango "prefer" Arial over Kochi when my locale is ja_JP (short of specifying Arial explicitly, which works). I don't know if it is possible, but I just wanted to state my problem. -- /^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\ / Georgi Georgiev (-< / A pencil with no point needs no \ \ chutz@chubaka.net /\ .o)\ eraser. / / +81(90)6266-1163 V_/_ |(/)/ \ \___________________________/\__________________________________/ --HlL+5n6rz5pIUxbD Content-Type: image/png Content-Disposition: attachment; filename="bg_BG.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASkAAAAcCAAAAAAYMhb0AAAC2UlEQVR4nO1YPWsVQRQ9J0LA 4CchoCLa2QQbkYCViGBra6MIVhZ2/gNbi7RK7BRBQbDTfxCD6Q3YaCEBSVKkU8ix2Llz7+zb F+Yl4CMwh7A792vm7tkzs49QaKjCzLQbODKYAZmGZB52pl8xEOmDzBMwTFUmk6WHJLFzZ+5A vQ/3Md5/uFzXFCGBwcQECwIAlCZgHo1J6zmWv/yYcKWMbjkGayiJI9m9TFaMZtxU+RAjDzSy ODn4SgiNlncqI8BUlioF4MPtBZBYI0G+mb+xaZbpNAcBEt9uzs0ufuqKRdKmtEs3aXjVki3G 3CGNX8UAoLwdos8yJcluhu5RNRhNVUiMhIpYEt3FdKkuDz/jhQToASDg8Qrum+U5KSgBuvb6 7zoueGuCINmiKU2Q+eB39JtCqkR+Ethf8uXRREzBufVb4A+BrbwyBqYsSZvdkIDflwABW9tY MMtzUrDzrD29Csqe0pZVXD9cFBtw1oyDgpIY6JM4/ts3sLEiJQOQn04jWRw+OgXg/Z8nAPDq IQDg7GnsuGWI5vLSxkqWJZ2uJJssWXT7hiL7G425vXRQyLoUu6D7SoWMaKqQZ62mgm48Mmb3 BUnsXeZ3AVd+AQI2t3HOrD0cS+kpKAE6gd1dF4FJKZCfheSNmGk6ifIph954GXZNCRzUUaEA a23fj80+n71eTfpNcU9vAVw/DwB49hF3zdrCUspMQQDAKay/9GLjOz/RyOICUHqp7nNkvVB9 mfV97i9PtUJTZVKUmksuCM6GxSvvneE9aX3FooDVzvP85K1ts45f/JnyVr0XvJs/8ygvnU/v UkOFSrLpmbLtNTxH6etuJW0Tgzhc/QHmKzqmCFlZUUynNg2pWOvJlM/KoKjkK1wHA6GpM/Uf 0V/Xvl1VtQiH0pT6/3+Y1hs6emj/S6hFY6oWjalaNKZq0ZiqRWOqFo2pWjSmatGYqkVjqhaN qVo0pmrRmKrFPw6cTkdTqI2EAAAAAElFTkSuQmCC --HlL+5n6rz5pIUxbD Content-Type: image/png Content-Disposition: attachment; filename="ja_JP.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAATgAAAAcAQAAAADdTp5TAAABd0lEQVR4nO3Rv0sCURwA8EvD lsihpSByiVwLV+9uDP+B/oRGHYQkOLuiQaLBwSXRvKHRwaGhoU4Ho5KMm4LA6IRCqdDnD+R5 3vO+PU/Loij/AL88vjz4fnjfL+/LwGjBjOqkLCQEKAOs8DxRyLCimAeADFwUZoTezSXxBL64 mxRSIFyVCe6CiBiJB68AJQd13JyHvRQ/3IOFefQ1q/IRJg7TGRsCPCvUufPX0cqnk9aNQ5QJ FV92gve2ib6rOZXefPlctFKPS/PFenwtHJvaS5Qzr7qGt9SA+Z6N9rWDC7jpXOxJ53wnLZ1D WFax/GYtBM7wZt+RhlBbUpoucOdzsUonjZItmkIZGyOjIHVI5DB1UerofKbbj1S1tC92p6VR gFURi7oF7ywS09TtZklj0l5ytv1gWfZELvyL0uptc2HqgE0hVtWT3WN1O4jVwT7Kw38zzIyh 41cM/urUEM81XeF/OiLCL8GAYe0tqW3/Z79/l8du7L7FO3330tQ/Xb18AAAAAElFTkSuQmCC --HlL+5n6rz5pIUxbD-- From vivek@lantana.tenet.res.in Tue Jun 17 05:15:02 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 0299418653 for ; Tue, 17 Jun 2003 05:14:56 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5H9EEC02535; Tue, 17 Jun 2003 14:44:19 +0530 Subject: gtk+-2.2.1 compilation From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-Q1Eg8cjg6cVUshCdvynd" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 17 Jun 2003 15:45:16 +0530 Message-Id: <1055844921.801.99.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-Q1Eg8cjg6cVUshCdvynd Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all I compiled the gtk+-2.2.1 using the source. After the compilation, while starting gnome, it says the error, gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name what is this 'relocation error' ? what should I do for this ? with regards Vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-Q1Eg8cjg6cVUshCdvynd Content-Type: text/html; charset=utf-8 Hi all
I compiled the gtk+-2.2.1 using the source.
After the compilation, while starting gnome, it says the error,

gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name

what is this 'relocation error' ? what should I do for this ?

with regards
Vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-Q1Eg8cjg6cVUshCdvynd-- From klchxbec@yahoo.com Wed Jun 18 01:02:20 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from web13901.mail.yahoo.com (web13901.mail.yahoo.com [216.136.175.27]) by mail.gnome.org (Postfix) with SMTP id C46961823F for ; Wed, 18 Jun 2003 01:02:19 -0400 (EDT) Message-ID: <20030618050219.94343.qmail@web13901.mail.yahoo.com> Received: from [203.200.195.2] by web13901.mail.yahoo.com via HTTP; Tue, 17 Jun 2003 22:02:19 PDT Date: Tue, 17 Jun 2003 22:02:19 -0700 (PDT) From: klchxbec Subject: fix to pango GSUB To: gtk-i18n-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Here is a one-liner to fix pango's GSUB code for rendering kannada text. ftp://ftp.gtk.org/incoming/ftxgsub-bad.png ftp://ftp.gtk.org/incoming/ftxgsub-good.png Index: pango/opentype/ftxgsub.c =================================================================== RCS file: /cvs/gnome/pango/pango/opentype/ftxgsub.c,v retrieving revision 1.6 diff -u -r1.6 ftxgsub.c --- pango/opentype/ftxgsub.c 16 Apr 2003 03:58:17 -0000 1.6 +++ pango/opentype/ftxgsub.c 17 Jun 2003 12:26:01 -0000 @@ -3823,7 +3823,7 @@ /* we are starting for lookahead glyphs right after the last context glyph */ - curr_pos = j; + curr_pos += j; s_in = &in->string[curr_pos]; lc = ccsf3->LookaheadCoverage; __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From zenithlau@i-cable.com Wed Jun 18 11:12:43 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from virgo.i-cable.com (virgo.i-cable.com [203.83.111.75]) by mail.gnome.org (Postfix) with SMTP id 2AA1B180E4 for ; Wed, 18 Jun 2003 11:12:42 -0400 (EDT) Received: (qmail 8987 invoked by uid 706); 18 Jun 2003 15:12:36 -0000 Received: from cm61-10-38-94.hkcable.com.hk (HELO ?192.168.0.34?) (61.10.38.94) by 0 with SMTP; 18 Jun 2003 15:12:13 -0000 Subject: Font configuration issues. From: Zarick Lau Reply-To: zenithlau@i-cable.com To: gtk-i18n-list@gnome.org Content-Type: text/plain Organization: NixStyle.Net Message-Id: <1055949103.5609.8.camel@zlap> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 18 Jun 2003 23:11:43 +0800 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi list, I am using gtk 2.2.1 with Gnome 2.2, I found that if the selection of font is effectively determined by LC_CTYPE, why?? In my understanding, LC_CTYPE should only influence how a apps process the data from external. Though I am not sure.. Another important issues is, is it possible to configuration the system (fonts.conf right?) so that, when in non en locale, the system will still use en fonts to render the latin messages, while taking another fonts for other language? If it is only a configuration issues, would you mind show me a bit examples? Regards, Zarick Lau From Tony.Graham@Sun.COM Wed Jun 18 11:22:48 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.gnome.org (Postfix) with ESMTP id B3BEB180E4 for ; Wed, 18 Jun 2003 11:22:47 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5IFMkLv026967 for ; Wed, 18 Jun 2003 08:22:46 -0700 (PDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5IFMjg6025853 for ; Wed, 18 Jun 2003 16:22:45 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5IFP1i04287; Wed, 18 Jun 2003 16:25:01 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16112.33869.254511.67633@tenso.ireland.sun.com> Date: Wed, 18 Jun 2003 16:25:01 +0100 To: gtk-i18n-list@gnome.org Subject: PangoPDF 1.2.3.0 released X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: PangoPDF is a version of Pango with additional PDF/PostScript backends and support for additional XSL-related text attributes. This release updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and Xft backends to match Pango 1.2.3. Download PangoPDF from http://sourceforge.net/projects/pangopdf/. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From vivek@lantana.tenet.res.in Thu Jun 19 00:26:38 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 75EA4181CD for ; Thu, 19 Jun 2003 00:26:36 -0400 (EDT) Received: from swan.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5J4PkC11643; Thu, 19 Jun 2003 09:55:48 +0530 Subject: GTK+- runtime error From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-c3mWW04KSiClVd8B3bqY" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Jun 2003 10:06:33 +0530 Message-Id: <1055997396.1426.4.camel@swan.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-c3mWW04KSiClVd8B3bqY Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii all. I am compiling the GTK+ from the source. The version I am using is 2.0.6. Previously i went through the latest versions, but it needs the latest, xft, glib etc.. There also I got a problem of 'relocation error'. so, I thought to use the same version of GTK installed in Redhat 8.0. After that, while i start 'gedit' or 'gnome-session' anything, i got the following error. What i have to do to make the compilation successfully ? The program 'gedit' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 46 error_code 16 request_code 154 minor_code 20) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Or can anyone tell me, with 'which version of which', I can successfully compile the Pango and GTK from source? Thanking you, with regards Vivek. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-c3mWW04KSiClVd8B3bqY Content-Type: text/html; charset=utf-8 Hii all.

I am compiling the GTK+ from the source. The version I am using is 2.0.6.  Previously i went through the latest versions, but it needs the latest, xft, glib etc..  There also I got a problem of
'relocation error'. so, I thought to use the same version of GTK installed in Redhat 8.0.

After that, while i start 'gedit' or 'gnome-session' anything, i got the following error.  What i have to
do to make the compilation successfully ?

The program 'gedit' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 46 error_code 16 request_code 154 minor_code 20)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Or can anyone tell me, with 'which version of which', I can successfully compile the Pango and GTK from source?

Thanking you,
with regards
Vivek. 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-c3mWW04KSiClVd8B3bqY-- From ittay@qlusters.com Sun Jun 22 10:17:59 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from hirame.qlusters.com (adsl-139-109.barak.net.il [62.90.139.109]) by mail.gnome.org (Postfix) with ESMTP id 2FA62181E0 for ; Sun, 22 Jun 2003 10:17:58 -0400 (EDT) Received: from ittay ([10.100.0.13]) by hirame.qlusters (8.10.2/8.10.2) with ESMTP id h5MEFge26386 for ; Sun, 22 Jun 2003 17:15:42 +0300 Subject: how do i add windows-1255 encoding? From: Ittay Dror To: gtk-i18n-list@gnome.org In-Reply-To: <20030622133801.28246.23535.Mailman@moniker.gnome.org> References: <20030622133801.28246.23535.Mailman@moniker.gnome.org> Content-Type: text/plain Message-Id: <1056291353.18485.6.camel@ittay> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0-1mdk Date: 22 Jun 2003 17:15:53 +0300 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: i'm using the new evolution, and the only hebrew encoding i have is iso-8859-8. unfortunately, all the words are in reverse order. i thought adding windows-1255 encoding would solve this. how do i add it? thanx, ittay -- ======================================= Ittay Dror (ittay@qlusters.com) User Space, R&D Qlusters Inc. Tel: +972-3-6081956 Fax: +972-3-6081841 From Takao.Fujiwara@Sun.COM Fri Jun 20 10:49:28 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.gnome.org (Postfix) with ESMTP id E5DBA1843D for ; Fri, 20 Jun 2003 10:49:27 -0400 (EDT) Received: from udsylm-mail1.Japan.Sun.COM ([129.158.26.30]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5KEnQep002428 for ; Fri, 20 Jun 2003 08:49:27 -0600 (MDT) Received: from requiem (requiem [129.158.28.20]) by udsylm-mail1.Japan.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.1p1) with SMTP id h5KEnPY25373; Fri, 20 Jun 2003 23:49:26 +0900 (JST) Message-Id: <200306201449.h5KEnPY25373@udsylm-mail1.Japan.Sun.COM> Date: Fri, 20 Jun 2003 23:49:19 +0900 (JST) From: Takao Fujiwara - Tokyo S/W Center Reply-To: Takao Fujiwara - Tokyo S/W Center Subject: alias in pangox.alias To: gtk-i18n-list@gnome.org Cc: Takao.Fujiwara@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zu2WY8a+lt3tBgPe0y0esA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 sun4u sparc Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi experts, I have quality issues about Japanese fonts in Pango. When we choose small size fonts in GNOME2.0.2 (pango 1.0.5) + Solaris 9, The rendering in Japanese fonts are very ugly. I have one remedy to add some alias to pangox.alias. However I don't have an explicit answer that it is no problem for pango specification. I would like to ask you it. Do you have any ideas to add gothic and mincho as aliases to pangox.alias below? gothic normal normal normal normal \ "-ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0201.1976-0,\ -ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0212.1990-0,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-1,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-2,\ -adobe-helvetica-medium-r-normal--*-*-*-*-*-*-iso8859-1" mincho normal normal normal normal \ "-ricoh-hg mincho l-medium-r-normal--*-*-*-*-c-*-jisx0201.1976-0,\ -ricoh-hg mincho l-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0212.1990-0,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-1,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-2,\ -adobe-utopia-medium-r-normal--*-*-*-*-*-*-iso8859-1" This remedy can fix problems that characters are very ugly in small Japanese fonts when gtk applications(Mozilla, etc) choose any fonts beside sans, serif, and monospace. I think that the issue occurs because 'gothic' in jisx0208 does not have small point size but 'hg gothic b' in jisx0208 has small point size. % xlsfonts -fn '-sun-minchou-bold-r-normal--*-*-*-*-c-*-jisx0208.1983-0' -sun-gothic-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0 -sun-gothic-medium-r-normal--14-120-75-75-c-120-jisx0208.1983-0 <---- -sun-gothic-medium-r-normal--16-140-75-75-c-140-jisx0208.1983-0 -sun-gothic-medium-r-normal--18-160-75-75-c-160-jisx0208.1983-0 -sun-gothic-medium-r-normal--22-200-75-75-c-200-jisx0208.1983-0 -sun-gothic-medium-r-normal--26-240-75-75-c-240-jisx0208.1983-0 % xlsfonts -fn '-ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0' -ricoh-hg gothic b-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--0-0-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--10-100-72-72-c-100-jisx0208.1983-0 <---- -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-120-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--14-140-72-72-c-140-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--16-160-72-72-c-160-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--18-180-72-72-c-180-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--20-200-72-72-c-200-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--24-240-72-72-c-240-jisx0208.1983-0 Sans, serif, and monospace have similar problems. If sans has only sun-gothic as jisx0208 font, pango renders ugly glyph. But If sans has ricoh-hg gothic b as jisx0208 font, pago renders fine glyph. So when pango refers 'gothic', I would like to point 'hg gothic b' in jisx0208/0201 against 'gothic', and when pango refers 'mincho', I would like to point 'hg mincho l' in jisx0208/0201 against 'mincho'. pangox.alias in Solaris has distinct directory(/etc/pango/$locale/pangox.alias) by locale, so pangox.alias can be set in each locale. I think this remedy has a pretty pit, i.e. If set 'gothic bold normal normal normal' in pangox.alias, user can see duplicated 'Bold' fonts in gnome-font-properties. It is no problem in 'gothic normal normal normal normal' because gothic fonts originally have 'medium' style but not 'normal' style. I do not join this mail alias, so please mail to me directly. Thanks in advance, Sun Microsystems Software Engineer Tokyo Software Center Takao Fujiwara E-Mail: Takao.Fujiwara@Sun.COM Tel: +81-45-227-9287(direct)/Fax: +81-45-225-5295 From otaylor@redhat.com Mon Jun 23 06:20:33 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1CFD018848 for ; Mon, 23 Jun 2003 06:20:33 -0400 (EDT) Received: from vpn50-2.rdu.redhat.com (vpn50-2.rdu.redhat.com [172.16.50.2]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5NAJxK02035; Mon, 23 Jun 2003 06:19:59 -0400 Subject: Re: PangoPDF 1.2.3.0 released From: Owen Taylor To: Tony Graham Cc: gtk-i18n-list@gnome.org In-Reply-To: <16112.33869.254511.67633@tenso.ireland.sun.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> Content-Type: text/plain Organization: Message-Id: <1056363575.13947.45.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 23 Jun 2003 06:19:36 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > PangoPDF is a version of Pango with additional PDF/PostScript backends > and support for additional XSL-related text attributes. This release > updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and > Xft backends to match Pango 1.2.3. > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. I'm being incredibly lazy here, and really should go look at the code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps the real question is, what do you mean by "backend" here?) I can't really see how you'd replace the Pango backend libraries and/or the shapers and keep keep things working reasonably. Regards, Owen From maclas@gmx.de Mon Jun 23 07:24:44 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by mail.gnome.org (Postfix) with SMTP id 5398F183F0 for ; Mon, 23 Jun 2003 07:24:44 -0400 (EDT) Received: (qmail 27486 invoked by uid 0); 23 Jun 2003 11:24:42 -0000 Date: Mon, 23 Jun 2003 13:24:42 +0200 (MEST) From: Matthias Clasen To: Owen Taylor Cc: gtk-i18n-list@gnome.org MIME-Version: 1.0 References: <1056363575.13947.45.camel@localhost.localdomain> Subject: Re: PangoPDF 1.2.3.0 released X-Priority: 3 (Normal) X-Authenticated-Sender: #0014083743@gmx.net X-Authenticated-IP: [195.243.100.246] Message-ID: <15429.1056367482@www60.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > > PangoPDF is a version of Pango with additional PDF/PostScript backends > > and support for additional XSL-related text attributes. This release > > updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and > > Xft backends to match Pango 1.2.3. > > > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > I'm being incredibly lazy here, and really should go look at the > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > the real question is, what do you mean by "backend" here?) > > I can't really see how you'd replace the Pango backend libraries > and/or the shapers and keep keep things working reasonably. > >From the PangoPDF homepage: PangoPDF implements a version of the Pango (http://www.pango.org/) library with a PDF backend for creating PDF output. This library also implements several of the inline properties defined by XSL (http://www.w3.org/TR/xsl/) that are not currently implemented by Pango. PangoPDF is designed to be API-compatible with the corresponding Pango version. The version number of the PangoPDF library, therefore, reflects the version number of the Pango version upon which library is based. The current PangoPDF version is 1.2.0.1, since it is based upon Pango 1.2.0. The goal of this project is to make itself redundant by implementing PDF support and XSL support so well that the additions are incorporated into Pango itself. The PangoPDF library tracks the official Pango library so the PangoPDF library can incorporate non PDF-related improvements and API changes as they are incorporated into Pango. -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! From vivek@lantana.tenet.res.in Tue Jun 24 07:00:39 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 238F4181D4; Tue, 24 Jun 2003 07:00:36 -0400 (EDT) Received: from lantana.iitm.ernet.in (IDENT:DcG7BlZfrrIv1KNv03I8HUSr4W9KMQwn@lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h5OB0wC16387; Tue, 24 Jun 2003 16:30:58 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5OAwsC00995; Tue, 24 Jun 2003 16:28:55 +0530 Subject: Encoding other than UTF-8 ? From: Viveka Nathan K To: gtk-list@gnome.org Cc: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-e35IJaWRw9jjkFMGgWt7" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Jun 2003 16:30:58 +0530 Message-Id: <1056452459.6174.30.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-e35IJaWRw9jjkFMGgWt7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all.. How can I use the encoding other than UTF-8, in GNOME ? If I set the LOCALE to en_US.ISO-8859-1, it saves the file in UTF-8 format only. How can I change it ? Applications like 'gtk2edit' are having the options to store in different encodings, but in 'gedit', I couldnt do that. Is there any way to do that ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Phone - Mobile: 0-9444167493 Off:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-e35IJaWRw9jjkFMGgWt7 Content-Type: text/html; charset=utf-8 Hi all..
How can I use the encoding other than UTF-8, in GNOME ?
If I set the LOCALE to en_US.ISO-8859-1, it saves the file in UTF-8 format only.
How can I change it ?  Applications like 'gtk2edit' are having the options to store
in different encodings, but in  'gedit', I couldnt do that.

Is there any way to do that ? 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. 
Phone - Mobile: 0-9444167493 Off:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves 
- Swami Vivekananda
--=-e35IJaWRw9jjkFMGgWt7-- From Tony.Graham@Sun.COM Wed Jun 25 06:36:05 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.gnome.org (Postfix) with ESMTP id A477318237 for ; Wed, 25 Jun 2003 06:36:04 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PAa3vc007545 for ; Wed, 25 Jun 2003 04:36:03 -0600 (MDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PAa2g6012556 for ; Wed, 25 Jun 2003 11:36:02 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5PAcGo09573; Wed, 25 Jun 2003 11:38:16 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16121.31640.237024.593290@tenso.ireland.sun.com> Date: Wed, 25 Jun 2003 11:38:16 +0100 To: gtk-i18n-list@gnome.org Subject: Re: PangoPDF 1.2.3.0 released In-Reply-To: <1056363575.13947.45.camel@localhost.localdomain> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400: > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: ... > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > I'm being incredibly lazy here, and really should go look at the > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > the real question is, what do you mean by "backend" here?) PangoPDF includes all of the backends so PangoPDF can be used as a drop-in replacement for Pango. To use PangoPDF instead of Pango in an application, just edit the application's configure.in (or configure.ac) to prefix Pango's pkg-config package names with 'pangopdf-', then rerun autoconf and configure. That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF. The FT2/X/Xft backends in PangoPDF are really just vanilla Pango. I expect that PangoPDF will add support for the 'XSL' attributes (which are also CSS3 attributes) to the FT2 and Xft backends (as one person has done for FT2 in his version of PangoPDF), but I expect to first implement the 'XSL' attributes as (conditionally) part of the PangAttrType enumeration instead of registering them with pango_attr_type_register() because it's so much easier to work with attribute types as constants rather than variables. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From otaylor@redhat.com Wed Jun 25 11:22:11 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DD55918C6E for ; Wed, 25 Jun 2003 11:22:10 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5PFM5K27129; Wed, 25 Jun 2003 11:22:05 -0400 Subject: Re: PangoPDF 1.2.3.0 released From: Owen Taylor To: Tony Graham Cc: gtk-i18n-list@gnome.org In-Reply-To: <16121.31640.237024.593290@tenso.ireland.sun.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> <16121.31640.237024.593290@tenso.ireland.sun.com> Content-Type: text/plain Message-Id: <1056554525.14257.195.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 25 Jun 2003 11:22:05 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Wed, 2003-06-25 at 06:38, Tony Graham wrote: > Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400: > > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > ... > > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > > > I'm being incredibly lazy here, and really should go look at the > > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > > the real question is, what do you mean by "backend" here?) > > PangoPDF includes all of the backends so PangoPDF can be used as a > drop-in replacement for Pango. > > To use PangoPDF instead of Pango in an application, just edit the > application's configure.in (or configure.ac) to prefix Pango's > pkg-config package names with 'pangopdf-', then rerun autoconf and > configure. > > That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF. > > The FT2/X/Xft backends in PangoPDF are really just vanilla Pango. I > expect that PangoPDF will add support for the 'XSL' attributes (which > are also CSS3 attributes) to the FT2 and Xft backends (as one person > has done for FT2 in his version of PangoPDF), but I expect to first > implement the 'XSL' attributes as (conditionally) part of the > PangAttrType enumeration instead of registering them with > pango_attr_type_register() because it's so much easier to work with > attribute types as constants rather than variables. While it's fine to experiment with a fork of Pango, I'd really strongly encourage you to try to get API additions into the main Pango. Pango really isn't a big enough of a project to need two competing versions, and there are some definately potential problems with what you are doing. For example, if you modify libgnomeprint-2.2.1.2 as you describe then you'll link against *both* Pango and PangoPDF when you have an app that uses GTK+ and uses libgnomeprint. And the effects of that will be unpredicatable and probably bad. But why is pango_attr_type_register() so hard to use? I don't really understand the problem. Sure, it's a few more lines of code, but that doesn't quite seem worth maintaining a fork. Regards, Owen From Tony.Graham@Sun.COM Wed Jun 25 18:38:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.gnome.org (Postfix) with ESMTP id 3984118C60 for ; Wed, 25 Jun 2003 18:38:30 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PMcRvc013790 for ; Wed, 25 Jun 2003 16:38:28 -0600 (MDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PMcRg6025351 for ; Wed, 25 Jun 2003 23:38:27 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5PMefA10115; Wed, 25 Jun 2003 23:40:41 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16122.9449.263238.517090@tenso.ireland.sun.com> Date: Wed, 25 Jun 2003 23:40:41 +0100 To: gtk-i18n-list@gnome.org Subject: Re: PangoPDF 1.2.3.0 released In-Reply-To: <1056554525.14257.195.camel@poincare.devel.redhat.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> <16121.31640.237024.593290@tenso.ireland.sun.com> <1056554525.14257.195.camel@poincare.devel.redhat.com> X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Owen Taylor wrote at 25 Jun 2003 11:22:05 -0400: ... > While it's fine to experiment with a fork of Pango, I'd really > strongly encourage you to try to get API additions into the > main Pango. Pango really isn't a big enough of a project > to need two competing versions, and there are some definately > potential problems with what you are doing. I don't want to fork Pango, and, as Matthis Clasen posted, the goal of PangoPDF is to make itself obsolete. > For example, if you modify libgnomeprint-2.2.1.2 as you > describe then you'll link against *both* Pango and PangoPDF > when you have an app that uses GTK+ and uses libgnomeprint. > And the effects of that will be unpredicatable and probably > bad. I know that. I still don't have a good solution to the fact that PangoPDF's GNOME Print backend depends on GNOME Print which depends on Pango. The effect of that will be unpredictable and probably bad too. As such, I don't think that part's ready to come into the fold. > But why is pango_attr_type_register() so hard to use? I don't > really understand the problem. Sure, it's a few more lines of > code, but that doesn't quite seem worth maintaining a fork. That's not why I'm maintaining a fork. I talked about pango_attr_type_register() when explaining what I would do if I were to add extra attributes to the FT2 and Xft backends. I am interested in seeing the fruits of what you wrote about in the "Merging code between Xft and FT2 shapers" thread on April 14 since that would make it easier to add FreeType-using backends to Pango. I will submit some enhancement requests. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From stephan.hegel@gmx.de Fri Jun 27 08:28:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id 02E8B18100 for ; Fri, 27 Jun 2003 08:28:30 -0400 (EDT) Received: (qmail 12482 invoked by uid 65534); 27 Jun 2003 12:28:18 -0000 Received: from unknown (EHLO gmx.de) (61.155.125.80) by mail.gmx.net (mp023) with SMTP; 27 Jun 2003 14:28:18 +0200 Message-ID: <3EFC3811.2090705@gmx.de> Date: Fri, 27 Jun 2003 20:26:57 +0800 From: Stephan Hegel Reply-To: stephan.hegel@gmx.de Organization: Private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en, de, zh-CN MIME-Version: 1.0 To: gtk-i18n-list@gnome.org Subject: Unexpected font rendering with pango Content-Type: multipart/mixed; boundary="------------010503000008060104000107" Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------010503000008060104000107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Recently I have found an unusual behaviour in Chinese font rendering with Pango.Please have a look at the attached, little screenshots. The only difference between both is the setting of the locale before starting the application. The first one uses LC_ALL=en_US and the second one LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing antialiasing - fine on the second pix, but not o.k. in the first case. It somehow uses a different size of fonts in just one string ... Anyone out there who has an idea or a hint how to track this and/or to fix this ? The application used in this case is called "lingoteach" and available on freshmeat. However, I have noticed that stardict behaves in the same strange way ... Kind regards, Stephan. --------------010503000008060104000107 Content-Type: image/png; name="en_US.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="en_US.png" iVBORw0KGgoAAAANSUhEUgAAAT4AAAFSCAIAAADkbCRGAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wYbCS03x2AlcAAAIABJREFUeJzt3XtwHNWB LvDTM6PRzEiyZMmyJfAzloRjrXB4+0IuZHfByZoK2ZuLy+xWkVRgNxvX3RTEhhgbYuOX/MQG wiPs5W6y2Vs32aQCLBCyobzEBrN+CD9Hkq2HkY2MJVsaPSxpZrrnce4fx+kc9XS3uud95O9X Lld3z+nTZ1r9zTnd82jJ7/c3NDT4/X5CSENDAyGETQPkv4aGhk/8nbluRW5ILKhlZWWRSESW 5VgsRgiRJElRlGg0Go/HKaXqbCwWGx4evnLlyr333mur/MMPP8zKU0r12yFJ6nQkElGno9Go Oh2Px9Vpvh5+XUVRJlzO18/an1gnT5ZlddrhcOi2x+40vy2j5alM8+wuN5Ku52W0zzMxzTNa 7vF41OmioiJ12uv1sgmfz9fV1dXc3LxixYqMxsRWeRdrnKIoIyMjgUCAHdaU0kgkEovFWBXq rCzLn332WWdn5913322r/PLly0dHRwcGBvjY8NHiWYmu0Z+EX5fHR5ev0+gw4rfF12k3upmO aCaia7Sc31f59nyt7AejNhcWFqrTPp9PnVajW1hYePz48QMHDjz66KMZjQlffvr06YQQRVF6 enp0y/8puoFAoLOzU5bleDzefaG77UxbYOCyx+OZdf2cquuqfN6iaDQqy3JHR0d3dzcrv2bN mp6eHlZDaWmpOuF0Otk2qqurJUnq7u6ORCKDg4Nnz57lezCj3c0fInYPFz5mfBm+HqNe18oh yLN7aObqULbykmf30M/n52s3umpENdNqjAsKCk6fPt3R0cEO+6VLl8qy7HQ6KyoqKioqIpFI RUWF0+l0OBxut3vBggXl5eXNzc1qTJqONo0MjUqSVFZWSiTCetF4PC7LyuBQwOGQXAUFn3Z2 qeVZDO+7775oNOp0Ol977bXh4WHW8cZiMTWGV6Mbi8VYTz06OvrOu+8cPnTI4ZLmVJTQmNL7 Wdvs2bNr6m71FhfJshwKhcLhMCs/MDBwzz33lPrcL77yqiNyZf/7vxvo6w30X77Uc7H19OnW lpZFX/va4cOHw+Ewe8FQFIXv/YyiZbSLjcpYWW40bWVAnrnpjRs3rlu3Tl2+adOmZ555Jrn2 bN++nXCefPJJ6+vu3r37Bz/4QRaeb+rTmfgbuVwu3Wn+JZ4duuywp5QODQ21tLQcO3ZsqP/S 5YufXbr4mRIaGx4aiF5R9r918Jnn/rmpqUmNSUdn+69/8xuf2zNv7ry/+tpSSmgsFguH5Zde erGsKD7nuuo7/vIBPlayLIfD4YGBgXfeeWdwcPCb3/zmz372s1gsFo/H2f/hcDgUCv2poWy/ vPPuO0cOH76+0rdgdpXHUxgbHRwKha50+S8Sufamr7LQq0/J5XItWlj7/RV/F4vK+997699/ 86ueC+cDl3uj0YgkkVKv86677vr4448jkYgkSZIkUUqt9JxW/lRWltsd0KaLrUNn06ZNTz/9 NJt+5plntmzZsnbt2iQ2unr16h07drAzIrbkiSeesL76888///jjjyexXYsy0YtmDTtu1cNm 3rx5L7/8cmdn5+EDf+jv6fa5JU+BVOiSCpySUyIlbumhhx56/fXX1ZiEQ/Lo8BWnd+RKv+/g wf+65ZZbZFl+/vk9bge9/XrPrLmVX5g713+yRS3PtjUwMHDu3LkDBw6Mjo4+8MADb775pppe FsOr0WW56r7QffjQ4esrvX+95M8X33FTV2trz4VPhwZ6QmNy+HLbyKU6R+kMWZZZFCmllZWV gUsXfvC/vtvT/Wnfxc9cUtzjkrxO4ixwSBKhlHi9XrU8O6RSeWVNV1xTGUBm9PDavHkzpXTL li1PP/30li1bCCFqjLdu3UoIWbNmzdatW5966ilCyLZt29hDq1evZhNqT/vkk09SSnfu3Kku 3LVrF3to1apVbOK5554jhKxcuVLd+p49ewghfPdr8fnmW+SMrqHwy/m28dcvjKbZxSF22FdX V3d1dX39619fvnx5eXl5SUmJz+erqKjwer3qKnxMKsqmTZ1SNt0dnuHsjfQV/Ncbh3v7h+tK pNq5hTV1Nz/4j9uO+k/x5dkrRUFBQTweD4VCBw8elCTpgQceePvtt4PBYDweZ2Nml7olRVGO HT3qkMi8WdWL77h5+T+sPfKrnR/s/dwT8YVJOBQNR/r8s76wkI3UWfk777xz5qxZC2/57+wq 17lz58rLy+fPnz9z5szh4eGpU6eyzcTjcTZaZuN1dXekcqnDbkStXNXMB42NjVu2bGHpbWxs pJSuXbu2sbFxzZo127ZtY63dvn07pfSpp55ig2RKqZpe1c6dO5944onnnnuOUrpq1apVq1bt 3r2bFV65cuXu3btXrly5Z88eSinLKqX08ccff+GFFyiljz32WNLtN4qNURmj/Z+u5Tyjl2yn 06lO8wNmNYeSJLF12WF/8ODBffv2/fSnPzU51+VjMnvOrP+57MEPPtg71TM4t+RSYTklM0vk CJGqFv79M699fOTIsaNH+fKsX2WnmR6PR5Kk06dP+3y+b3zjG2+99dbIyMi4XldRFFmWP/vs vMcllXrd51pbDv9q18UzR0udMimKBynxxDwkPlxXN/+3/xGnlLLyZWVlgUDg8uXLwWDw2LFj haNdM6aVU/r1lpaWsbGxWCzGXiTUE13WPt1dmelpsbCDm/WuW7dubWxs3LZt2+rVq5966im1 s92+ffsPf/hDdsju2LGD9bTsITaxa9cu1tnu3r171apV6qN79uzZvXv3nj17Vq5cuWrVquef f37Pnj1siyzGL774ou7gOdMxs7LcSkTtlikoKFCn+ejykZYkyeFwsMOeUtp+qukLCxqio93K YO/+37199ow/pgSHB/ocJD7QerL+H156//331ZhEIpHrr5v5lbv/ovfwOzNKFK9HIoSEw2TB 0mWHP2k6cvggGyHz5dlsQUGBz+fzer1ut7u3t/fQoUOFhYVDQ0Os/NWGsi640FM4xU1jo0MX u8/+Ye/FMmdYksOlrnChh9AYkSm9obaWxY+VZy8PQ0ND+/fvn10U/Pb9t1ZVlL55YG+8+jb1 9ICVZ+ff/AmDyZ8kn89jjaS9J3/66ac19fDjN8bpdKplNNNkfOe2a9cu9WSYX52MH2arD/FH sCpXkUtlf1pZd8LoskEs+WNM5s2bd+TgRz9/bXfg4rkLn55xE6W40FHkdngKJLdLKnaThx56 aOfOnZqYTJ069UQgULRwyorH/4oQ8urz70kxx6lmPx8TvjwhxOv1TpkyxefzVVdXV1ZW9vf3 V1VV9fT0sJIuvnG33HxrkxwYDAWnDvZ6ol5STEudskSk0jKPPEYX3/NAb19fLBZTFIWVj8Vi AwMDBw4cqCunL617fPo939u7fdl0uXO0n4xU3Er+eIbAriqzMIseV6MBYWKuGCuHL//qblKh 0+nctGmTZokmrox6/K1du5aNvQkhO3bs0FwAc7lcjY2N6kK+Bt0mZaLHsyLTlxL56OruBBak WCzGDvvq6up9Ta1Lly7z+XxG57qamMhy+JWXX1pURoMh+uoL7xV6yoIh0nam7YYFX/KfahkL BjTl4/H42NhYUVHRtGnTZs2aNXXq1JKSkrNnzzY3N0+bNo3Fatxlqqqqqjmz5w53+cNjcpiE Q5QWehxlZYUPf+fu373Rctu3NzVuf1lRFPV8OhAI/P73v79hmmPVdx6svOsr5954xn+8yUFj 5aEOX8gz5cb/cerUKVbe4XAkXqbKxFv5RlI5B0ulV5lwuTqxceNGvgB/DG3YsIEVe/bZZ599 9lk2oa64fv16Mj7GDodDfc9p3bp1jY2NDoeDzf7oRz+ilLL/2SwbkBPjU74Jn4uRTPeW6arH aJCs5lC9rssOeyvnunxMFCXy8qsvTy+Q517nVWYsXvClRcP9fUq8teDMr+UC+hdfWfL2u+/y 5dXLVKWlpfX19dddd90NN9zw+uuvt7S01NTUsJYoiuIihDQ0NHzwwQfRaNTj8dbU3XKRyOHL baFo2BPzkBgNj9Hfvd3y1e82njjV0dbepg76o9Hom2++Oas48nfLHrxj+bL2t/7fsUMfReSg u8BVUuKpdne7w8cWPfydjz76yOFwsNcJkwFzKjG2e0XRSkSzcylly5Yt/Bu57FhhXatmeuPG jSyiLLr8EkLIhg0bWP1sgh1/GzZsUHPOzzqdzs2bNzudTlZ4/fr1bDk7gvlpk+eSimyeyFhh 9L4uP2B2uVwul4sd9pTSS22HKmtujV3+5PKZk6MDPcHBXmd0rOvTs2G5PxbdK9VveOONN9SY 9AV6Z011LJjiu/mev/7HLf/07jvv9SsXpt99m3z0V/GO38758pf/9m+WHzp8SC2vhrOkpKS0 tHTRokXr168/f/58XV2dGiJJkv50rsvW8RYX1960ZORSrdzXLCu94aijat6iJWteONna//r/ +Rnb6ZRSVt7pdFZNiV+8+PnP168PDV26eK69uNDhcDqKiz3LH1r8b788ULH0Cb68yRVmnpXe NV1xtRtjK+20si0Vu4yszrL3hNj//JK1a9euW7dOnWVH1ebNmxMrZAtZnZoBtjrLJvhH+WlN /59RVvZzJvDbMjpT4KPrcDhYDxSNRufNmxccG9v3by/+/H//2OuIlBRQVzxY6nUUul3Tp5f+ zd/+N3LnQ5s2bVIP+4qpU++546bpJZ4V619577e//8P+ffF4/PrrZi759mba+e4Xv3znqdbL hIsJyyebdbvdjzzySH9//+LFi9X3ddlO+1N0w+Gwem3aXT6zqnZh3fz5DV/8s76Bwa3P/d+z Zz9lV8BYAVb+xhtvnDl37tiMWZ6KiqKCgi8tKYpEImVlZZTSD6PeG1es9nq96sVu1iz+01T8 n83KJ6JSGTCnMvBOpWdOBV/npk2bWHQJIRs3bkz64rndFe1Gy+5Lod2TFP4SgJX6rVyD4I8x 3bapV4DZYV9dXb3llV8sXbr0odWvGp3r8jEpnzpj7l8u93l9//qLXxw9epSNh9s72kpKim+7 5aunWi9HlDhfnsXwwoULoVDokUceqa6uvuuuu0KhkBppFkMXIcTv9x87dqyjo+PcuXPss8cs YP/5n/vVvltt0JUrVyKRSF9fX0dHRzweb2tra21tVQsYld+/f397e/uFCxfC4bC6a+x+aNGI 3RjzMtHzG7EyUjBx7733sokPP/zQ1nZ5dl+e7I50jKLF/x2NPvZg1B7+b8QPaFOpn8evq9vr xuPx7u7uWCzGDvvi4uLu7u5XXnllwsOeldfESi3f3Nz8Lz83LO9yuT7++GO32z1jxoy2trbE +q/uiJMnT544cWJkZIR9zlE9Y2afpuBn2ftOdsv/8pe/7OnpGRwcDAaDursvlR7VqJ50Lbfb e9iNaCYGirl6vkbfrDKKh1G0jNblrwZnon6jddlbm5mOCV++q6srEolMmTKlu7tbt7ykfsm+ s71F90kCQB4a9x7A/NqFuWoHAFgkSVJne4v27buzHa05aQ0AWPHhvr1sYuKTeADIQ4gugJAQ XQAhIboAQkJ0AYRkNbo1dfXqP1urJNuwLEnieakrplg46U0n3YwcboWvIbna8v9YyrKr3xyy UlT9zEZNXf2En9+wUibnNI3Mfptt7VIAXvIDZvYqqL4W8r1Hig9pXqGtz6aID5J5w2w9C01h o02b1KaZ1n3WVtqszprsxuTab469MGlq0G1D4hPnt46Ol6fzjWoj6o5L7Cs0E+zvpPuQrQlb s+nZH+NrS8sT5Atb37rRKroFrLSZ/PEPN+FuTKX9Fhm1weiJZ6INorv6zSErY2bdHapOm7wi ah4yWcvob8P/XfmFbDYLf1HzTVh8FhYlPsfEg9tKPdabkd72J1auvnBoXkQgFTZ6XXMmf4zk HrJSPhO9bhLSu/UJa0v7k8303sNANxPS/OaQ9b7X4kO6BTJ05pNihamfDerWZjRWtLvTrLTB VnmLdbIht/oPZ63pkp5e12TsmtxDugXMZ1NptjqrWTjhOJk/HK0UTlyo2ZDdfZL4RKxXZatY eoc2Rn9K3SUZaoPoxn1fd37tQnxzaHLAUT5Zfbhv7yPffawz8Ut/unSHN6IfGUZjNtGfV17B Ts4cS9GdlDt6Uj4pVZ48uzxpxqSEzzADCAnRBRCSdsCs/nwGAOSzcdHN5s/PA0Aqxn1zCBcV AESBc10AIaXtM8z5QPTfkcbnYcA6G98cynOT4KNg+AgUWKftdUtLp+akHcCu7Wd//w8PD2Z5 i5AW46JbWjr1+Ccf56opKbpv6YO5bkIaZH//L7l/Gbp6EeEy1TXtk6bDuW4CJAnRBRASogsg JEQXQEiTPLq6v7RgUixxgnC/M6r7qPVNA6SRpY9kLLl/mTr9/m9/bWsDS+5fZneV9EritxSJ 8Y+bW3/rNS2Xbfk9TxJ2Ptu36h7O+a6GbJo4upoDYnIcH0a/ZqwuMYpo4i/RJr4uJP6acWIx 68GecG9Pgj8HJCHJATPrDZbcv4zvFjSzmvLqQ4kTmmKaAta3oov/FcIJf2CNWA6V5jfl+J8+ 1Ay2dYulMpxO3CGa/4nxnkx6o5BvbNxzSEMzTjMZtlkc0fGPJq6Sb4PDpH9B2m5oNWcr/B7g ixntnPzZY5BeyX/9IPE4MHpR1z1iLB5J1rdiIq9ue2G3GUZ7iWU19XpAUOn85lB2Do78ueiV yor581ICgnIQQthPMaeL7hksP2u3u7C4FVtYP2z+RpGmJPtn/svmiWXU5fwvg6cltzhxvcZN 3Otqkjbh+C2xgO5DJsWS24ou/lYARhPWH9VdoruKleUWaXY+vwd0XyX5MiTXgxTInHF3P8ja N4cyccnkvqUPCv19Xfar9llO2idNh9c+uwtDdxHl4NNUuNQJkLocRBe5BUjdJP8MM8BkhegC CEl7k85ctyd5Ql+jUgn9J4DskCRJ5yadkyMA4sL+B4swYAYQiXpXMEQXQEgOkuw3hwAgh9Dr AggJ0QUQUvq/OQQAWYBeF0BIiC6AkBBdACEhugBCQnQBhIToAggJ0QUQEqILICREF0BIiC6A kBBdACEhugBCQnQBhJTO24VBNigKCQZJWJbCYaIoRFFIJEqiERKNkXic0DihlFBKJIlIEpEc xOEgLidxFZACF3G7idtNPR7iKSQ+H3G7c/1kIHmIbt4LBqXhYXJlhIyOkrExq2uxAJM4iRES IYSE1EckvlhRESkuJlNKaGkp8fnS12jIOEQ3LwVDUiBABgbI8HBmNzQ2RsbGyKVLV/NcWkrK y2lFBfF5M7tdSBmim09GRqXeXnK5j8SiuWnA8DAZHpa6uojTRaZX0qoqUlKcm5bARBDdPBCL SRc+J59/TqI5SmyiWJT09Eg9PcTlItdfT2deT5zOXLcJxkF0c2psTDp3ngQCuW6HsWiUnD8v nT9PKiro3DmkqCjXDYKrEN0cGRuTOs9m/FQ2jQIBKRAgpaW0Zj4CnA8Q3ayLx6W2dtLXl+t2 JGV4WDp6jFRW0hvqiAMfCsglRDe7enqljo5cNyJlfX1SXx+trSXVVbluyrUL0c0eqaU1r09r bZI6OsjAAK3HrQlzA2OerAiHpUNHJlNurwoEpENHSDic63ZcixDdzBsdlY40EUXOdTsyQ5Gl I01kdDTX7bjmILoZFgxJx47nuhEZJx07ToKhictB+iC6mUSpdM3cFEby+wmluW7FNQTRzSDp TBuRkxknf2/F9ydckro01ynL0pm2dFYIpnCFOWP6A6m8efu9Fd//yas/Vqc1S5Kr0HwradDX RyorybSKtFUIxtDrZop0/nx6K7SbMT6rfER/8uqP+el0NY9J+7MGI+h1M2NoyMZ3a8djkdN0 uXzGrHeVmvTabQPPasjHxsjQECkrs74tSA6imxFSf0pv4SbmRJMl6+n9yas/VsNvMb26lVvf otQfoIhu5mHAnBlXriS3nnpay8+yzGR0oJtOyT53sAXRzYxQGj5gxDo6zciZJOQ2xQvFRpev kq8xHc8dJoQBc2Yk9TMXLKuaiGpGqib9LZ83i8V0r12nMlomJMnnDnYhupnhdCVxBBvFgx8/ a65X8ROJ/fOEm0i8Bqa7dXvjcycOqmzAgDkzvJ60VKMJoeZSk3oOTMbn1ihpSZwhJ/PGb5qe O5hDdDNjypQ0Vpbek9s0VqIvrc8djLgIIQ0NDbluxmRDp1VIFy+mWInuaJZ1vEbv36gTiYPn 5D5cmURHTfFpqqzAaUlmlJWRoqKkP5VBJhqp8u8SqSUTL2vpXujSbCXpFuorKsLnMbIDA+ZM oXPmpLK6ldyqdBOYkzeBU3zWYJ2LEOL3+zFmTr9pFaSyMvWfjzPvGDXvJ1nvRY3eJU4sYyP5 +O5BFqHXzSC64AZSWJjEipp3WTXXkBNL6n61wMom0tkhFxbSBTekrTaYiOT3+wkhDQ0Nne0t 82sXnu1ozXWTJpdgSPrkk1w3IhvorbfiTkVZ8OG+vY9897HO9hb0uhnm89Kbb8p1IzKO3nwT cptliG7mFRfT228j7mRGzgJwF9LbbyPFuKtYtiG6WeHx0MW3k4pJdwmnooIuvp148PGpHEB0 s4fWL6S1tbluRdrQ2lr8fnoO4SMZ2VVdRWdMF/ieQwzuOZQHEN2sczjoFxeQ2bMEu9Mfgzv9 5Q1EN0eKiuiiGwW4v64K99fNM4huThUV0fqF+XhXexXuap+v8M2hPOB00jmzyZzZZGRU6u0l l/ty/0MTTheZXkmrqkgJ3vXJU+h180lJMS2pIbU1JBiSAgEyMJDtk+HSUlJeTisq8PmK/Ifo 5iWfl/pmklkzCSEkGJSGh8mVETI6msq3CPUVFZHiYjKlhJaWEp8vzZVDJuGbQ3nP56M+H6mu vjqrKCQYJGFZCoeJohBFIZEoiUZINEbicULjhFJCKZEkIklEchCHg7icxFVAClzE7SZuN/V4 iKeQ+HzE7c7pE4OUoNcVjdvNIoeb6l3j8K46gJAQXQAhIboAQkJ0AYSE6AIICdEFEBKiCyAk RBdASIgugJAcBN8cAhAQel0AISG6AEJyEELYDRAAQCDodQGEhOgCCAnRBRASogsgJJ1fyZhf i7tRAOQjSZL++Z9eYNP6P3CDu+wC5JsP9+3lZzFgBhASogsgJEQXQEiILoCQ8M0hACFZ7XVr 6uqtF+P/t1ibxfrTi99oTV19TtoAkJw03/2gs70lyyumRU1dfW4bAGBXkt8cUjsozYR5x6Xp 2RK76MRHE9fiF6prGbVHd6Oa2qy0HCDfZO+eQ2rPpgmSeXfHr6UpqVmuW5XmUd3C/HIAUSR5 hZkd7uqsrUOfL5mYRrUPVB9K4ixUXZ1VmGJtAHlIgDv9pdgfarpZ9K4wOST/vq46zrQ72jTv 9IwqtNhVJg4HkmgDQP7LXq+rhkqTLutr2dqW7urJ1QaQh6xGV/dYTxyC8ksSV+ETpbui7rZM Nq07Yd5y3Q0hySCcyfZBSFwrhmvEZIsucgvXiMkWXYBrBKILICQX0fvmkOanNAAg3+hcYZYk KfvtAABbdKKLKz0AeUsdEeOeQwBCwmUqACEhugBCQnQBhIQblwAIAzcuARAPblwCMBkgugBC QnQBhIToAggJ0QUQktV7Dqk/WZ6JH2rDj7wB2GXjZ+X4nzJO71cU8IUHALtSGjBPeEsRwt0W RPfuIbr/m5QEAMZFCPH7/RbHzGzC5I4hutMmdw9J3ITFkgDXOBu9bmd7C/tnfiMv3RUtLrde EuAal9JPqCNRALmShjeHkh7NWl8RA2YADRu9ruZcV/cmIPxw2mT0a/EOJsnd6wTgWpCGG5do ppO4UYjJfUwwJgfQlZubdE7YMydREuCakpvoJncfbQBQ4TPMAEJCdAGEpD9gxo1LAPKczj2H cOMSgPyHG5cAiGTcjUsAQDi45xCAkNDrAggJ0QUQEm5cAiAM3LgEQDy4cQnAZIDoAggJ0QUQ EqILICREF0BIiC6AkKzecwgA8gp6XQAhIboAQsI3hwCEhF4XQEiILoCQEF0AISG6AEJCdAGE hOgCCAnRBRASogsgJNy4BEBIOtHFjUsA8h9uXAIgEty4BEBsiC6AkBBdACEhugBCwo1LAISB G5cAiAc3LgGYDBBdACEhugBCQnQBhIToAgjJanRr6upNZvNQTV19/jcSIGmTs9etqavvbG/p bG9BemGySjW6rHNTE2IyYVKen00Mm26d5hvFl59g0tP/SIYu3VCpIeGnTSSWN5kwaobFjVps EoCIbESXj4HRQJSNUc2jpVnXSrVGVZlAbmFysxHdtOC71sRHETYAi9J/mUrteJPu9xK75SSu NuFVACa3lHpdPlQWo6KukhhI/iHdFY02qpttDJhhcrMaXU0M+CAZFTZKjsm61vOfxBKAyUSA 93XRfwIkEiC6yC1AIgGiCwCJEF0AIeHGJQBCwo1LAISEG5cAiGTcjUsaGhpy2hgAsA2XqQCE hOgCCMlBCPH7/bluBgDYg14XQEiILoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiI LoCQ8M0hACGh1wUQEqILICR8cwhASOh1AYSE6AIICdEFEBKiCyAkRBdASIgugJAQXQAh6dz9 YH7twuy3I5EkSZTSrG0L93wAsejfLuxsR2uW26Gh3p0hCy3BvdFARBgwAwgJ3xwCEBJ6XQAh IboAQsI3hwCEZKnXramrr6mr52etrDLhkuSwxqSrNgBB6b85lLdq6urVN2D5aYBrjdVz3c72 Ft2OdMIOMLEAvySVLpTllq+Kn9DUzC9MYlsA+Sb5XtdKB6gu5yOkLulsb7HbhfKvIOblE2tO nAAQl43ostgkd9DzkUvshO1Wpa7Iwm/0IqKpGXGFySQH57p8hBK7ZXPWXzvs1gwgFnvv6+qe 8VqRuQvOhBsOmAcbGYbJJPle18ppp1pGdyJx+YQ9qq1zXfNNAwjNUnT5Y91o2mgVkwnz5VYa o1loUjNCC5NMRs51LXaMSVfLQxrh2uQiGfjmUIYME65jAAADGUlEQVTilEq1SDhMMvj6AYCQ EF0AIbkIIX6/XzNmzp/ffMmflgDkFZ3LVJIkZb8duvKnJQD5Rie6uKIDkP9wrgsgJEQXQEiI LoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiILoCQEF0AISG6AEJCdAGEhOgCCAnR BRASogsgJEQXQEiILoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiILoCQEF0AISG6 AEJCdAGEpL1JJ25FDSCEcdHFragBRDEuurgpNoAocK4LIKSrvW53d3ckEpFlORaLRSIRRVEI IcFgcGBg4MqVKw8//DB7lFJqUpdmvB2JRPjZaDTKz8bjcX5WU7OmKtYei49qthuLxUw2xJNl mZ91OMa9rmkanMqspg3mj6Zx1uJDEz5qLnO7gv9TZm4vWd+HEz7q8Xj42aKiIn7W6/Wq0z6f r6urq7m5ecWKFSZJvPfee9mjra2tV6OrKMrIyEggEGClFUWhlIbD4Y6Ojs7OzuXLl4+Ojg4M DGhSYX5ubCu6Gpo9oqlKQxNdzYbMo8s3Q7OVVKKbq3BmJ7rmj2p2eIZ2VD7sw8QGa2YLCwv5 WZ/Px8/y0S0sLDx+/PiBAwceffRRkyTefffd7NGTJ0+6CCENDQ2nT58OBAKdnZ2hUCgajSqK EovFZFlubm7u7u6ORqP9/f1nzpwJhULW223+J7T1aCqz1g+OXB0N2ZnN3FZy8sKUn92s5lE+ nImzfJIdDkdTU9OJEycURTFJovroqVOnrva6R44caWpqOnfuXDgcZqVZSi9cuDA6Ojo2NjY4 OBgMBjX9W9bCaWvnmtP0pSZHg0bm/sCZezTpXjdrhdO4bibqSbHmgoICi7PRaDQSiUSjUfMk qo8eOXLkanRPnjx54sSJkZERlvVYLBYMBgkhoVAoEol861vf6unpYem1/qzSmLfsHOvmDdac HZjPaqTyaLpk7hUhlR1lflaieQV3Op1GK2qY16OJkPWNprhd86rY+Zp5EtVHg8Gg5Pf7CSEN DQ2EEHWaTQDkuYaGhsx1sHnu/wPur6N3B7/qtwAAAABJRU5ErkJggg== --------------010503000008060104000107 Content-Type: image/png; name="zh_CN.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="zh_CN.png" iVBORw0KGgoAAAANSUhEUgAAAT0AAAFPCAIAAACwE44AAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wYbCSwoU3MZxAAAIABJREFUeJzt3Xt0HNWB JvBb3S31Q2/JsiXbAhvLwrEDJIEsLGQhOwNOxpyQ2Sw+ZuYc4MTMMMPZ2QOxIcaG2NiyZRsb G1geh4zzYjabTHICLBCy4XgSG8z4hY0fkrAlGcluIcmW1Hp3d3V39d0/rqe4ru6qru6uftzW 9zs+PvW4VXW7VF/dW9WPks6dOzcxMTE8PBwOhwkhlNJwOKwoiqIo/KgsyxcuXOjq6mpubk6q /J49eyYnJ30+HyvPSJJE4uHLRCIRdTgajcYtTymNuywvFArFXSercOx6+G3x67TZbHHL6A3r rZOfnolhnlXT+X2Vb6/XzH7Qq7PT6VSHPR6POux2u9UCn3zyyYEDB375y19mNCZ8+ZkzZxJC QqFQf3+/XnlHKBQaHh7u6uqSZTkajXp7vWfPnB32XXK5XA1zrq6bXedxl0QiEVmWOzs7vV4v K7927dr+/n722ioqKtQBu93ONlBfXy9JktfrDYfDIyMj586dk2U54b7mj49kjxU+Y3wZfj18 Gb316x1/vGSPy1wdx2bOd8ke9/n8epPNrZpPzbCa4aKiok8//bSzs5Md9suWLZNl2W6319TU 1NTUhMPhmpoau91us9mKi4sXLVpUXV3d2tqqxuTosaMTo5OSJFVWVhCJRCKRaDQajUZlOTQy OmyzSY6ios+6utXyLIZ33XVXJBKx2+2vvfba2NhYNBqllCqKwsfQoShKOByWZXlycvKdd985 fOiQzSFdXVNGldDAhbNXXXVVY9NN7tISWZYDgUAwGGTlfT7fHXfcUeEpfvGVV23h8f3v/8E3 ODA8dOlif1/7p5+2t7Xd8O1vHz58OBgMslNFKBTi2z29XOntX70yZqbrDeu159k5tjZt2rR+ /Xp1enNz89NPP51afbZv3044TzzxhPlld+3a9YMf/CALrzf94Uz8jRwOR9xh/vzODl122FNK R0dH29rajh8/Pjp08VLfhYt9F0KBqbFRX2Q8tP+tg08/99OjR4+qMens6vjt737nKXbNnzf/ r769jBKqKEowKL/00ouVJdGrZ9ff/Jf38LGSZTkYDPp8vnfeeWdkZOR73/vez3/+c0VRotEo +z8YDLLyDnWnvPPuO0cOH55T61l0VZ3L5VQmR0YDgfHu031EXvjVb7G4q6/H4XDcsHjh/3zk 75SIvP+9t/7v737T33t++NJAJBKWJFLhtt92220fffRROByWJEmSJEqpmTbTzN/JzPRk+7FW Seq4aW5ufuqpp9jw008/vWXLlnXr1qWw0TVr1jz77LOUUvXq4/HHHze/+PPPP//YY4+lsF2T MtF+Zg07btXDZv78+S+//HJXV9fhA38e6vd6iiVXkeR0SEV2yS6RsmLpvvvu27NnjxqTYECe HBu3uyfGhzwHD/77jTfeKMvy88/vLrbR/zTH1TCv9pp5806fbFPLs235fL6enp4DBw5MTk7e c889b775phpdNYYOFipvr/fwocNzat1/vfS/3nLzV7vb2/t7Pxv19Qem5OClsxMXm2wVs2RZ ZjmklNbW1g5f7P3B/3i43/vZYN8FhxR1OSS3ndiLbJJEKCVut1stz46ndM6pVmU1nX5jRo+t zZs3U0q3bNny1FNPbdmyhRCiZnjr1q2EkLVr127duvXJJ58khGzbto3NWrNmDRtQ29gnnniC Urpjxw514s6dO9ms1atXs4HnnnuOELJq1Sp167t37yaE8A2vydebb3nTu2/CT+frxt+z0BuO RCKKorDDvr6+vru7+zvf+c6KFSuqq6vLyso8Hk9NTY3b7VYX4WNSUzmjqrxyZnFwln0gPFj0 728cHhgaayqTFs5zNjZ97d5/2nbs9Cm+PDtNFBUVRaPRQCBw8OBBSZLuueeet99+2+/3R6NR 1lUOh8MOWZZDodDxY8dsEpnfUH/LzV9b8Q/rjvxmx5/2fu4Ke4IkGIgEw4OnG65ZzHrnrPyt t946t6Fh8Y3/JRQKTUxM9PT0VFdXL1iwYO7cuWNjY1VVVWwb0WiUdZJZH13dF+nc20g2n3r3 n3J+LtdoaWnZsmULi25LSwuldN26dS0tLWvXrt22bRur7fbt2ymlTz75JOsbU0rV6Kp27Njx +OOPP/fcc5TS1atXr169eteuXazwqlWrdu3atWrVqt27d1NKWVAppY899tgLL7xAKX300UdT rr9eZvTK6O1/q6bz9M7XdrtdHeb7yWoIJUliy7LD/uDBg/v27fvZz35mcH3Lx+Sqqxv++/J7 //SnvVWukXllF53VlMwtk8NEqlv890+/9tGRI8ePHePLsxaVXV26XC5Jkj799FOPx/Pd7373 rbfempiYYO1tNBp1hEIhWZYvXDjvckgV7uKe9rbDv9nZd+ZYhV0mJVE/JS7FRaJjTU0Lfv// opRSVr6ysnJ4ePjSpUt+v//48ePOye5ZM6op/U5bW9vU1JSiKOz0oF7cso3F3Y+ZHhYLO7JZ u7p169aWlpZt27atWbPmySefVJvZ7du3//CHP2TH67PPPsvaWDaLDezcuZM1s7t27Vq9erU6 d/fu3bt27dq9e/eqVatWr179/PPP7969m22RZfjFF1+M22fOdMbMTDeTz2TLFBUVqcN8bvk8 S5Jks9nYYU8p7Th19JpF10UmvaGRgf1/ePvcmdNKyD/mG7SRqK/95JJ/eOn9999XYxIOh+fM nvvN2/9i4PA7s8pCbpdECAkGyaJlyw9/fPTI4YOsY8yXZ6NFRUUej8ftdhcXFw8MDBw6dMjp dI6OjqrlHazldbqc5cVUmRzt8577896+SntQkoMVjqDTRahCZEqvXbiQZY+VZyeG0dHR/fv3 X1Xif/Dum+pqKt48sDda/3X1koCVZxfc/EWCwd8jn69d9Vjehj/11FOa9fDdNsZut6tlNMPk ymZt586d6gUwvzi5snetzuIPX1Wu8pbO/jSzbMLcsr4rIYQd9vPnzz9y8MPXX9s13NfT+9mZ YhIqddpKim2uIqnYIZUWk/vuu2/Hjh2amFRVVZ0YHi5ZXP7IY39FCHn1+fckxXaq9TQfE748 IcTtdpeXl3s8nvr6+tra2qGhobq6uv7+frW8g9Xsxq/ddFQeHgn4q0YGXBE3KaUVdlkiUkWl S56it9xxz8DgoKIooVCIlVcUxefzHThwoKmavrT+sZl3/OPe7ctnyl2TQ2Si5ibyH1cF7B4y S7LoWdXrB8aGijFz7PLndYMV2u325uZmzRRNVhn14Fu3bh3rchNCnn32Wc0dL4fD0dLSok7k 1xC3Splo68zI9L1DPrdxdwJLkaIo7LCvr6/fd7R92bLlHo9H7/pWExNZDr7y8ks3VFJ/gL76 wntOV6U/QM6eOXvtoq+cPtU25R/WlI9Go1NTUyUlJTNmzGhoaKiqqiorKzt37lxra+uMGTPU WF2+L1VXV3f1VfPGuk8Hp+QgCQYodbpslZXO+79/+x/eaPv6g80t218OhULqBfTw8PAf//jH a2fYVn//3trbvtnzxtOnPzlqo0p1oNMTcJVf/99OnTrFyttsttj7Upl4v15POtdd6bQnCaer A5s2beIL8AfQxo0bWbFnnnnmmWeeYQPqghs2bCBXZthms6lvL61fv76lpcVms7HRH/3oR5RS 9j8bZf1won+Zl/C16Ml0O2nVevT6xmoI1bu47LA3c33LxyQUCr/86sszi+R5s92hWbcs+soN Y0ODoWh70ZnfykX0L7659O133+XLq/elKioqlixZMnv27GuvvXbPnj1tbW2NjY2sJqy8g118 ulzuxqYb+4gcvHQ2EAm6FBdRaHCK/uHttm893HLiVOfZjrNqRz8Sibz55psNpeG/W37vzSuW d7z1f44f+jAs+4uLHGVlrvpib3Hw+A33f//DDz+02WzsDGHQT04nw8nePzSTz+zcO9myZQv/ hi07UFijqhnetGkTyyfLLT+FELJx40a2fjbADr6NGzeqIedH7Xb75s2b7XY7K7xhwwY2nR2+ /LDBa0lHNq9fzNB7/5bvJzscDofjckwopRfPHqptvEm59PGlMycnff3+kQF7ZKr7s3NBeUiJ 7JWWbHzjjTfUmAwODzRU2RaVe752x1//05Yfv/vOe0Oh3pm3f10+9pto5++v/sY3/vZvVhw6 fEgtryazrKysoqLihhtu2LBhw/nz55uamtQQsRg6IpEIW8BdWrrwq0snLi6UB1vl0EAwYqub f8PStS+cbB/a85Ofsz1OKWXl7XZ7XXm0r+/z1zdsCIxe7OvpKHXabHZbaalrxX23/OuvD9Qs e5wvb3A/mWemXbUqq8lm2Ew9zWxLxW4aq6Ps7R/2Pz9l3bp169evV0fZIbV58+bYFbKJbJ2a frU6ygb4ufywpuXPKDP7ORP4beldIPC5tdlsrPmJRCLz58/3T03t+9cXX//n/+W2hcuKqCPq r3DbnMWOmTMr/uZv/zO59b7m5mb1sK+pqrrj5q/OLHM9suGV937/xz/v3xeNRufMnrv0wc20 690vfePWU+2XCBcTFk42WlxcvHLlyqGhoVtuuUV9/1aNoSMSiQSDQfU2dHH13LqFi5sWLLju S18e9I1sfe5/nzv3GaVU/dQIK3/99dfPnTdvalaDq6ampKjoK0tLwuFwZWUlpfSDiPv6R9a4 3W71vjarE/95Kf5vZuYzT+n0k9Ppb6fTJqeDX2dzczPLLSFk06ZNKd8qT3bBZHOV7Hkw2WsT /rLfzPrN3Hfgj7G4dVPv37LDvr6+fssrv1q2bNl9a17Vu77lY1JdNWveX67wuD3/8qtfHTt2 jHWDOzrPlpWVfv3Gb51qvxQORfnyLIa9vb2BQGDlypX19fW33XZbIBBQ86zG0DE4ONjZ2dnT 08M+V8zS9W//tl9tstXajI+Ph8NhVj4ajZ49e7a9vV0toFd+//79HR0dvb29wWBQ3S96+dQb 1pNshnmZaPP1mOkjGLjzzjvZwAcffJDUdnnJnpuS7ePo5Yr/O+p9tkGvPvzfiO/HprN+Hr9s 3PY2Go16vV5FUdhhX1pa6vV6X3nllYSHfdxYqeVbW1t/8bpueYfD8dFHHxUXF8+aNevs2bNx 1+84efLkiRMnJiYm2Oen1Etk9pEJfpS9v5Rs+V//+tf9/f0jIyN+vz/h3ymdHGbiWjTZdiPZ fGaif5ir16v3fSm9bOjlSm9Z/t5vJtavtyx7FzPTMeHLd3d3h8Ph8vJyr9erV14ihHR1tMV9 hQCQhxqbllzueyxYuDi3VQGAhCRJYq3sF9cM5zrbc1cfAEjgg3171eHE1+4AkG+QWwDxILcA 4kFuAcSD3AKIJ3FuG5uWqP9MrjSpwrmSwutSF0yzcMqbTrkaOdwKv4bU1pb/x1L2xfnSViz1 gxmNTUsSfkjDTJmc01Qy+3VOapcCaKTST2bnP/UsyLcbac7SnJvNj6aJT5FxxZJ6FZrCeps2 WJtmOO6rNlNnddRgN6ZWf2PsrKRZQ9w6xL5wfutocjVMtbfqXottJTQD7I8Ud1ZSA0mNWrUv +LVZ8gL5wua3rrdI3AJm6kz+4w+XcDemU3+T9Oqg98IzUYcCkFw/Oe4Ug3OhZpbBUnp/GP6P yk9ko1n4cxpvwuSrMCn2NcYe2WbWY74a1tY/duXqWUNzBoE0mcqtMYO/RGqzzJTPRHubAmu3 nnBtlr/YTO899G8zxLL3gcy3uiZnxS2QoaudNFeY/hVg3LXpdRGT3Wlm6pBUeZPrZD1t9R+u VC2Ubntr0GVNbVbcAsaj6VRbHdVMTNg95o9FM4VjJ2o2lOw+iX0h5leVVDFrOzV6f8q4UzJU hwJw+fu3CxYuxveBCgMO8UL1wb69Kx9+lJ3XErS3cXs1oh8Wel010V9XXsFOzqgEuS3IvVyQ L0qVJ68uT6pRqPD5ZADxILcA4vmin8z/CgYA5LPLuc3mD8YDQJou5xZ3EQAEgutbAPFY8Pnk fCD67z/jQy+QlELIbQF82AsfcoKkfJHbioqqHNZjOmN38rO//8fGRrK8RbDK5dxWVFR98vFH ua1Kyu5adm+uq2CB7O//pXcvRyMvKNyXmqY+Pno411WA1CG3AOJBbgHEg9wCiKdgcxv3NxMM isUOEO4nQuPONb9pAGsleP926d3L1eH3f//bpFa99O7lyS5irRR+CZHo/yK5+bdYLblJy+95 ErPz2b5V93DOdzVkmVFuNUdDYRwcer9CrE7Ry2fsj8jGnhRif4U4tpj5VCfc2wXw54DUJN1P Zu3A0ruX8w2CZlRTXp0VO6Appilgfitx8b8hmPAX0ojpRGl+FI7/4UJNHztusXR60bE7RPM/ 0d+TKW8U8lAqn3PUdM8MemsmO3L83NhF8q1PmPIvPyebWM1FCr8H+GJ6Oyd/9hhYLpXcxh4E eqfzuIeLycPI/FYM5NVTKpKtht5eYkFNfz0gLmu+V5CdIyN/7nKls2D+nEdAXFZ+H8ign8wk 21CY3EpSDK4wNYmK+9voxiuMu7hVv9WuwsUqGOVWE7OE3bbYAnFnGRRLbStx8T/erzdgfm7c KXEXMTPdJM3O5/dA3Bt7fBmS6+4JZNTl5xVk7ftAmbhHcteye4X+/i37Hfosx+zjo4fXPbMT PXYRNTYtyernpXBjE8ASWc0tQgtgiYL9fDJAAUNuAcTzxXM0c12T1Al9U0ol9J8AskOSJO1z NAvj6BcX9j+Yh34ygBj4J3ghtwDiQW4BxIPcAogHuQUQD3ILIB7kFkA8yC2AeJBbAPEgtwDi QW4BxIPcAogHuQUQD3ILIB7kFkA8yC2AeKz83XPILEUhwSCRZSKHpHCIhCMkHCaKQhSFKFES VQglhFJCKCESkSQiEWKzE7uN2O3EbidFRaTIQYuKibOYOJ3E5SJ2e65fEqQIuc1jfj+ZmpIm p0ggQAIBEo2aXpISSgklJBolkStmSPyIzUbcbuJ209ISUlJCPB5rqg2Zh9zmmfEJaWyMjI8T vz/j24pGydQUmZqShoYuT/F4SHk5ragg5WUZ3zqkAbnNA9EoGRqSfCNkYiLHNfH7id8vDQwQ QkhZGa2uIjNmEBtuguQd5DanBgelS4PZaFpTMDEhTUyQ8xeIx0Nn1pLa2lxXCL6A3OaC3y/1 DxCfL9f1MMfvl3rOk57zpLqa1tfhMjgfILfZNToq9X5OAoFc1yMlPp/k8xG3m86dQyorc12b aQ25zZaxMen8BSLLua5H2gIBqbOLOJ306qtIRUWuazNNIbeZFwxK3T1kcjLX9bCULEsdnaS0 lM6fR1yuXNdm2kFuM0vy9hJ2e7YgTU5Kp1tJXR1tmJvrqkwvyG3GBINSZxcJBnNdj8wbGJBG R+nCRjS8WYO35jJjeFg63TotQssEg9LpVjI8nOt6TBdob60n9fWRz/tyXYsckD7rJrJMZ8/O dUUKH9pbi0le7/QM7WWf90leb64rUfiQWytJn/eRgYu5rkWuDVyUpvOZKyuQW+sMDZM+HK+E EEL6+sgQrnUzCLm1SDAodXfnuhJ5ROrunka35bIOubWG1HM+11XIO9gnmYPcWsHnS/8reA88 +FDCKVbNTa1k0iYmhPnuhGjwPpAFJIvuRT3w4EOv/+In6rBmikH5uNmLu6z5kpaQBi7S6upM rHmaQ27TNjVFpqYytG6TcdIUY+FUI82fC17/xU80cw22EjfkySWc7ZySkiQWAROQ23RJI6Pp r0STn9g4aZpEg7zFXTbusPn68NOTbZylkVGK3FoN17dps+iLPnohYf+IfhdXM/r6L34Suyp1 ipnIGZwUDLrlugrsi1D5AblNWyDddzs0seRjw4dQzYymZGx006yPtetJf/9ALOQ2bZFI4jKm aRpMNTx8es00nsmmji/PNqHX/htvNw5L9w8wuL7NMf5eEYl3M4mYyEncJjfhvWjz5WNPH5Bb yG3aHA4SCae8dMKoxMZJbfT0bkElTJfB/ecUqpqAA8eY9dBPTpvb4i+LaxpPvjW2RGrxS72l tXr/AEFuLVBamom1xm0S+VmpXGrGMHlGSGsrmdk/0xxymy5aZeUvksZNY+y7L7E3rsysllz5 3pLB20sWsnb/AINrj7SVlJCSEks+MmV8JynudayZD0LEvdel2a5xrUjKTS7bOWA1tLcWoHWz LFlPsqHlC+hlL6lPXMTSvFecLKv2DGigvbVCdTW5NGjhU7kShiT2XaLUbl8lfIMn7l1rs8rK CL5UkBlob61B512d5ho0UVTTqClm8Nau3iIJN5qwm51aW53+PgE9EiGkq6NtwcLF5zrbc10Z wQ0N4ycvVHT+fDKjJte1KCgf7Nu78uFHuzraGpuWoL21zowagp8gZWbPRmgzCrm1Ep0zm+BO TN0sOgfnr8xCbi1GGxrIdD5q58ymDQ25rkThw/1k69HZs4nTKX027a516TXzSQ26x9mA3GZG TQ0tKZkuz/UihLhceK5XNqGfnDEuF73uy6SuLtf1yLy6OnrdlxHabEJ7m1m0YS6pnVGAz61m 8NzqHEFuM8/lol9aRMbGpPMXiCznujYWcTrp1VeRiopc12OaQm6zpaKCXn8dGR2Vej8ngUCu a5MGt5vOnUMq8S2fXEJus6uyklZWEr9f6h8Q77f8q6tpfR3xeHJdD0Buc8LjoQuuIQuuIYOD 0qVB4vfnukKGPB46s5bU1ua6HvAF5DanamtpbS2JRsnQkOQbsfAbRRYoK6PVVWTGDGLDmw55 B7nNAzYbmTmTzpxJCCHjE9LYGBkfz00j7PGQ8nJaUUHKy3KwdTANuc0z5WVUzYzfT6ampMkp EgiQQIBEoxZvy2Yjbjdxu2lpCSkpwYWrQJDbPObxEI+HqheWikKCQSLLRA5J4RAJR0g4TBSF KApRoiSqEEoIpYRQQiQiSUQixGYndhux24ndToqKSJGDFhUTZzFxOonLRez2nL48SB1yKw67 Xf25JprrukBu4ZYDgHiQWwDxILcA4kFuAcSD3AKI54r7yQsWLs5VPQDAgCRJP/3xC+qo9n0g /BorQL75YN9ezRT0kwHEg9wCiAe5BRAPcgsgHuQWQDzILYB4kFsA8STObWPTEjMrYsX4/02u zeT6rcVvtLFpSU7qAJAyy75/29XRluUFLdHYtCS3FQBIQdL9ZLVp0gwYN1maNi22cY6dG7sU P1FdSq8+cTeqWZuZmgPkoWz83oXapmlSZNzQ8UtpSmqmx12VZm7cwvx0AIEk3d6yY10dTeq4 50vGRlFt/dRZKVx5qouzFaa5NoD8lNe/L5VmS6hpYNGuQsFI5X0gtXuZbCfTuLnTW6HJRjK2 I5BCHQCEkI32Vk2UJlrml0pqW3EXT21tAPlJIoR0dbQtWLj4XGc7+z/XVUodbjJBQfpg396V Dz/60x+/sPLhR1kLVDifl0JoYfoonNwitDB9FE5uAaYP5BZAPMgtgHiQWwDxaN+/jf3FRwDI N1fkVpKkXNUDAMy7Ird4KwUgb/F9YVzfAogHuQUQD3ILIB7kFkA8eI4mgADwHE0AweA5mgCF ALkFEA9yCyAe5BZAPMgtgHiQWwDxILcA4jH1HE3+UVpxC6S8efwKOUAKTP3uOf+IHWu/64dv DgKkIMV+csInXBLuKZVxH2YZ93+DkgCgMtXeqskxeIBl3GGDh1nGbsJkSQAw1d52dbSxf8ZP lI67oMnp5ksCQIrP9UKcAHIorfeBUu7Eml8Q/WSAWKlc38Z9JiXfizbo9Jp8oGZqj94EmCYS 5zZuCDWJjVvSfBkzJQFAlY3nVvMStskplASYbrKdW/MhRFwB9ODzyQDiQW4BxIPcAogHuQUQ D56jCSAePEcTQDx4jiaAGPAcTQCxIbcA4kFuAcSD3AKIB8/RBBAAnqMJIBg8RxOgECC3AOJB bgHEg9wCiAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEg9wCiAe5BRAPcgsgHuQWQDzI LYB4kFsA8SC3AOJBbgHEg9wCiAe5BRAPcgsgHjxHE0A8eI4mgHjwHE0AMeA5mgBiQ24BxIPc AogHuQUQD56jCSAAPEcTQDB4jiZAIUBuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHgS57axaYnB aB5qbFqS/5UESEehtbeNTUu6Otq6OtoQXShgqeeWNWtqPAwGDMrzo7FJi7tO443iK8QwHWg/ 5xhX3ESpCeGHDcSWNxjQq4bJjZqsEoCgTOWWz4Be/5N1TY1zpVnWzGr1VmUAoYWCZyq3luAb 1di5SBqAeVbel1Kb3JRbvNgGOYXbSzgFQMFLsb3lE2UyJ+oisWnkZ8VdUG+jcYONfjIUvMS5 1WSAT5FeYb3YGCxrPvwpTAEoMHn9/i1aToC48jq3CC1AXHmdWwCIC7kFEA9yCyAe5BZAPHiO JoB48BxNAPHgOZoAYsBzNAHEhtwCiAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEg9wC iAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEc8XvXSxYuDhX9eBJkkQpzdq28CsfIBzt 78Kd62zPST1U6o9xZKEm+BE8EBT6yQDiQW4BxIPcAogHuQUQD3ILIJ4EuW1sWtLYtIQfTbjG 2DJmljKDVcaqtQGIS/s+UN7inz2P59DDNJe4n9zV0Ra3CU3Y9MUW4Kek03iy0PKr4gc0a+Yn prAtgDyUSntrpulTp/P5Uad0dbQl23jypw/j8rFrjh0AEJqp3LLMpHbE83mLbX6TXZW6IEu+ 3hlEs2ZkFQpMVq9v+fzENsjGzJ84kl0zgHDMvg8U9yrXjMzdXiZcR8A41QgwFJhU2lszl5pq mbgDsdMTtqVJXd8abxpAdAlyyx/oesN6ixgMGE83UxnNRIM1I7FQeCy+vjXZJKa8Wh6iCNOW xbnNUJbSWS3iDYUHn08GEA9yCyAebT85f366JX9qApBvrsitJEm5qodG/tQEIA9dkVvcwgEQ Aq5vAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHiQWwDJ/2rfAAACqElEQVTxILcA4kFuAcSD3AKI B7kFEA9yCyAe5BZAPMgtgHiQWwDxILcA4kFuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHiQWwDx ILcA4kFuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHi+eI4mnhMNIIrLucVzogEEcjm3eGI1gEBw fQsgHsnr9YbDYVmWFUUJh8OhUIgQ4vf7fT7f+Pj4/fffz+ZSSo3WcmU3OxwO86ORSIQfjUaj /KhmzZpVsfqYnKvZrqIoBhviybLMj9psV5zONBVOZ1RTB+O5Fo6anJVwrrHM7Qr+T5m5vWR+ Hyac63K5+NGSkhJ+1O12q8Mej6e7u7u1tfWRRx4xSOKdd97J5ra3t4+PjztCodDExMTw8DAr GgqFKKXBYLCzs7Orq2vFihWTk5M+n08TCePr4aRyq6HZHZpVaWhyq9mQcW75ami2kk5uc5XM 7OTWeK5mh2doR+XDPoytsGbU6XTyox6Phx/lc+t0Oj/55JMDBw489NBDBkm8/fbb2dyTJ092 dXU5QqHQ8PBwV1dXIBCIRCKhUEhRFFmWW1tbvV5vJBIZGho6c+ZMIBAwX2njv19Sc9MZNX9k 5OpQyM5o5raSk7NSfjawmrl8MmNH+RjbbLajR4+eOHHCOInq3FOnTnm9XseRI0eOHj3a09MT DAZZURbR3t7eycnJqampkZERv9+vadmylsyk9qwxTStqcChoZO6vm7m5Kbe3WSts4bKZWE+a ay4qKjI5GolEwuFwJBIxTqI698iRI5OTk46TJ0+eOHFiYmKCpVxRFL/fTwgJBALhcPiBBx7o 7+9n0TX/kiwMW3YOdOMKay4KjEc10plrlcydDtLZUcYXI5rTt91u11tQw3g9mvyY32ia2zVe FbtMM06iOtfv94fD4f8PcKaec5T2mGIAAAAASUVORK5CYII= --------------010503000008060104000107-- From morwen@evilmagic.org Fri Jun 27 09:32:54 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by mail.gnome.org (Postfix) with ESMTP id 28C28183AD for ; Fri, 27 Jun 2003 09:32:54 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030627133252.SDSC21249.mta01-svc.ntlworld.com@ganymede.arrow>; Fri, 27 Jun 2003 14:32:52 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganymede.arrow (8.11.2/8.11.2) with ESMTP id h5RDWb302018; Fri, 27 Jun 2003 14:32:37 +0100 Subject: Re: Unexpected font rendering with pango From: Abigail Brady To: stephan.hegel@gmx.de Cc: gtk-i18n-list@gnome.org In-Reply-To: <3EFC3811.2090705@gmx.de> References: <3EFC3811.2090705@gmx.de> Content-Type: text/plain Organization: Message-Id: <1056720756.1971.3.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 27 Jun 2003 14:32:37 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 13:26, Stephan Hegel wrote: > Recently I have found an unusual behaviour in Chinese font rendering > with Pango.Please have a look at the attached, little screenshots. The > only difference between both is the setting of the locale before starting > the application. The first one uses LC_ALL=en_US and the second one > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing > antialiasing - fine on the second pix, but not o.k. in the first > case. It somehow uses a different size of fonts in just one string ... > > Anyone out there who has an idea or a hint how to track this and/or to > fix this ? It's doing this because of the preference order of the fonts. With en_US its picking up a japanese or korean font first, and using that to display any characters it has support for - and only then moving to the chinese font. When in the chinese locale, it knows to use chinese fonts first... So you'll need to fiddle with the config files. -- Abi From pablo@mandrakesoft.com Fri Jun 27 11:45:11 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chanae.alphanet.ch (212-100-178-141.adsl.easynet.be [212.100.178.141]) by mail.gnome.org (Postfix) with ESMTP id 0033418587 for ; Fri, 27 Jun 2003 11:45:10 -0400 (EDT) Received: (from srtxg@localhost) by chanae.alphanet.ch (8.9.0/8.9.0) id RAA19301 for gtk-i18n-list@gnome.org; Fri, 27 Jun 2003 17:52:27 +0200 Date: Fri, 27 Jun 2003 17:52:27 +0200 From: Pablo Saratxaga To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango Message-ID: <20030627155227.GA19166@chanae.alphanet.ch> Mail-Followup-To: Pablo Saratxaga , gtk-i18n-list@gnome.org References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <1056720756.1971.3.camel@ganymede.arrow> User-Agent: Mutt/1.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kaixo! On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote: > > Recently I have found an unusual behaviour in Chinese font rendering > > with Pango.Please have a look at the attached, little screenshots. The > > only difference between both is the setting of the locale before starti= ng > > the application. The first one uses LC_ALL=3Den_US and the second one > > LC_ALL=3Dzh_CN.GB2312. The font rendering is - despite the missing > > antialiasing - fine on the second pix, but not o.k. in the first > > case. It somehow uses a different size of fonts in just one string ... > >=20 > > Anyone out there who has an idea or a hint how to track this and/or to > > fix this ? >=20 > It's doing this because of the preference order of the fonts. With > en_US its picking up a japanese or korean font first, and using that to > display any characters it has support for - and only then moving to the > chinese font. When in the chinese locale, it knows to use chinese fonts > first... So you'll need to fiddle with the config files. The problem is that it is using a *non scalable* font at a *wrong size*. Imho pango (well, Xft actually I think) should first look at scalable fonts, and only if no scalable fonts are found ressort to non scalable ones, if that is already doable trough a config option, then I would be interested to know what option it is, in order to enable that by default. It is simply too bad that a single text get in mixed sizes, just because the first matching font is used, without checking it has the character=20 at the right size. Such an output is acceptable if the only other alternative would be to display an empty square, but that is not the case here. Even worst: the first character of the paragraphe is a traditional chinese one, and taken from a traditional chinese font; imho in such case=20 pango should continue with the same font as long as possible, instead of switching to the default one for the next (for every?) character (that behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it makes sense to stick when the same font as long as possible; that is, if a given character was not on the default font, nor in the first CJK font ('ja' or 'ko' covering one in this case), and was on another CJK font, then it should stick with that one, as it is likely that other characters w= ill be in the same case. Following that ordering will give a much better output in all cases of normal CJK text. But if that is too complex to do, pango must at least give priority to scalable fonts, having a word with some letters near 3 or 4 times the size of some others is horrendous. --=20 Ki =E7a vos v=E5ye b=E9n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portugue= se] --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/GhQpSX1mtm4VGYRAn2cAJ9pNE4F7/8K768x4noZ3dem7uyISQCaA8L/ DmDwmnCOlRzB/aZ2XfJNljA= =Fddk -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From otaylor@redhat.com Fri Jun 27 15:16:57 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 03D6618389 for ; Fri, 27 Jun 2003 15:16:57 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5RJGqK30609; Fri, 27 Jun 2003 15:16:52 -0400 Subject: Re: Unexpected font rendering with pango From: Owen Taylor To: Pablo Saratxaga Cc: gtk-i18n-list@gnome.org In-Reply-To: <20030627155227.GA19166@chanae.alphanet.ch> References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> <20030627155227.GA19166@chanae.alphanet.ch> Content-Type: text/plain Message-Id: <1056741412.6045.10.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 27 Jun 2003 15:16:52 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 11:52, Pablo Saratxaga wrote: > Kaixo! > > On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote: > > > > Recently I have found an unusual behaviour in Chinese font rendering > > > with Pango.Please have a look at the attached, little screenshots. The > > > only difference between both is the setting of the locale before starting > > > the application. The first one uses LC_ALL=en_US and the second one > > > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing > > > antialiasing - fine on the second pix, but not o.k. in the first > > > case. It somehow uses a different size of fonts in just one string ... > > > > > > Anyone out there who has an idea or a hint how to track this and/or to > > > fix this ? > > > > It's doing this because of the preference order of the fonts. With > > en_US its picking up a japanese or korean font first, and using that to > > display any characters it has support for - and only then moving to the > > chinese font. When in the chinese locale, it knows to use chinese fonts > > first... So you'll need to fiddle with the config files. > > The problem is that it is using a *non scalable* font at a *wrong size*. > Imho pango (well, Xft actually I think) should first look at scalable fonts, > and only if no scalable fonts are found ressort to non scalable ones, > if that is already doable trough a config option, then I would be interested > to know what option it is, in order to enable that by default. I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd have to have a very exotic configuration (basically, no scalable CJK fonts) to get those results with fontconfig/Xft. > It is simply too bad that a single text get in mixed sizes, just because > the first matching font is used, without checking it has the character > at the right size. Such an output is acceptable if the only other > alternative would be to display an empty square, but that is not the case > here. > > Even worst: the first character of the paragraphe is a traditional chinese > one, and taken from a traditional chinese font; imho in such case > pango should continue with the same font as long as possible, instead of > switching to the default one for the next (for every?) character (that > behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it > makes sense to stick when the same font as long as possible; that is, > if a given character was not on the default font, nor in the first CJK > font ('ja' or 'ko' covering one in this case), and was on another CJK font, > then it should stick with that one, as it is likely that other characters will > be in the same case. Following that ordering will give a much better > output in all cases of normal CJK text. Unfortunately, you can't autodetect traditional vs. modern Chinese, so I don't think we'll ever be able to do much better than supplied language tag for that situation... if you have a section of text that has only shared characters, it's going to get one or the other font arbitrarily. For other languages, there is possibility of improvement - see http://bugzilla.gnome.org/show_bug.cgi?id=112503. For Stephan, there is a easy solution ... since the app knows the language of the text it is displaying, it can explicitely set the language tag, and override the language tag of the locale. Regards, Owen From pablo@mandrakesoft.com Fri Jun 27 16:26:23 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chanae.alphanet.ch (212-100-178-141.adsl.easynet.be [212.100.178.141]) by mail.gnome.org (Postfix) with ESMTP id 4DE3118FA5 for ; Fri, 27 Jun 2003 16:26:22 -0400 (EDT) Received: (from srtxg@localhost) by chanae.alphanet.ch (8.9.0/8.9.0) id WAA25904 for gtk-i18n-list@gnome.org; Fri, 27 Jun 2003 22:33:40 +0200 Date: Fri, 27 Jun 2003 22:33:40 +0200 From: Pablo Saratxaga To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango Message-ID: <20030627203340.GB24947@chanae.alphanet.ch> Mail-Followup-To: Pablo Saratxaga , gtk-i18n-list@gnome.org References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> <20030627155227.GA19166@chanae.alphanet.ch> <1056741412.6045.10.camel@poincare.devel.redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline In-Reply-To: <1056741412.6045.10.camel@poincare.devel.redhat.com> User-Agent: Mutt/1.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kaixo! On Fri, Jun 27, 2003 at 03:16:31PM -0400, Owen Taylor wrote: > I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd probably. > > one, and taken from a traditional chinese font; imho in such case=20 > > pango should continue with the same font as long as possible, instead of > > switching to the default one for the next (for every?) character (that > Unfortunately, you can't autodetect traditional vs. modern Chinese, so I idn't mean that. I meant, if a char "X" is searched in first font, and not found there then found in the second font; then, when displaying the second char "Y", first look at the last used font (the second) instead of looking again at the first, then second. If the search was done like that for CJK (only for CJK, as for latin, greek, and cyrillic it won't be desirable) then a text will be properly displayed in most cases; at worst only the few chars at the begining of the text will be in a different style; not a mixed style in all the document. In the particular case shown in the examples, it would have given a correct display, that is the same display that in the chinese locale.=20 Is such behaviour doable ? It would be a big improvement imho. --=20 Ki =E7a vos v=E5ye b=E9n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portugue= se] --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/Ko5pSX1mtm4VGYRAmidAJ0bHr8/eIYufQ5aPFZtdDws0y1UMgCfai21 3/EbR70DpOnbrXuDYMi+JNo= =8BqY -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From keithp@keithp.com Fri Jun 27 17:21:51 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from localhost (unknown [63.227.221.253]) by mail.gnome.org (Postfix) with ESMTP id 11A0318FDA for ; Fri, 27 Jun 2003 17:21:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=keithp.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19W0ex-0001aT-00; Fri, 27 Jun 2003 14:21:31 -0700 X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev To: Pablo Saratxaga Cc: gtk-i18n-list@gnome.org, Keith Packard Subject: Re: Unexpected font rendering with pango From: Keith Packard In-reply-to: Your message of "Fri, 27 Jun 2003 22:33:40 +0200." <20030627203340.GB24947@chanae.alphanet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 14:21:29 -0700 Message-Id: Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Around 22 o'clock on Jun 27, Pablo Saratxaga wrote: > I meant, if a char "X" is searched in first font, and not found there > then found in the second font; then, when displaying the second char "Y", > first look at the last used font (the second) instead of looking again > at the first, then second. And if the characters are in the opposite order, you'll still get 'ransom note' typography. A particular counter example is a document which is largely in English but which happens to start with a Japanese glyph. With a 'sticky font' mechanism, the whole document will be rendered with a Japanese font. The current mechanism is also designed to be 'stable' so that the glyphs selected for any particular character don't change as the document is edited; this makes layout significantly easier. The correct solution is to inform the font system what languages are in use so that appropriate fonts can be selected. -keith From keithp@keithp.com Fri Jun 27 18:03:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from localhost (unknown [63.227.221.253]) by mail.gnome.org (Postfix) with ESMTP id 0D5F318FDB for ; Fri, 27 Jun 2003 18:03:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=keithp.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19W1Iu-0001bw-00; Fri, 27 Jun 2003 15:02:48 -0700 X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev To: Eric Mader Cc: Keith Packard , Pablo Saratxaga , gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango From: Keith Packard In-reply-to: Your message of "Fri, 27 Jun 2003 14:37:26 PDT." <3EFCB916.1050702@bigfoot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 15:02:48 -0700 Message-Id: Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Around 14 o'clock on Jun 27, Eric Mader wrote: > It might also make sense to take the language into account too; possibly > with a notion of what characters are used to write a given language in a > given script. I haven't thought about that enough to say for sure. That's precisely what fontconfig does. It calculates language coverage based on Unicode coverage of language orthography. It's a relatively straightforward technique aside from the collection of language orthographies; fontconfig is still missing orthographies for 17 of the 139 languages in ISO 639-1. > Another point: for complex text like Arabic and Hindi, you really, > really want to try and keep it all in the same font, because that's the > only way to get the correct contextual behavior. Arabic is not horribly problematic as most fonts provide coverage for most languages. One issue for Arabic is that newer fonts are less likely to include the presentation forms and are starting to expect shapers to perform compositing. That may require some additional information for font matching. I've seen significantly more trouble with languages presented in Latin or Cyrillic scripts where the lack of a language tag often results in uncommon glyphs being presented in an unexpected font. If an application wants to ensure that a complete document is presented in a single font, it can pass the set of Unicode values from the document to the font selection mechanism and request a single font covering those values. Language tags simply provide a convenient shorthand for this mechanism. -keith From stephan.hegel@gmx.de Sat Jun 28 20:24:45 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id DF74418926 for ; Sat, 28 Jun 2003 20:24:44 -0400 (EDT) Received: (qmail 18026 invoked by uid 65534); 29 Jun 2003 00:24:42 -0000 Received: from unknown (EHLO gmx.de) (61.155.124.129) by mail.gmx.net (mp027) with SMTP; 29 Jun 2003 02:24:42 +0200 Message-ID: <3EFE316D.9080609@gmx.de> Date: Sun, 29 Jun 2003 08:23:09 +0800 From: Stephan Hegel Reply-To: stephan.hegel@gmx.de Organization: Private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en, de, zh-CN MIME-Version: 1.0 To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango References: <20030628160014.14571.48469.Mailman@moniker.gnome.org> In-Reply-To: <20030628160014.14571.48469.Mailman@moniker.gnome.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi all, Thanks for the quick replies. Here just a few more notes on the issue. 1. The mentioned application lingoteach is not my work, I have just downloaded it from freshmeat since I'm looking for a vocabulary trainer what is able to display Simplified Chinese chars. However, I will have deeper look into it to figure out how it is done, but it looks like the apps uses only gtk_set_label calls. 2. A language tag as proposed by Owen is certainly a good solution to display a consistent, nice looking layout. However the mentioned application allows to add new languages and one doesn't know in advance what the user want to add. 3. I do use fontconfig/Xft. At least pango is telling me that when I configure it. checking for fontconfig >= 1.0.1... yes checking FONTCONFIG_CFLAGS... -I/usr/local/include checking FONTCONFIG_LIBS... -L/usr/local/lib -lfontconfig checking for freetype-config... /usr/bin/freetype-config checking for FT_Get_Next_Char in -lfreetype... yes checking for xft >= 2.0.0... yes checking XFT_CFLAGS... -I/usr/local/include -I/usr/include/freetype2 -I/usr/X11R6/include checking XFT_LIBS... -L/usr/local/lib -L/usr/X11R6/lib -lXft -lfreetype -lz -lXrender -lfontconfig ... configuration: backends: FreeType X Xft The shared libraries are all available, finally: libpango, libpangoft2, libpangox, and libpangoxft. 4. Beside Arial Unicode MS, there are other TTF Simplified Chinese fonts available on the system like MsSong, MsHei, SimHei, etc. xlsfonts and fc-list reports them all. I would like to find out what font is really selected by what backend in this application. Is there a simple log/trace/track mechanism available in Pango (kind of environment variable or whatever) which can be easily activated ? Thanks & regards, Stephan. From morwen@evilmagic.org Sun Jun 29 05:39:25 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by mail.gnome.org (Postfix) with ESMTP id 7119018655 for ; Sun, 29 Jun 2003 05:39:25 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030629093925.XPQR18592.mta07-svc.ntlworld.com@ganymede.arrow> for ; Sun, 29 Jun 2003 10:39:25 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganymede.arrow (8.11.2/8.11.2) with ESMTP id h5T9d4f01372 for ; Sun, 29 Jun 2003 10:39:05 +0100 Subject: Re: Unexpected font rendering with pango From: Abigail Brady To: gtk-i18n-list@gnome.org In-Reply-To: <3EFE316D.9080609@gmx.de> References: <20030628160014.14571.48469.Mailman@moniker.gnome.org> <3EFE316D.9080609@gmx.de> Content-Type: text/plain Organization: Message-Id: <1056879544.1119.2.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Jun 2003 10:39:04 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Sun, 2003-06-29 at 01:23, Stephan Hegel wrote: > 3. I do use fontconfig/Xft. At least pango is telling me that when > I configure it. > > checking for fontconfig >= 1.0.1... yes > checking FONTCONFIG_CFLAGS... -I/usr/local/include > checking FONTCONFIG_LIBS... -L/usr/local/lib -lfontconfig > checking for freetype-config... /usr/bin/freetype-config > checking for FT_Get_Next_Char in -lfreetype... yes > checking for xft >= 2.0.0... yes > checking XFT_CFLAGS... -I/usr/local/include -I/usr/include/freetype2 > -I/usr/X11R6/include > checking XFT_LIBS... -L/usr/local/lib -L/usr/X11R6/lib -lXft -lfreetype > -lz -lXrender -lfontconfig > ... > configuration: > backends: FreeType X Xft > > The shared libraries are all available, finally: > libpango, libpangoft2, libpangox, and libpangoxft. All this is telling you is that Xft was built, not that you are using it. Have you set GDK_USE_XFT? -- Abi From emader@bigfoot.com Fri Jun 27 17:37:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mail.gnome.org (Postfix) with ESMTP id AECFD1810B for ; Fri, 27 Jun 2003 17:37:29 -0400 (EDT) Received: (qmail 31091 invoked from network); 27 Jun 2003 21:37:28 -0000 Received: from unknown (HELO bigfoot.com) (emader@[66.93.135.240]) (envelope-sender ) by mail9.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Jun 2003 21:37:28 -0000 Message-ID: <3EFCB916.1050702@bigfoot.com> Date: Fri, 27 Jun 2003 14:37:26 -0700 From: Eric Mader User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Packard Cc: Pablo Saratxaga , gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: You can make the font 'sticky' only for that script. In general, it seems to be a good idea to try and display all characters in a given script in the same font. It might also make sense to take the language into account too; possibly with a notion of what characters are used to write a given language in a given script. I haven't thought about that enough to say for sure.. Another point: for complex text like Arabic and Hindi, you really, really want to try and keep it all in the same font, because that's the only way to get the correct contextual behavior. Regards, Eric Mader IBM GCoC - San José 5600 Cottle Rd. M/S 50-2/B11 San Jose, CA 95193 Keith Packard wrote: > Around 22 o'clock on Jun 27, Pablo Saratxaga wrote: > > >>I meant, if a char "X" is searched in first font, and not found there >>then found in the second font; then, when displaying the second char "Y", >>first look at the last used font (the second) instead of looking again >>at the first, then second. > > > And if the characters are in the opposite order, you'll still get 'ransom > note' typography. > > A particular counter example is a document which is largely in English but > which happens to start with a Japanese glyph. With a 'sticky font' > mechanism, the whole document will be rendered with a Japanese font. > > The current mechanism is also designed to be 'stable' so that the glyphs > selected for any particular character don't change as the document is > edited; this makes layout significantly easier. > > The correct solution is to inform the font system what languages are in use > so that appropriate fonts can be selected. > > -keith > > > _______________________________________________ > gtk-i18n-list mailing list > gtk-i18n-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-i18n-list > > From otaylor@redhat.com Sun Jun 29 11:55:41 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DFF921835F for ; Sun, 29 Jun 2003 11:55:40 -0400 (EDT) Received: from vpn50-32.rdu.redhat.com (vpn50-32.rdu.redhat.com [172.16.50.32]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5TFtaK03645; Sun, 29 Jun 2003 11:55:36 -0400 Subject: Re: Unexpected font rendering with pango From: Owen Taylor To: Eric Mader Cc: Keith Packard , Pablo Saratxaga , gtk-i18n-list@gnome.org, morwen@evilmagic.org In-Reply-To: <3EFCB916.1050702@bigfoot.com> References: <3EFCB916.1050702@bigfoot.com> Content-Type: text/plain Organization: Message-Id: <1056902111.15837.55.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 29 Jun 2003 11:55:12 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 17:37, Eric Mader wrote: > You can make the font 'sticky' only for that script. In general, it > seems to be a good idea to try and display all characters in a given > script in the same font. It might also make sense to take the language > into account too; possibly with a notion of what characters are used to > write a given language in a given script. I haven't thought about that > enough to say for sure.. This is basically what http://bugzilla.gnome.org/show_bug.cgi?id=112503 is about. Once we have script run information for shaper selection, we need to push it into the font selection algorithm in some fashion, for one thing, because shapers are only fed runs of glyphs in the same font. (The other thing that needs dealing with is dealing omitting non-rendering characters such as ZWJ from font selection to avoid having them break runs... fonts shouldn't have to claim to cover these languages) The language is already taken into consideration by fontconfig - it orders fonts returned by how well they match the language tag, and I think that will automatically carry over into any future script-run based system ... as long as we select fonts in the order that fontconfig returns them, we'll get the best font for the current language. I used to worry about font selection algorithms where subsequent characters could affect previous characters, figuring that would seem confusing while editing, but I've stopped worrying about that. For one, thing, it only matters if the font you have selected doesn't itself include all the characters in the language you are typing. It certainly doesn't make layout harder in any fundamental way since Pango never lays out less than a paragraph at a time. There *is* some question in my mind whether script-range font selection should apply to anything other than COMMON/INHERITED characters. - Pro: it's the only way that ransom-note effects will be reduced for wrong-tagged text for CJK or Roman where fonts commonly don't cover the entire script range. - Con: it can actually make things worse because it means that a single foreign name might throw an entire paragraph of text into a different font. In fact, I think the Con: here wins ... yes, script-run consideration for font selection is important, but no it shouldn't be used to fix problems like the one that started this thread. Regards, Owen [ Abi - since you asked for suggestions of things to work on, I think 91542/112503 is the most serious problem that Pango has at the moment. Assignment of ZWJ/ZWNJ to the wrong shaper has serious consequences for the correct rendering of Farsi and Indic languages. And, I think it's also likely fairly *interesting* to work on, which is definitely an added bonus ] From otaylor@redhat.com Sun Jun 29 12:24:22 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D5F71183EA; Sun, 29 Jun 2003 12:24:21 -0400 (EDT) Received: from vpn50-32.rdu.redhat.com (vpn50-32.rdu.redhat.com [172.16.50.32]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5TGOLK05478; Sun, 29 Jun 2003 12:24:21 -0400 Subject: [admin] List rules and FAQs added to www.gtk.org From: Owen Taylor Reply-To: gtk-list@gnome.org To: gtk-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-doc-list@gnome.org, gtk-i18n-list@gnome.org, gtk-devel-list@gnome.org Content-Type: text/plain Organization: Message-Id: <1056903836.15837.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 29 Jun 2003 12:23:56 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: I just added a short "List Rules and FAQs" section to http://www.gtk.org/mailinglists.html. Nothing there should be that surprising to current list members, but it wouldn't hurt to take a quick look. If you have any comments or suggestions for additional material which would be useful there, please let me know. Regards, Owen From jshin@mailaps.org Sun Jun 29 13:08:08 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from atlas.jtan.com (atlas.jtan.com [207.106.84.159]) by mail.gnome.org (Postfix) with ESMTP id 8926318A29 for ; Sun, 29 Jun 2003 13:08:07 -0400 (EDT) Received: from callisto.jtan.com (root@callisto.jtan.com [207.106.84.134]) by atlas.jtan.com (8.12.8p1/8.12.8) with ESMTP id h5TH86uN000310 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 29 Jun 2003 13:08:07 -0400 (EDT) Received: from callisto.jtan.com (jshin@localhost [127.0.0.1]) by callisto.jtan.com (8.12.1/8.12.1) with ESMTP id h5TH84OW013528 for ; Sun, 29 Jun 2003 13:08:04 -0400 (EDT) Received: from localhost (jshin@localhost) by callisto.jtan.com (8.12.1/8.12.1/Submit) with ESMTP id h5TH834w013202 for ; Sun, 29 Jun 2003 13:08:04 -0400 (EDT) X-Authentication-Warning: callisto.jtan.com: jshin owned process doing -bs Date: Sun, 29 Jun 2003 13:08:03 -0400 (EDT) From: Jungshik Shin X-X-Sender: To: Subject: Re: Unexpected font rendering with pango In-Reply-To: <1056902111.15837.55.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On 29 Jun 2003, Owen Taylor wrote: > (The other thing that needs dealing with is dealing omitting > non-rendering characters such as ZWJ from font selection to > avoid having them break runs... fonts shouldn't have to claim to > cover these languages) You meant 'claim to cover these characters', didn't you? If that's what you meant, it may not be so clear-cut for some 'invisible' characters. For characters like 'invisible times' (sorry I forgot the code point, it's somewhere in U+206x? or can be easily found in 'Default_Ignorable' list at Unicode ftp site) and 'invisible apply a function to'(?), there's no question that they should be ignored. [1] It gets a bit murky for ZWJ and ZWNJ (or CGJ).Some opentype fonts have to claim to cover characters like ZWJ and ZWNJ because ZWJ and ZWNJ take part in glyph substitutions (via GSBU look-up) and their presence and absence affect the rendering result. [1] Some aggressive fonts have visible glyphs for truly invisible characters. In presence of those fonts, not taking 'truly invisible' characters into account in font selection is essential to prevent the visible glyph of 'invisible times' from one of those fonts from popping up in the middle of a text-run rendered with another font. Jungshik From vivek@lantana.tenet.res.in Tue Jun 3 01:40:39 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 8939618A4D for ; Tue, 3 Jun 2003 01:40:34 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h535df530262 for ; Tue, 3 Jun 2003 11:09:44 +0530 Subject: utf-8 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-huysmgQWAktM7Ldxz9Kk" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jun 2003 11:10:40 +0530 Message-Id: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-huysmgQWAktM7Ldxz9Kk Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi In Pango, the strings are stroed in the UTF-8 standard. But, while i read the characters as integer, it gives some negative values. For example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the case for all the characters. How can I get the exact UTF-8 value ? I get the above values in Pango-context.c and shape.c with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-huysmgQWAktM7Ldxz9Kk Content-Type: text/html; charset=utf-8 Hi
  In Pango, the strings are stroed in the UTF-8 standard.  But, while i read the characters as integer, it gives some negative values. For example,  -32 -92 -107 is stored there for Devanagari 'ka'. This is the case for all the characters. How can I get the exact UTF-8 value ?  

I get the above values in Pango-context.c and shape.c

with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-huysmgQWAktM7Ldxz9Kk-- From nlevitt@computer.cc.columbia.edu Tue Jun 3 01:48:16 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id 90CD518135 for ; Tue, 3 Jun 2003 01:48:16 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19N4eS-0005OJ-00; Tue, 03 Jun 2003 01:48:04 -0400 Date: Tue, 3 Jun 2003 01:48:04 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: utf-8 Message-ID: <20030603054804.GI20359@columbia.edu> References: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Use g_utf8_get_char_validated or g_utf8_get_char to get the unicode character. You are looking at the byte values, which are not generally useful. If you are sure you want the UTF-8 bytes, you might want to cast to guchar if you want the unsigned values. gtk-list or gtk-app-devel-list would be better for this type of question. Noah On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while i > read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the > case for all the characters. How can I get the exact UTF-8 value ? > > I get the above values in Pango-context.c and shape.c > > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda From vivek@lantana.tenet.res.in Tue Jun 3 02:18:40 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 76639183C4 for ; Tue, 3 Jun 2003 02:18:35 -0400 (EDT) Received: from lantana.iitm.ernet.in (lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h536J4C23735 for ; Tue, 3 Jun 2003 11:49:04 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h536Hl531438 for ; Tue, 3 Jun 2003 11:47:47 +0530 Subject: Re: utf-8 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-D2E9hJukNaaTHzX9XosU" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jun 2003 11:48:47 +0530 Message-Id: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-D2E9hJukNaaTHzX9XosU Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Naoh. I have one more doubt. If we give 8bit value in the input (gtk), whether it is converted to UTF-8, before it gets stored ? Can we store the 8-bit value as it is (instead of converting to UTF-8) in GTK applications ? with regards vivek On Tue, 2003-06-03 at 11:18, Noah Levitt wrote: Use g_utf8_get_char_validated or g_utf8_get_char to get the unicode character. You are looking at the byte values, which are not generally useful. If you are sure you want the UTF-8 bytes, you might want to cast to guchar if you want the unsigned values. gtk-list or gtk-app-devel-list would be better for this type of question. Noah On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while i > read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the > case for all the characters. How can I get the exact UTF-8 value ? > > I get the above values in Pango-context.c and shape.c > > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-D2E9hJukNaaTHzX9XosU Content-Type: text/html; charset=utf-8 Thanks Naoh.
   I have one more doubt.  If we give 8bit value in the input (gtk), whether it is converted to UTF-8, before it gets stored ? Can we store the 8-bit value as it is (instead of converting to UTF-8) in GTK applications ?

with regards
vivek

On Tue, 2003-06-03 at 11:18, Noah Levitt wrote: 
Use g_utf8_get_char_validated or g_utf8_get_char to get the
unicode character. You are looking at the byte values, which
are not generally useful.

If you are sure you want the UTF-8 bytes, you might want to
cast to guchar if you want the unsigned values.

gtk-list or gtk-app-devel-list would be better for this type
of question.

Noah

On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote:
> Hi
>   In Pango, the strings are stroed in the UTF-8 standard.  But, while i
> read the characters as integer, it gives some negative values. For
> example,  -32 -92 -107 is stored there for Devanagari 'ka'. This is the
> case for all the characters. How can I get the exact UTF-8 value ?   
> 
> I get the above values in Pango-context.c and shape.c
> 
> with regards
> vivek
> -- 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
> Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> All condemnation of others really condemns ourselves - Swami Vivekananda
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda

--=-D2E9hJukNaaTHzX9XosU-- From nlevitt@computer.cc.columbia.edu Tue Jun 3 02:52:52 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id C4FF318110 for ; Tue, 3 Jun 2003 02:52:52 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19N5XT-0006CR-00; Tue, 03 Jun 2003 02:44:55 -0400 Date: Tue, 3 Jun 2003 02:44:55 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: utf-8 Message-ID: <20030603064455.GA23823@columbia.edu> References: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: I don't understand the question at all. (8bit value? input? converted? stored? What do you mean by these?) Noah On Tue, Jun 03, 2003 at 11:48:47 +0530, Viveka Nathan K wrote: > Thanks Naoh. > I have one more doubt. If we give 8bit value in the input (gtk), > whether it is converted to UTF-8, before it gets stored ? Can we store > the 8-bit value as it is (instead of converting to UTF-8) in GTK > applications ? > > with regards > vivek > From morwen@evilmagic.org Tue Jun 3 12:14:12 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail1-gui.server.ntli.net (mail1-gui.server.ntli.net [194.168.222.13]) by mail.gnome.org (Postfix) with ESMTP id 2CA1818285 for ; Tue, 3 Jun 2003 12:14:12 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mail1-gui.server.ntli.net (Post.Office MTA v3.1 release PO203a ID# 0-33929U70000L2S50) with ESMTP id AAA12970; Tue, 3 Jun 2003 17:14:00 +0100 Subject: Re: utf-8 From: Abigail Brady To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org In-Reply-To: <1054618844.955.31.camel@dodo.lli.tenet.res.in> References: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Content-Type: text/plain Organization: Message-Id: <1054656653.17407.4.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 17:10:53 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Tue, 2003-06-03 at 06:40, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while > i read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is > the case for all the characters. How can I get the exact UTF-8 value > ? I don't see why this is a surprise at all to you - that IS the correct UTF-8 encoding for KA. (E0, A4, 95, treated as 8-bit twos complement is -32 -92 -107). Perhaps you misunderstand UTF-8 or C. What are you expecting to see? -- Abi From vantr@touchtunes.com Tue Jun 3 10:39:54 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.touchtunes.com (operator.touchtunes.com [207.96.182.163]) by mail.gnome.org (Postfix) with ESMTP id 7C8E7184F5; Tue, 3 Jun 2003 10:39:54 -0400 (EDT) Received: from touchtunes.com (vantr.touchtunes.com [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 59921159E4; Tue, 3 Jun 2003 10:11:04 -0400 (EDT) Message-ID: <3EDCA50F.7030008@touchtunes.com> Date: Tue, 03 Jun 2003 09:39:27 -0400 From: Tristan Van Berkom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "B. Souliotis" Cc: gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org, gtk-list-request@gnome.org Subject: Re: Making Signal For A Widget. References: <3EDC8E7E.4010901@beta-cae.gr> In-Reply-To: <3EDC8E7E.4010901@beta-cae.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: You might do well to note also that gtkwidget.c is like a HUB for all theese events. As input, you get your GdkEvents and as output, you have a bunch of basic signals that are "emmited" at the GtkWidget level and handlers are "implemented" by various subclasses. you should probably read this: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Event-Structures.html#GdkEventButton when a "clicked" signal is emitted (by the GtkButtonClass); the mouse button has already been "released". now wether you mean the "Left button", the "button down" or "button press" by "First" is an entirely different question. Hope this helps, -Tristan From vivek@lantana.tenet.res.in Thu Jun 5 01:52:53 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id AEBEE18237 for ; Thu, 5 Jun 2003 01:52:44 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h555pP531885 for ; Thu, 5 Jun 2003 11:21:30 +0530 Subject: compiling gtk program From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-rozlI9E79IeeDf+2jH1O" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Jun 2003 11:22:49 +0530 Message-Id: <1054792374.916.23.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-rozlI9E79IeeDf+2jH1O Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi.. I took the sample program given in GTK documentation (helloworld.c) and I compiled it. It gives the error as : : /usr/include/gtk-1.2/glib/gtypes.h:41: syntax error before "typedef" : : /usr/include/gtk-1.2/glib/garray.h:32: parse error before "G_BEGIN_DECLS" /usr/include/gtk-1.2/glib/garray.h:34: syntax error before "typedef" : : what is that 'G_BEGIN_DECLS' I went through that gtypes.h.. there it is like as follows. What should I do to compile the program ? : : #include G_BEGIN_DECLS /* Provide type definitions for commonly used types. typedef char gchar; typedef short gshort; : : -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-rozlI9E79IeeDf+2jH1O Content-Type: text/html; charset=utf-8 Hi..
  I took the sample program given in GTK documentation (helloworld.c) and I compiled it.
It gives the error as

:
:
/usr/include/gtk-1.2/glib/gtypes.h:41: syntax error before "typedef"
:
:
/usr/include/gtk-1.2/glib/garray.h:32: parse error before "G_BEGIN_DECLS"
/usr/include/gtk-1.2/glib/garray.h:34: syntax error before "typedef"
:
:

what is that 'G_BEGIN_DECLS'

I went through that gtypes.h.. there it is like as follows.  What should I do to compile the program ?

:
:
#include <glibconfig.h>

G_BEGIN_DECLS

/* Provide type definitions for commonly used types.
typedef char   gchar;
typedef short  gshort;
:
: 

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-rozlI9E79IeeDf+2jH1O-- From vivek@lantana.tenet.res.in Thu Jun 5 07:17:43 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 069B818130 for ; Thu, 5 Jun 2003 07:17:39 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h55BGS511062 for ; Thu, 5 Jun 2003 16:46:31 +0530 Subject: pango ? From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-KgCMtsNS3UFlBsYuXcN4" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Jun 2003 16:47:56 +0530 Message-Id: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-KgCMtsNS3UFlBsYuXcN4 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi.. I am going to create one application in GTK with pango. In the normal program, if it contains the English string in the following label, button = gtk_button_new_with_label ("Hai!"); It displayed correctly. If i replace the string with 'UTF-8' characters, it didn't display anything. What should I add to display the UTF-8 characters using pango? Thanking you with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-KgCMtsNS3UFlBsYuXcN4 Content-Type: text/html; charset=utf-8 Hi..
 
  I am going to create one application in GTK with pango. In the normal program, if it contains
the English string in the following label,
  button = gtk_button_new_with_label ("Hai!");
  It displayed correctly.

If i replace the string with 'UTF-8' characters, it didn't display anything.
What should I add to display the UTF-8 characters using pango?

Thanking you
with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-KgCMtsNS3UFlBsYuXcN4-- From nlevitt@computer.cc.columbia.edu Thu Jun 5 11:28:12 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id 0476E18216 for ; Thu, 5 Jun 2003 11:28:12 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19Nwel-0006kJ-00; Thu, 05 Jun 2003 11:27:59 -0400 Date: Thu, 5 Jun 2003 11:27:59 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: pango ? Message-ID: <20030605152759.GA25898@columbia.edu> References: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Either it wasn't valid UTF-8 or you don't have fonts with the characters you were trying to draw. Noah On Thu, Jun 05, 2003 at 16:47:56 +0530, Viveka Nathan K wrote: > Hi.. > > I am going to create one application in GTK with pango. In the normal > program, if it contains > the English string in the following label, > button = gtk_button_new_with_label ("Hai!"); > It displayed correctly. > > If i replace the string with 'UTF-8' characters, it didn't display > anything. > What should I add to display the UTF-8 characters using pango? > > Thanking you > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda From vivek@lantana.tenet.res.in Fri Jun 6 02:59:00 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 0603A18121 for ; Fri, 6 Jun 2003 02:58:58 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h566wjQ04641; Fri, 6 Jun 2003 12:28:47 +0530 Subject: gtk program compilation error. From: Viveka Nathan K To: gtk-i18n-list@gnome.org Cc: cyrille@chepelov.org, nlevitt@columbia.edu Content-Type: multipart/alternative; boundary="=-H3/KZLLR0Pn0k2xeOhCD" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jun 2003 12:28:47 +0530 Message-Id: <1054882734.913.7.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-H3/KZLLR0Pn0k2xeOhCD Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Noah and Cyrille.. Now I installed gtk+-2.0 and compiled my program. Now it says the error as /tmp/ccNUHBNN.o: In function `main': /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:62: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:65: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:74: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:81: undefined reference to `g_type_check_instance_cast' /tmp/ccNUHBNN.o:/home/smilax2/vivekanathan/gtk/helloworld.c:81: more undefined references to `g_type_check_instance_cast' follow collect2: ld returned 1 exit status Before this, it said errors on some header files as 'No such file or directory'. I copied those files in the location as it needed. Now I dont know what to do for the above problem. Can you help me ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-H3/KZLLR0Pn0k2xeOhCD Content-Type: text/html; charset=utf-8 Thanks Noah and Cyrille..

Now I installed gtk+-2.0 and compiled my program.
Now it says the error as

/tmp/ccNUHBNN.o: In function `main':
/home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:62: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:65: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:74: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:81: undefined reference to `g_type_check_instance_cast'
/tmp/ccNUHBNN.o:/home/smilax2/vivekanathan/gtk/helloworld.c:81: more undefined references to `g_type_check_instance_cast' follow
collect2: ld returned 1 exit status 
Before this, it said errors on some header files as 'No such file or directory'.
I copied those files in the location as it needed.  Now I dont know what to do
for the above problem.  Can you help me ?
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-H3/KZLLR0Pn0k2xeOhCD-- From cyrille@chepelov.org Fri Jun 6 04:26:44 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chepelov.net1.nerim.net (chepelov.net1.nerim.net [62.212.101.212]) by mail.gnome.org (Postfix) with ESMTP id 4FFEE18363 for ; Fri, 6 Jun 2003 04:26:44 -0400 (EDT) Received: from muscat-eth0.intra.chepelov.org ([2001:7a8:29d4:0:2a0:24ff:fea6:57a0] helo=muscat.intra.chepelov.org) by chepelov.net1.nerim.net with esmtp (Exim 3.35 #1 (Debian)) id 19OCaP-0005bp-00; Fri, 06 Jun 2003 10:28:33 +0200 Received: from cyrille by muscat.intra.chepelov.org with local (Exim 3.36 #1 (Debian)) id 19OCYP-0006tQ-00; Fri, 06 Jun 2003 10:26:29 +0200 Date: Fri, 6 Jun 2003 10:26:29 +0200 To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: gtk program compilation error. Message-ID: <20030606082629.GA26487@chepelov.org> Mail-Followup-To: Viveka Nathan K , gtk-i18n-list@gnome.org References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1054882734.913.7.camel@dodo.lli.tenet.res.in> X-Face: "99`N"mZV/:OLp[>#d3R;u.!ivtwAEpIQDL8rD#;L3Wm)~^)Uv=#;S!LZf1y8oRY7J#JR\Lr{*4Cn*32C89ln>0~5~tm--}j%hvhj+vtW> Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Le Fri, Jun 06, 2003, à 12:28:47PM +0530, Viveka Nathan K a écrit: > Thanks Noah and Cyrille.. > > Now I installed gtk+-2.0 and compiled my program. > Now it says the error as > > /tmp/ccNUHBNN.o: In function `main': > /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to > `g_type_check_instance_cast' What arguments did you give to ld ? did you pass `pkg-config --libs gtk+-2.0` ? > Before this, it said errors on some header files as 'No such file or directory'. > I copied those files in the location as it needed. Now I dont know what to do > for the above problem. Can you help me ? What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0` ? -- Cyrille -- From vivek@lantana.tenet.res.in Fri Jun 6 05:03:28 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 8E68D184D4 for ; Fri, 6 Jun 2003 05:03:25 -0400 (EDT) Received: from lantana.iitm.ernet.in (lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h56942C22089 for ; Fri, 6 Jun 2003 14:34:02 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h56931Q08465; Fri, 6 Jun 2003 14:33:01 +0530 Subject: Re: gtk program compilation error. From: Viveka Nathan K To: Cyrille Chepelov Cc: gtk-i18n-list@gnome.org In-Reply-To: <20030606082629.GA26487@chepelov.org> References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> <20030606082629.GA26487@chepelov.org> Content-Type: multipart/alternative; boundary="=-/KP8l3ifKKUoAc1WvTY5" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jun 2003 14:33:04 +0530 Message-Id: <1054890184.939.13.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-/KP8l3ifKKUoAc1WvTY5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Cyrille.. Its working now. I compiled the source previously as gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags`=20 `gtk-config --libs` now, as I did as you told. Its going on and working properly :) Thank you once again On Fri, 2003-06-06 at 13:56, Cyrille Chepelov wrote: Le Fri, Jun 06, 2003, =E0 12:28:47PM +0530, Viveka Nathan K a =E9crit: > Thanks Noah and Cyrille.. >=20 > Now I installed gtk+-2.0 and compiled my program. > Now it says the error as >=20 > /tmp/ccNUHBNN.o: In function `main': > /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined referenc= e to > `g_type_check_instance_cast' =20 What arguments did you give to ld ? =20 did you pass `pkg-config --libs gtk+-2.0` ? =20 =20 > Before this, it said errors on some header files as 'No such file or= directory'. > I copied those files in the location as it needed. Now I dont know = what to do > for the above problem. Can you help me ? =20 What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0`= ? =20 -- Cyrille =20 --=20 =20 --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D=20 Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D All condemnation of others really condemns ourselves - Swami Vivekananda --=-/KP8l3ifKKUoAc1WvTY5 Content-Type: text/html; charset=utf-8 Thanks Cyrille.. Its working now.

I compiled the source previously as
gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags`  `gtk-config --libs`

now, as I did as you told. Its going on and working properly :)
Thank you once again

On Fri, 2003-06-06 at 13:56, Cyrille Chepelov wrote: 
Le Fri, Jun 06, 2003, à 12:28:47PM +0530, Viveka Nathan K a écrit:
>    Thanks Noah and Cyrille..
> 
>    Now I installed gtk+-2.0 and compiled my program.
>    Now it says the error as
> 
>    /tmp/ccNUHBNN.o: In function `main':
>    /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to
>    `g_type_check_instance_cast'

What arguments did you give to ld ?

did you pass `pkg-config --libs gtk+-2.0` ?


>  Before this, it said errors on some header files as 'No such file or directory'.
>  I copied those files in the location as it needed.  Now I dont know what to do
>  for the above problem.  Can you help me ?

What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0` ?

	-- Cyrille

-- 

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-/KP8l3ifKKUoAc1WvTY5-- From cyrille@chepelov.org Fri Jun 6 05:48:33 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chepelov.net1.nerim.net (chepelov.net1.nerim.net [62.212.101.212]) by mail.gnome.org (Postfix) with ESMTP id BB4A3184D4 for ; Fri, 6 Jun 2003 05:48:32 -0400 (EDT) Received: from muscat-eth0.intra.chepelov.org ([2001:7a8:29d4:0:2a0:24ff:fea6:57a0] helo=muscat.intra.chepelov.org) by chepelov.net1.nerim.net with esmtp (Exim 3.35 #1 (Debian)) id 19ODre-0005qM-00; Fri, 06 Jun 2003 11:50:26 +0200 Received: from cyrille by muscat.intra.chepelov.org with local (Exim 3.36 #1 (Debian)) id 19ODpd-0006hx-00; Fri, 06 Jun 2003 11:48:21 +0200 Date: Fri, 6 Jun 2003 11:48:21 +0200 To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: gtk program compilation error. Message-ID: <20030606094821.GA25745@chepelov.org> Mail-Followup-To: Viveka Nathan K , gtk-i18n-list@gnome.org References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> <20030606082629.GA26487@chepelov.org> <1054890184.939.13.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1054890184.939.13.camel@dodo.lli.tenet.res.in> X-Face: "99`N"mZV/:OLp[>#d3R;u.!ivtwAEpIQDL8rD#;L3Wm)~^)Uv=#;S!LZf1y8oRY7J#JR\Lr{*4Cn*32C89ln>0~5~tm--}j%hvhj+vtW> Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Le Fri, Jun 06, 2003, à 02:33:04PM +0530, Viveka Nathan K a écrit: > I compiled the source previously as > gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags` `gtk-config > --libs` Oh, I see. No wonder you had gtk 1.2 files coming in; gtk-config is for the 1.2 versions. Happy to know it's working now. -- Cyrille -- From otaylor@redhat.com Mon Jun 9 01:04:55 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 037D218169; Mon, 9 Jun 2003 01:04:54 -0400 (EDT) Received: from vpn50-35.rdu.redhat.com (vpn50-35.rdu.redhat.com [172.16.50.35]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5954sK32431; Mon, 9 Jun 2003 01:04:54 -0400 Subject: Pango-1.2.3 released From: Owen Taylor To: gnome-announce-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org Content-Type: text/plain Organization: Message-Id: <1055135072.1665.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 09 Jun 2003 01:04:32 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Pango-1.2.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.2/ As compared to Pango-1.2.1 (Pango-1.2.2 was a short-lived release and never announced), this release contains various bug fixes, a large speedup to layout with the Xft and FT2 backends (as much as 5 times faster for short strings), and new shapers to allow Indic and Thai to be used with the FT2 backend. About Pango =========== Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most usage so far as been in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+ 2. Pango is designed to be modular; the core Pango layout can be used with four different font backends: - Core X windowing system fonts - Client-side fonts on X using the Xft2 library - Direct rendering of scalable fonts using the FreeType library - Native fonts on Microsoft platforms Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango-1.2 ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango depends on version 2.2.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of Changes in Pango 1.2.2 ================================== * Fix operation with --disable-debug [Jeff Waugh] * Improve handling of ink rectangle extents for empty runs * Fix problem with keynav at line boundaries for RTL text [Matthias Clasen] Overview of Changes in Pango 1.2.2 ================================== * Cache fontsets for the Xft and FT2 backends, a large speedup for short strings [Owen Taylor, Soeren Sandmann] * Make built in rendering functions, especially the FT2 one, work more like the GDK implementation [Sven Neumann] * Add an indic-ft2 module [Kapil Chowskey], Add a thai-ft2 module [Theppitak Karoonboonyanan] * Optimize pango_x_render() by drawing multiple character with a single request when possible [Morten Welinder] * Change the handling of attributes that cover only partial glyphs [Owen, Taneem Ahmed, Sunil Mohan Adapa] * Fix problems with Arial Unicode and the Opentype code [Owen, Noah Levitt] * Fix common crash for fonts missing a GDEF table * Fix common portability problem with informative output at end of configure. * Build cleanups and fixes [Tim Mooney, Chris Ross, Akira Tagoh, Will Partain, James Su] * Miscellaneous bug fixes and cleanups [Simon Budig, Rick Jones, Noah, Padraig O'Briain, Benjamin Otte, Andrey Panov, Federic Zhang] * Documentation fixes [Tim, Sven] Owen Taylor 9 June 2003 From sky@icqus.dyndns.org Mon Jun 9 16:32:24 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from icqus.dyndns.org (12-215-147-200.client.mchsi.com [12.215.147.200]) by mail.gnome.org (Postfix) with ESMTP id 67E75187AD for ; Mon, 9 Jun 2003 16:32:24 -0400 (EDT) Received: from icqus.dyndns.org (sky@localhost.my.domain [IPv6:::1]) by icqus.dyndns.org (8.12.9/8.12.9) with ESMTP id h59KWNpp005422 for ; Mon, 9 Jun 2003 16:32:23 -0400 (EDT) Received: (from sky@localhost) by icqus.dyndns.org (8.12.9/8.12.9/Submit) id h59KU0bD021164 for gtk-i18n-list@gnome.org; Mon, 9 Jun 2003 16:30:00 -0400 (EDT) Date: Mon, 9 Jun 2003 16:30:00 -0400 (EDT) From: Teardrop Sky Message-Id: <200306092030.h59KU0bD021164@icqus.dyndns.org> To: gtk-i18n-list@gnome.org Subject: unicode fonts Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: i had a question about unicode fonts that i posted to gtk-list, but i just discovered this list and realized it had been more appropriate here, but in short i'm looking for examples of unicode code written for gtk+2. (specifically with greek and hebrew fonts, but anything to sift through would be welcome) links or short examples, whatever. thanks :) ~sky From vivek@lantana.tenet.res.in Tue Jun 10 08:40:48 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id F3849180EE for ; Tue, 10 Jun 2003 08:40:45 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5ACea804262 for ; Tue, 10 Jun 2003 18:10:39 +0530 Subject: compiling gtk+-2.2.1 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-ttvrksX/Kvt+Z581nOPE" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Jun 2003 18:10:54 +0530 Message-Id: <1055248857.10655.3.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-ttvrksX/Kvt+Z581nOPE Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii I am upgrading the gtk (which is available with RH 8.0) to gtk+-2.2.1. After completing the make and make install, While starting the gnome-session, I got the following error. gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name This lib is linked with the lib which is currently created as follows lrwxrwxrwx 1 root root 25 Jun 10 17:55 /usr/lib/libgdk-x11-2.0.so.0 -> libgdk-x11-2.0.so.0.200.1 What should I do ? with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-ttvrksX/Kvt+Z581nOPE Content-Type: text/html; charset=utf-8 Hii
I am upgrading the gtk (which is available with RH 8.0) to gtk+-2.2.1. After completing the make and make install,  While starting the gnome-session, I got the following error.

gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name

This lib is linked with the lib which is currently created as follows
lrwxrwxrwx    1 root     root           25 Jun 10 17:55 /usr/lib/libgdk-x11-2.0.so.0 -> libgdk-x11-2.0.so.0.200.1

What should I do ?

with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-ttvrksX/Kvt+Z581nOPE-- From vivek@lantana.tenet.res.in Thu Jun 12 04:35:17 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id EFFD318D26 for ; Thu, 12 Jun 2003 04:35:14 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5C8Yk830183 for ; Thu, 12 Jun 2003 14:04:48 +0530 Subject: [Fwd: Use of Bonobo (fwd)] From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-v4j5dv3CjxL1ERGc2Gfa" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 12 Jun 2003 14:05:32 +0530 Message-Id: <1055406934.20734.4.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-v4j5dv3CjxL1ERGc2Gfa Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii all, Can anyone please tell me what is the role of Bonobo object in gedit? with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-v4j5dv3CjxL1ERGc2Gfa Content-Type: text/html; charset=utf-8 
Hii all,
	Can anyone please tell me what is the role of Bonobo object in gedit?

with regards
vivek
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-v4j5dv3CjxL1ERGc2Gfa-- From chutz@gg3.net Sat Jun 14 04:00:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from tiger.gg3.net (142.13.111.219.st.bbexcite.jp [219.111.13.142]) by mail.gnome.org (Postfix) with SMTP id 855E618512 for ; Sat, 14 Jun 2003 04:00:29 -0400 (EDT) Received: (qmail 23398 invoked by uid 0); 14 Jun 2003 08:00:28 -0000 Received: from tiger.gg3.net (10.0.0.9) by 0 with SMTP; 14 Jun 2003 08:00:28 -0000 Received: from lion.gg3.net (10.0.0.2) by tiger.gg3.net (tmda-ofmipd) with ESMTP; Sat, 14 Jun 2003 17:00:27 +0900 Received: by lion.gg3.net (sSMTP sendmail emulation); Sat, 14 Jun 2003 17:00:27 +0900 Date: Sat, 14 Jun 2003 17:00:27 +0900 To: gtk-i18n-list@gnome.org Subject: Regarding selection of alternate fonts (with untagged text) Message-ID: <20030614080027.GA4590%chutz@gg3.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.5.4i-ja.1 From: Georgi Georgiev Mail-Followup-To: gtk-i18n-list@gnome.org X-Delivery-Agent: TMDA/0.74 (Citation) X-Primary-Address: chutz@gg3.net Reply-To: Georgi Georgiev Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello list, I have a question/problem which was partially answered at http://www.pango.org/font-selection.shtml (I hope this is the right list to post my question to). My question is related to language auto-tagging and the selection of an alternate font that Pango makes in different locales. My problem is that basically, it chooses different fonts for Cyrillic text when LC_ALL is set to bg_BG or ja_JP. There were a few interesting posts I found in the mailing list archive, but the talk being too broad, I had trouble understanding if this problem is being tackled or not. Here goes a more detailed description of what I mean. What happens is that I for example have my locale set to ja_JP. Actually it is only LC_CTYPE=ja_JP LC_COLLATE=ja_JP LC_MONETARY=ja_JP and the rest LC_*=C (LC_ALL is unset). I need the few ja_JP because I want to be able to properly display Japanese in all applications, but I prefer to read messages in English. I also need it for Japanese input. However, I sometimes also work with Cyrillic (actually pretty often). What happens when Pango is asked for a font that does not have the Cyrillic characters is that it of course does that auto-tagging and substitution (I guess) and hands me a different font that has the characters that I need. In my /etc/fonts/fonts.conf I have the following: sans-serif Bitstream Vera Sans Arial Verdana Nimbus Sans L Luxi Sans Helvetica Kochi Gothic AR PL KaitiM GB AR PL KaitiM Big5 Baekmuk Dotum SimSun When I run a program with LC_ALL=bg_BG, Cyrillic is displayed in Arial. However, when I run it with LC_ALL=ja_JP I see Cyrillic displayed in Kochi Gothic (meaning ugly, square letters). I am also attaching two small screenshots to illustrate what I mean. So my question is, how do I make Pango "prefer" Arial over Kochi when my locale is ja_JP (short of specifying Arial explicitly, which works). I don't know if it is possible, but I just wanted to state my problem. -- /^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\ / Georgi Georgiev (-< / A pencil with no point needs no \ \ chutz@chubaka.net /\ .o)\ eraser. / / +81(90)6266-1163 V_/_ |(/)/ \ \___________________________/\__________________________________/ --HlL+5n6rz5pIUxbD Content-Type: image/png Content-Disposition: attachment; filename="bg_BG.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASkAAAAcCAAAAAAYMhb0AAAC2UlEQVR4nO1YPWsVQRQ9J0LA 4CchoCLa2QQbkYCViGBra6MIVhZ2/gNbi7RK7BRBQbDTfxCD6Q3YaCEBSVKkU8ix2Llz7+zb F+Yl4CMwh7A792vm7tkzs49QaKjCzLQbODKYAZmGZB52pl8xEOmDzBMwTFUmk6WHJLFzZ+5A vQ/3Md5/uFzXFCGBwcQECwIAlCZgHo1J6zmWv/yYcKWMbjkGayiJI9m9TFaMZtxU+RAjDzSy ODn4SgiNlncqI8BUlioF4MPtBZBYI0G+mb+xaZbpNAcBEt9uzs0ufuqKRdKmtEs3aXjVki3G 3CGNX8UAoLwdos8yJcluhu5RNRhNVUiMhIpYEt3FdKkuDz/jhQToASDg8Qrum+U5KSgBuvb6 7zoueGuCINmiKU2Q+eB39JtCqkR+Ethf8uXRREzBufVb4A+BrbwyBqYsSZvdkIDflwABW9tY MMtzUrDzrD29Csqe0pZVXD9cFBtw1oyDgpIY6JM4/ts3sLEiJQOQn04jWRw+OgXg/Z8nAPDq IQDg7GnsuGWI5vLSxkqWJZ2uJJssWXT7hiL7G425vXRQyLoUu6D7SoWMaKqQZ62mgm48Mmb3 BUnsXeZ3AVd+AQI2t3HOrD0cS+kpKAE6gd1dF4FJKZCfheSNmGk6ifIph954GXZNCRzUUaEA a23fj80+n71eTfpNcU9vAVw/DwB49hF3zdrCUspMQQDAKay/9GLjOz/RyOICUHqp7nNkvVB9 mfV97i9PtUJTZVKUmksuCM6GxSvvneE9aX3FooDVzvP85K1ts45f/JnyVr0XvJs/8ygvnU/v UkOFSrLpmbLtNTxH6etuJW0Tgzhc/QHmKzqmCFlZUUynNg2pWOvJlM/KoKjkK1wHA6GpM/Uf 0V/Xvl1VtQiH0pT6/3+Y1hs6emj/S6hFY6oWjalaNKZq0ZiqRWOqFo2pWjSmatGYqkVjqhaN qVo0pmrRmKrFPw6cTkdTqI2EAAAAAElFTkSuQmCC --HlL+5n6rz5pIUxbD Content-Type: image/png Content-Disposition: attachment; filename="ja_JP.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAATgAAAAcAQAAAADdTp5TAAABd0lEQVR4nO3Rv0sCURwA8EvD lsihpSByiVwLV+9uDP+B/oRGHYQkOLuiQaLBwSXRvKHRwaGhoU4Ho5KMm4LA6IRCqdDnD+R5 3vO+PU/Loij/AL88vjz4fnjfL+/LwGjBjOqkLCQEKAOs8DxRyLCimAeADFwUZoTezSXxBL64 mxRSIFyVCe6CiBiJB68AJQd13JyHvRQ/3IOFefQ1q/IRJg7TGRsCPCvUufPX0cqnk9aNQ5QJ FV92gve2ib6rOZXefPlctFKPS/PFenwtHJvaS5Qzr7qGt9SA+Z6N9rWDC7jpXOxJ53wnLZ1D WFax/GYtBM7wZt+RhlBbUpoucOdzsUonjZItmkIZGyOjIHVI5DB1UerofKbbj1S1tC92p6VR gFURi7oF7ywS09TtZklj0l5ytv1gWfZELvyL0uptc2HqgE0hVtWT3WN1O4jVwT7Kw38zzIyh 41cM/urUEM81XeF/OiLCL8GAYe0tqW3/Z79/l8du7L7FO3330tQ/Xb18AAAAAElFTkSuQmCC --HlL+5n6rz5pIUxbD-- From vivek@lantana.tenet.res.in Tue Jun 17 05:15:02 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 0299418653 for ; Tue, 17 Jun 2003 05:14:56 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5H9EEC02535; Tue, 17 Jun 2003 14:44:19 +0530 Subject: gtk+-2.2.1 compilation From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-Q1Eg8cjg6cVUshCdvynd" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 17 Jun 2003 15:45:16 +0530 Message-Id: <1055844921.801.99.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-Q1Eg8cjg6cVUshCdvynd Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all I compiled the gtk+-2.2.1 using the source. After the compilation, while starting gnome, it says the error, gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name what is this 'relocation error' ? what should I do for this ? with regards Vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-Q1Eg8cjg6cVUshCdvynd Content-Type: text/html; charset=utf-8 Hi all
I compiled the gtk+-2.2.1 using the source.
After the compilation, while starting gnome, it says the error,

gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name

what is this 'relocation error' ? what should I do for this ?

with regards
Vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-Q1Eg8cjg6cVUshCdvynd-- From klchxbec@yahoo.com Wed Jun 18 01:02:20 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from web13901.mail.yahoo.com (web13901.mail.yahoo.com [216.136.175.27]) by mail.gnome.org (Postfix) with SMTP id C46961823F for ; Wed, 18 Jun 2003 01:02:19 -0400 (EDT) Message-ID: <20030618050219.94343.qmail@web13901.mail.yahoo.com> Received: from [203.200.195.2] by web13901.mail.yahoo.com via HTTP; Tue, 17 Jun 2003 22:02:19 PDT Date: Tue, 17 Jun 2003 22:02:19 -0700 (PDT) From: klchxbec Subject: fix to pango GSUB To: gtk-i18n-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Here is a one-liner to fix pango's GSUB code for rendering kannada text. ftp://ftp.gtk.org/incoming/ftxgsub-bad.png ftp://ftp.gtk.org/incoming/ftxgsub-good.png Index: pango/opentype/ftxgsub.c =================================================================== RCS file: /cvs/gnome/pango/pango/opentype/ftxgsub.c,v retrieving revision 1.6 diff -u -r1.6 ftxgsub.c --- pango/opentype/ftxgsub.c 16 Apr 2003 03:58:17 -0000 1.6 +++ pango/opentype/ftxgsub.c 17 Jun 2003 12:26:01 -0000 @@ -3823,7 +3823,7 @@ /* we are starting for lookahead glyphs right after the last context glyph */ - curr_pos = j; + curr_pos += j; s_in = &in->string[curr_pos]; lc = ccsf3->LookaheadCoverage; __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From zenithlau@i-cable.com Wed Jun 18 11:12:43 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from virgo.i-cable.com (virgo.i-cable.com [203.83.111.75]) by mail.gnome.org (Postfix) with SMTP id 2AA1B180E4 for ; Wed, 18 Jun 2003 11:12:42 -0400 (EDT) Received: (qmail 8987 invoked by uid 706); 18 Jun 2003 15:12:36 -0000 Received: from cm61-10-38-94.hkcable.com.hk (HELO ?192.168.0.34?) (61.10.38.94) by 0 with SMTP; 18 Jun 2003 15:12:13 -0000 Subject: Font configuration issues. From: Zarick Lau Reply-To: zenithlau@i-cable.com To: gtk-i18n-list@gnome.org Content-Type: text/plain Organization: NixStyle.Net Message-Id: <1055949103.5609.8.camel@zlap> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 18 Jun 2003 23:11:43 +0800 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi list, I am using gtk 2.2.1 with Gnome 2.2, I found that if the selection of font is effectively determined by LC_CTYPE, why?? In my understanding, LC_CTYPE should only influence how a apps process the data from external. Though I am not sure.. Another important issues is, is it possible to configuration the system (fonts.conf right?) so that, when in non en locale, the system will still use en fonts to render the latin messages, while taking another fonts for other language? If it is only a configuration issues, would you mind show me a bit examples? Regards, Zarick Lau From Tony.Graham@Sun.COM Wed Jun 18 11:22:48 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.gnome.org (Postfix) with ESMTP id B3BEB180E4 for ; Wed, 18 Jun 2003 11:22:47 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5IFMkLv026967 for ; Wed, 18 Jun 2003 08:22:46 -0700 (PDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5IFMjg6025853 for ; Wed, 18 Jun 2003 16:22:45 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5IFP1i04287; Wed, 18 Jun 2003 16:25:01 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16112.33869.254511.67633@tenso.ireland.sun.com> Date: Wed, 18 Jun 2003 16:25:01 +0100 To: gtk-i18n-list@gnome.org Subject: PangoPDF 1.2.3.0 released X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: PangoPDF is a version of Pango with additional PDF/PostScript backends and support for additional XSL-related text attributes. This release updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and Xft backends to match Pango 1.2.3. Download PangoPDF from http://sourceforge.net/projects/pangopdf/. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From vivek@lantana.tenet.res.in Thu Jun 19 00:26:38 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 75EA4181CD for ; Thu, 19 Jun 2003 00:26:36 -0400 (EDT) Received: from swan.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5J4PkC11643; Thu, 19 Jun 2003 09:55:48 +0530 Subject: GTK+- runtime error From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-c3mWW04KSiClVd8B3bqY" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Jun 2003 10:06:33 +0530 Message-Id: <1055997396.1426.4.camel@swan.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-c3mWW04KSiClVd8B3bqY Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii all. I am compiling the GTK+ from the source. The version I am using is 2.0.6. Previously i went through the latest versions, but it needs the latest, xft, glib etc.. There also I got a problem of 'relocation error'. so, I thought to use the same version of GTK installed in Redhat 8.0. After that, while i start 'gedit' or 'gnome-session' anything, i got the following error. What i have to do to make the compilation successfully ? The program 'gedit' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 46 error_code 16 request_code 154 minor_code 20) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Or can anyone tell me, with 'which version of which', I can successfully compile the Pango and GTK from source? Thanking you, with regards Vivek. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-c3mWW04KSiClVd8B3bqY Content-Type: text/html; charset=utf-8 Hii all.

I am compiling the GTK+ from the source. The version I am using is 2.0.6.  Previously i went through the latest versions, but it needs the latest, xft, glib etc..  There also I got a problem of
'relocation error'. so, I thought to use the same version of GTK installed in Redhat 8.0.

After that, while i start 'gedit' or 'gnome-session' anything, i got the following error.  What i have to
do to make the compilation successfully ?

The program 'gedit' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 46 error_code 16 request_code 154 minor_code 20)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Or can anyone tell me, with 'which version of which', I can successfully compile the Pango and GTK from source?

Thanking you,
with regards
Vivek. 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-c3mWW04KSiClVd8B3bqY-- From ittay@qlusters.com Sun Jun 22 10:17:59 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from hirame.qlusters.com (adsl-139-109.barak.net.il [62.90.139.109]) by mail.gnome.org (Postfix) with ESMTP id 2FA62181E0 for ; Sun, 22 Jun 2003 10:17:58 -0400 (EDT) Received: from ittay ([10.100.0.13]) by hirame.qlusters (8.10.2/8.10.2) with ESMTP id h5MEFge26386 for ; Sun, 22 Jun 2003 17:15:42 +0300 Subject: how do i add windows-1255 encoding? From: Ittay Dror To: gtk-i18n-list@gnome.org In-Reply-To: <20030622133801.28246.23535.Mailman@moniker.gnome.org> References: <20030622133801.28246.23535.Mailman@moniker.gnome.org> Content-Type: text/plain Message-Id: <1056291353.18485.6.camel@ittay> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0-1mdk Date: 22 Jun 2003 17:15:53 +0300 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: i'm using the new evolution, and the only hebrew encoding i have is iso-8859-8. unfortunately, all the words are in reverse order. i thought adding windows-1255 encoding would solve this. how do i add it? thanx, ittay -- ======================================= Ittay Dror (ittay@qlusters.com) User Space, R&D Qlusters Inc. Tel: +972-3-6081956 Fax: +972-3-6081841 From Takao.Fujiwara@Sun.COM Fri Jun 20 10:49:28 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.gnome.org (Postfix) with ESMTP id E5DBA1843D for ; Fri, 20 Jun 2003 10:49:27 -0400 (EDT) Received: from udsylm-mail1.Japan.Sun.COM ([129.158.26.30]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5KEnQep002428 for ; Fri, 20 Jun 2003 08:49:27 -0600 (MDT) Received: from requiem (requiem [129.158.28.20]) by udsylm-mail1.Japan.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.1p1) with SMTP id h5KEnPY25373; Fri, 20 Jun 2003 23:49:26 +0900 (JST) Message-Id: <200306201449.h5KEnPY25373@udsylm-mail1.Japan.Sun.COM> Date: Fri, 20 Jun 2003 23:49:19 +0900 (JST) From: Takao Fujiwara - Tokyo S/W Center Reply-To: Takao Fujiwara - Tokyo S/W Center Subject: alias in pangox.alias To: gtk-i18n-list@gnome.org Cc: Takao.Fujiwara@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zu2WY8a+lt3tBgPe0y0esA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 sun4u sparc Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi experts, I have quality issues about Japanese fonts in Pango. When we choose small size fonts in GNOME2.0.2 (pango 1.0.5) + Solaris 9, The rendering in Japanese fonts are very ugly. I have one remedy to add some alias to pangox.alias. However I don't have an explicit answer that it is no problem for pango specification. I would like to ask you it. Do you have any ideas to add gothic and mincho as aliases to pangox.alias below? gothic normal normal normal normal \ "-ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0201.1976-0,\ -ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0212.1990-0,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-1,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-2,\ -adobe-helvetica-medium-r-normal--*-*-*-*-*-*-iso8859-1" mincho normal normal normal normal \ "-ricoh-hg mincho l-medium-r-normal--*-*-*-*-c-*-jisx0201.1976-0,\ -ricoh-hg mincho l-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0212.1990-0,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-1,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-2,\ -adobe-utopia-medium-r-normal--*-*-*-*-*-*-iso8859-1" This remedy can fix problems that characters are very ugly in small Japanese fonts when gtk applications(Mozilla, etc) choose any fonts beside sans, serif, and monospace. I think that the issue occurs because 'gothic' in jisx0208 does not have small point size but 'hg gothic b' in jisx0208 has small point size. % xlsfonts -fn '-sun-minchou-bold-r-normal--*-*-*-*-c-*-jisx0208.1983-0' -sun-gothic-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0 -sun-gothic-medium-r-normal--14-120-75-75-c-120-jisx0208.1983-0 <---- -sun-gothic-medium-r-normal--16-140-75-75-c-140-jisx0208.1983-0 -sun-gothic-medium-r-normal--18-160-75-75-c-160-jisx0208.1983-0 -sun-gothic-medium-r-normal--22-200-75-75-c-200-jisx0208.1983-0 -sun-gothic-medium-r-normal--26-240-75-75-c-240-jisx0208.1983-0 % xlsfonts -fn '-ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0' -ricoh-hg gothic b-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--0-0-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--10-100-72-72-c-100-jisx0208.1983-0 <---- -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-120-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--14-140-72-72-c-140-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--16-160-72-72-c-160-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--18-180-72-72-c-180-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--20-200-72-72-c-200-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--24-240-72-72-c-240-jisx0208.1983-0 Sans, serif, and monospace have similar problems. If sans has only sun-gothic as jisx0208 font, pango renders ugly glyph. But If sans has ricoh-hg gothic b as jisx0208 font, pago renders fine glyph. So when pango refers 'gothic', I would like to point 'hg gothic b' in jisx0208/0201 against 'gothic', and when pango refers 'mincho', I would like to point 'hg mincho l' in jisx0208/0201 against 'mincho'. pangox.alias in Solaris has distinct directory(/etc/pango/$locale/pangox.alias) by locale, so pangox.alias can be set in each locale. I think this remedy has a pretty pit, i.e. If set 'gothic bold normal normal normal' in pangox.alias, user can see duplicated 'Bold' fonts in gnome-font-properties. It is no problem in 'gothic normal normal normal normal' because gothic fonts originally have 'medium' style but not 'normal' style. I do not join this mail alias, so please mail to me directly. Thanks in advance, Sun Microsystems Software Engineer Tokyo Software Center Takao Fujiwara E-Mail: Takao.Fujiwara@Sun.COM Tel: +81-45-227-9287(direct)/Fax: +81-45-225-5295 From otaylor@redhat.com Mon Jun 23 06:20:33 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1CFD018848 for ; Mon, 23 Jun 2003 06:20:33 -0400 (EDT) Received: from vpn50-2.rdu.redhat.com (vpn50-2.rdu.redhat.com [172.16.50.2]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5NAJxK02035; Mon, 23 Jun 2003 06:19:59 -0400 Subject: Re: PangoPDF 1.2.3.0 released From: Owen Taylor To: Tony Graham Cc: gtk-i18n-list@gnome.org In-Reply-To: <16112.33869.254511.67633@tenso.ireland.sun.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> Content-Type: text/plain Organization: Message-Id: <1056363575.13947.45.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 23 Jun 2003 06:19:36 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > PangoPDF is a version of Pango with additional PDF/PostScript backends > and support for additional XSL-related text attributes. This release > updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and > Xft backends to match Pango 1.2.3. > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. I'm being incredibly lazy here, and really should go look at the code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps the real question is, what do you mean by "backend" here?) I can't really see how you'd replace the Pango backend libraries and/or the shapers and keep keep things working reasonably. Regards, Owen From maclas@gmx.de Mon Jun 23 07:24:44 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by mail.gnome.org (Postfix) with SMTP id 5398F183F0 for ; Mon, 23 Jun 2003 07:24:44 -0400 (EDT) Received: (qmail 27486 invoked by uid 0); 23 Jun 2003 11:24:42 -0000 Date: Mon, 23 Jun 2003 13:24:42 +0200 (MEST) From: Matthias Clasen To: Owen Taylor Cc: gtk-i18n-list@gnome.org MIME-Version: 1.0 References: <1056363575.13947.45.camel@localhost.localdomain> Subject: Re: PangoPDF 1.2.3.0 released X-Priority: 3 (Normal) X-Authenticated-Sender: #0014083743@gmx.net X-Authenticated-IP: [195.243.100.246] Message-ID: <15429.1056367482@www60.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > > PangoPDF is a version of Pango with additional PDF/PostScript backends > > and support for additional XSL-related text attributes. This release > > updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and > > Xft backends to match Pango 1.2.3. > > > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > I'm being incredibly lazy here, and really should go look at the > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > the real question is, what do you mean by "backend" here?) > > I can't really see how you'd replace the Pango backend libraries > and/or the shapers and keep keep things working reasonably. > From the PangoPDF homepage: PangoPDF implements a version of the Pango (http://www.pango.org/) library with a PDF backend for creating PDF output. This library also implements several of the inline properties defined by XSL (http://www.w3.org/TR/xsl/) that are not currently implemented by Pango. PangoPDF is designed to be API-compatible with the corresponding Pango version. The version number of the PangoPDF library, therefore, reflects the version number of the Pango version upon which library is based. The current PangoPDF version is 1.2.0.1, since it is based upon Pango 1.2.0. The goal of this project is to make itself redundant by implementing PDF support and XSL support so well that the additions are incorporated into Pango itself. The PangoPDF library tracks the official Pango library so the PangoPDF library can incorporate non PDF-related improvements and API changes as they are incorporated into Pango. -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! From vivek@lantana.tenet.res.in Tue Jun 24 07:00:39 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 238F4181D4; Tue, 24 Jun 2003 07:00:36 -0400 (EDT) Received: from lantana.iitm.ernet.in (IDENT:DcG7BlZfrrIv1KNv03I8HUSr4W9KMQwn@lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h5OB0wC16387; Tue, 24 Jun 2003 16:30:58 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5OAwsC00995; Tue, 24 Jun 2003 16:28:55 +0530 Subject: Encoding other than UTF-8 ? From: Viveka Nathan K To: gtk-list@gnome.org Cc: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-e35IJaWRw9jjkFMGgWt7" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Jun 2003 16:30:58 +0530 Message-Id: <1056452459.6174.30.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-e35IJaWRw9jjkFMGgWt7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all.. How can I use the encoding other than UTF-8, in GNOME ? If I set the LOCALE to en_US.ISO-8859-1, it saves the file in UTF-8 format only. How can I change it ? Applications like 'gtk2edit' are having the options to store in different encodings, but in 'gedit', I couldnt do that. Is there any way to do that ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Phone - Mobile: 0-9444167493 Off:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-e35IJaWRw9jjkFMGgWt7 Content-Type: text/html; charset=utf-8 Hi all..
How can I use the encoding other than UTF-8, in GNOME ?
If I set the LOCALE to en_US.ISO-8859-1, it saves the file in UTF-8 format only.
How can I change it ?  Applications like 'gtk2edit' are having the options to store
in different encodings, but in  'gedit', I couldnt do that.

Is there any way to do that ? 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. 
Phone - Mobile: 0-9444167493 Off:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves 
- Swami Vivekananda
--=-e35IJaWRw9jjkFMGgWt7-- From Tony.Graham@Sun.COM Wed Jun 25 06:36:05 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.gnome.org (Postfix) with ESMTP id A477318237 for ; Wed, 25 Jun 2003 06:36:04 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PAa3vc007545 for ; Wed, 25 Jun 2003 04:36:03 -0600 (MDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PAa2g6012556 for ; Wed, 25 Jun 2003 11:36:02 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5PAcGo09573; Wed, 25 Jun 2003 11:38:16 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16121.31640.237024.593290@tenso.ireland.sun.com> Date: Wed, 25 Jun 2003 11:38:16 +0100 To: gtk-i18n-list@gnome.org Subject: Re: PangoPDF 1.2.3.0 released In-Reply-To: <1056363575.13947.45.camel@localhost.localdomain> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400: > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: ... > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > I'm being incredibly lazy here, and really should go look at the > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > the real question is, what do you mean by "backend" here?) PangoPDF includes all of the backends so PangoPDF can be used as a drop-in replacement for Pango. To use PangoPDF instead of Pango in an application, just edit the application's configure.in (or configure.ac) to prefix Pango's pkg-config package names with 'pangopdf-', then rerun autoconf and configure. That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF. The FT2/X/Xft backends in PangoPDF are really just vanilla Pango. I expect that PangoPDF will add support for the 'XSL' attributes (which are also CSS3 attributes) to the FT2 and Xft backends (as one person has done for FT2 in his version of PangoPDF), but I expect to first implement the 'XSL' attributes as (conditionally) part of the PangAttrType enumeration instead of registering them with pango_attr_type_register() because it's so much easier to work with attribute types as constants rather than variables. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From otaylor@redhat.com Wed Jun 25 11:22:11 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DD55918C6E for ; Wed, 25 Jun 2003 11:22:10 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5PFM5K27129; Wed, 25 Jun 2003 11:22:05 -0400 Subject: Re: PangoPDF 1.2.3.0 released From: Owen Taylor To: Tony Graham Cc: gtk-i18n-list@gnome.org In-Reply-To: <16121.31640.237024.593290@tenso.ireland.sun.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> <16121.31640.237024.593290@tenso.ireland.sun.com> Content-Type: text/plain Message-Id: <1056554525.14257.195.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 25 Jun 2003 11:22:05 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Wed, 2003-06-25 at 06:38, Tony Graham wrote: > Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400: > > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > ... > > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > > > I'm being incredibly lazy here, and really should go look at the > > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > > the real question is, what do you mean by "backend" here?) > > PangoPDF includes all of the backends so PangoPDF can be used as a > drop-in replacement for Pango. > > To use PangoPDF instead of Pango in an application, just edit the > application's configure.in (or configure.ac) to prefix Pango's > pkg-config package names with 'pangopdf-', then rerun autoconf and > configure. > > That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF. > > The FT2/X/Xft backends in PangoPDF are really just vanilla Pango. I > expect that PangoPDF will add support for the 'XSL' attributes (which > are also CSS3 attributes) to the FT2 and Xft backends (as one person > has done for FT2 in his version of PangoPDF), but I expect to first > implement the 'XSL' attributes as (conditionally) part of the > PangAttrType enumeration instead of registering them with > pango_attr_type_register() because it's so much easier to work with > attribute types as constants rather than variables. While it's fine to experiment with a fork of Pango, I'd really strongly encourage you to try to get API additions into the main Pango. Pango really isn't a big enough of a project to need two competing versions, and there are some definately potential problems with what you are doing. For example, if you modify libgnomeprint-2.2.1.2 as you describe then you'll link against *both* Pango and PangoPDF when you have an app that uses GTK+ and uses libgnomeprint. And the effects of that will be unpredicatable and probably bad. But why is pango_attr_type_register() so hard to use? I don't really understand the problem. Sure, it's a few more lines of code, but that doesn't quite seem worth maintaining a fork. Regards, Owen From Tony.Graham@Sun.COM Wed Jun 25 18:38:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.gnome.org (Postfix) with ESMTP id 3984118C60 for ; Wed, 25 Jun 2003 18:38:30 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PMcRvc013790 for ; Wed, 25 Jun 2003 16:38:28 -0600 (MDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PMcRg6025351 for ; Wed, 25 Jun 2003 23:38:27 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5PMefA10115; Wed, 25 Jun 2003 23:40:41 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16122.9449.263238.517090@tenso.ireland.sun.com> Date: Wed, 25 Jun 2003 23:40:41 +0100 To: gtk-i18n-list@gnome.org Subject: Re: PangoPDF 1.2.3.0 released In-Reply-To: <1056554525.14257.195.camel@poincare.devel.redhat.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> <16121.31640.237024.593290@tenso.ireland.sun.com> <1056554525.14257.195.camel@poincare.devel.redhat.com> X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Owen Taylor wrote at 25 Jun 2003 11:22:05 -0400: ... > While it's fine to experiment with a fork of Pango, I'd really > strongly encourage you to try to get API additions into the > main Pango. Pango really isn't a big enough of a project > to need two competing versions, and there are some definately > potential problems with what you are doing. I don't want to fork Pango, and, as Matthis Clasen posted, the goal of PangoPDF is to make itself obsolete. > For example, if you modify libgnomeprint-2.2.1.2 as you > describe then you'll link against *both* Pango and PangoPDF > when you have an app that uses GTK+ and uses libgnomeprint. > And the effects of that will be unpredicatable and probably > bad. I know that. I still don't have a good solution to the fact that PangoPDF's GNOME Print backend depends on GNOME Print which depends on Pango. The effect of that will be unpredictable and probably bad too. As such, I don't think that part's ready to come into the fold. > But why is pango_attr_type_register() so hard to use? I don't > really understand the problem. Sure, it's a few more lines of > code, but that doesn't quite seem worth maintaining a fork. That's not why I'm maintaining a fork. I talked about pango_attr_type_register() when explaining what I would do if I were to add extra attributes to the FT2 and Xft backends. I am interested in seeing the fruits of what you wrote about in the "Merging code between Xft and FT2 shapers" thread on April 14 since that would make it easier to add FreeType-using backends to Pango. I will submit some enhancement requests. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From stephan.hegel@gmx.de Fri Jun 27 08:28:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id 02E8B18100 for ; Fri, 27 Jun 2003 08:28:30 -0400 (EDT) Received: (qmail 12482 invoked by uid 65534); 27 Jun 2003 12:28:18 -0000 Received: from unknown (EHLO gmx.de) (61.155.125.80) by mail.gmx.net (mp023) with SMTP; 27 Jun 2003 14:28:18 +0200 Message-ID: <3EFC3811.2090705@gmx.de> Date: Fri, 27 Jun 2003 20:26:57 +0800 From: Stephan Hegel Reply-To: stephan.hegel@gmx.de Organization: Private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en, de, zh-CN MIME-Version: 1.0 To: gtk-i18n-list@gnome.org Subject: Unexpected font rendering with pango Content-Type: multipart/mixed; boundary="------------010503000008060104000107" Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------010503000008060104000107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Recently I have found an unusual behaviour in Chinese font rendering with Pango.Please have a look at the attached, little screenshots. The only difference between both is the setting of the locale before starting the application. The first one uses LC_ALL=en_US and the second one LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing antialiasing - fine on the second pix, but not o.k. in the first case. It somehow uses a different size of fonts in just one string ... Anyone out there who has an idea or a hint how to track this and/or to fix this ? The application used in this case is called "lingoteach" and available on freshmeat. However, I have noticed that stardict behaves in the same strange way ... Kind regards, Stephan. --------------010503000008060104000107 Content-Type: image/png; name="en_US.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="en_US.png" iVBORw0KGgoAAAANSUhEUgAAAT4AAAFSCAIAAADkbCRGAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wYbCS03x2AlcAAAIABJREFUeJzt3XtwHNWB LvDTM6PRzEiyZMmyJfAzloRjrXB4+0IuZHfByZoK2ZuLy+xWkVRgNxvX3RTEhhgbYuOX/MQG wiPs5W6y2Vs32aQCLBCyobzEBrN+CD9Hkq2HkY2MJVsaPSxpZrrnce4fx+kc9XS3uud95O9X Lld3z+nTZ1r9zTnd82jJ7/c3NDT4/X5CSENDAyGETQPkv4aGhk/8nbluRW5ILKhlZWWRSESW 5VgsRgiRJElRlGg0Go/HKaXqbCwWGx4evnLlyr333mur/MMPP8zKU0r12yFJ6nQkElGno9Go Oh2Px9Vpvh5+XUVRJlzO18/an1gnT5ZlddrhcOi2x+40vy2j5alM8+wuN5Ku52W0zzMxzTNa 7vF41OmioiJ12uv1sgmfz9fV1dXc3LxixYqMxsRWeRdrnKIoIyMjgUCAHdaU0kgkEovFWBXq rCzLn332WWdn5913322r/PLly0dHRwcGBvjY8NHiWYmu0Z+EX5fHR5ev0+gw4rfF12k3upmO aCaia7Sc31f59nyt7AejNhcWFqrTPp9PnVajW1hYePz48QMHDjz66KMZjQlffvr06YQQRVF6 enp0y/8puoFAoLOzU5bleDzefaG77UxbYOCyx+OZdf2cquuqfN6iaDQqy3JHR0d3dzcrv2bN mp6eHlZDaWmpOuF0Otk2qqurJUnq7u6ORCKDg4Nnz57lezCj3c0fInYPFz5mfBm+HqNe18oh yLN7aObqULbykmf30M/n52s3umpENdNqjAsKCk6fPt3R0cEO+6VLl8qy7HQ6KyoqKioqIpFI RUWF0+l0OBxut3vBggXl5eXNzc1qTJqONo0MjUqSVFZWSiTCetF4PC7LyuBQwOGQXAUFn3Z2 qeVZDO+7775oNOp0Ol977bXh4WHW8cZiMTWGV6Mbi8VYTz06OvrOu+8cPnTI4ZLmVJTQmNL7 Wdvs2bNr6m71FhfJshwKhcLhMCs/MDBwzz33lPrcL77yqiNyZf/7vxvo6w30X77Uc7H19OnW lpZFX/va4cOHw+Ewe8FQFIXv/YyiZbSLjcpYWW40bWVAnrnpjRs3rlu3Tl2+adOmZ555Jrn2 bN++nXCefPJJ6+vu3r37Bz/4QRaeb+rTmfgbuVwu3Wn+JZ4duuywp5QODQ21tLQcO3ZsqP/S 5YufXbr4mRIaGx4aiF5R9r918Jnn/rmpqUmNSUdn+69/8xuf2zNv7ry/+tpSSmgsFguH5Zde erGsKD7nuuo7/vIBPlayLIfD4YGBgXfeeWdwcPCb3/zmz372s1gsFo/H2f/hcDgUCv2poWy/ vPPuO0cOH76+0rdgdpXHUxgbHRwKha50+S8Sufamr7LQq0/J5XItWlj7/RV/F4vK+997699/ 86ueC+cDl3uj0YgkkVKv86677vr4448jkYgkSZIkUUqt9JxW/lRWltsd0KaLrUNn06ZNTz/9 NJt+5plntmzZsnbt2iQ2unr16h07drAzIrbkiSeesL76888///jjjyexXYsy0YtmDTtu1cNm 3rx5L7/8cmdn5+EDf+jv6fa5JU+BVOiSCpySUyIlbumhhx56/fXX1ZiEQ/Lo8BWnd+RKv+/g wf+65ZZbZFl+/vk9bge9/XrPrLmVX5g713+yRS3PtjUwMHDu3LkDBw6Mjo4+8MADb775pppe FsOr0WW56r7QffjQ4esrvX+95M8X33FTV2trz4VPhwZ6QmNy+HLbyKU6R+kMWZZZFCmllZWV gUsXfvC/vtvT/Wnfxc9cUtzjkrxO4ixwSBKhlHi9XrU8O6RSeWVNV1xTGUBm9PDavHkzpXTL li1PP/30li1bCCFqjLdu3UoIWbNmzdatW5966ilCyLZt29hDq1evZhNqT/vkk09SSnfu3Kku 3LVrF3to1apVbOK5554jhKxcuVLd+p49ewghfPdr8fnmW+SMrqHwy/m28dcvjKbZxSF22FdX V3d1dX39619fvnx5eXl5SUmJz+erqKjwer3qKnxMKsqmTZ1SNt0dnuHsjfQV/Ncbh3v7h+tK pNq5hTV1Nz/4j9uO+k/x5dkrRUFBQTweD4VCBw8elCTpgQceePvtt4PBYDweZ2Nml7olRVGO HT3qkMi8WdWL77h5+T+sPfKrnR/s/dwT8YVJOBQNR/r8s76wkI3UWfk777xz5qxZC2/57+wq 17lz58rLy+fPnz9z5szh4eGpU6eyzcTjcTZaZuN1dXekcqnDbkStXNXMB42NjVu2bGHpbWxs pJSuXbu2sbFxzZo127ZtY63dvn07pfSpp55ig2RKqZpe1c6dO5944onnnnuOUrpq1apVq1bt 3r2bFV65cuXu3btXrly5Z88eSinLKqX08ccff+GFFyiljz32WNLtN4qNURmj/Z+u5Tyjl2yn 06lO8wNmNYeSJLF12WF/8ODBffv2/fSnPzU51+VjMnvOrP+57MEPPtg71TM4t+RSYTklM0vk CJGqFv79M699fOTIsaNH+fKsX2WnmR6PR5Kk06dP+3y+b3zjG2+99dbIyMi4XldRFFmWP/vs vMcllXrd51pbDv9q18UzR0udMimKBynxxDwkPlxXN/+3/xGnlLLyZWVlgUDg8uXLwWDw2LFj haNdM6aVU/r1lpaWsbGxWCzGXiTUE13WPt1dmelpsbCDm/WuW7dubWxs3LZt2+rVq5966im1 s92+ffsPf/hDdsju2LGD9bTsITaxa9cu1tnu3r171apV6qN79uzZvXv3nj17Vq5cuWrVquef f37Pnj1siyzGL774ou7gOdMxs7LcSkTtlikoKFCn+ejykZYkyeFwsMOeUtp+qukLCxqio93K YO/+37199ow/pgSHB/ocJD7QerL+H156//331ZhEIpHrr5v5lbv/ovfwOzNKFK9HIoSEw2TB 0mWHP2k6cvggGyHz5dlsQUGBz+fzer1ut7u3t/fQoUOFhYVDQ0Os/NWGsi640FM4xU1jo0MX u8/+Ye/FMmdYksOlrnChh9AYkSm9obaWxY+VZy8PQ0ND+/fvn10U/Pb9t1ZVlL55YG+8+jb1 9ICVZ+ff/AmDyZ8kn89jjaS9J3/66ac19fDjN8bpdKplNNNkfOe2a9cu9WSYX52MH2arD/FH sCpXkUtlf1pZd8LoskEs+WNM5s2bd+TgRz9/bXfg4rkLn55xE6W40FHkdngKJLdLKnaThx56 aOfOnZqYTJ069UQgULRwyorH/4oQ8urz70kxx6lmPx8TvjwhxOv1TpkyxefzVVdXV1ZW9vf3 V1VV9fT0sJIuvnG33HxrkxwYDAWnDvZ6ol5STEudskSk0jKPPEYX3/NAb19fLBZTFIWVj8Vi AwMDBw4cqCunL617fPo939u7fdl0uXO0n4xU3Er+eIbAriqzMIseV6MBYWKuGCuHL//qblKh 0+nctGmTZokmrox6/K1du5aNvQkhO3bs0FwAc7lcjY2N6kK+Bt0mZaLHsyLTlxL56OruBBak WCzGDvvq6up9Ta1Lly7z+XxG57qamMhy+JWXX1pURoMh+uoL7xV6yoIh0nam7YYFX/KfahkL BjTl4/H42NhYUVHRtGnTZs2aNXXq1JKSkrNnzzY3N0+bNo3Fatxlqqqqqjmz5w53+cNjcpiE Q5QWehxlZYUPf+fu373Rctu3NzVuf1lRFPV8OhAI/P73v79hmmPVdx6svOsr5954xn+8yUFj 5aEOX8gz5cb/cerUKVbe4XAkXqbKxFv5RlI5B0ulV5lwuTqxceNGvgB/DG3YsIEVe/bZZ599 9lk2oa64fv16Mj7GDodDfc9p3bp1jY2NDoeDzf7oRz+ilLL/2SwbkBPjU74Jn4uRTPeW6arH aJCs5lC9rssOeyvnunxMFCXy8qsvTy+Q517nVWYsXvClRcP9fUq8teDMr+UC+hdfWfL2u+/y 5dXLVKWlpfX19dddd90NN9zw+uuvt7S01NTUsJYoiuIihDQ0NHzwwQfRaNTj8dbU3XKRyOHL baFo2BPzkBgNj9Hfvd3y1e82njjV0dbepg76o9Hom2++Oas48nfLHrxj+bL2t/7fsUMfReSg u8BVUuKpdne7w8cWPfydjz76yOFwsNcJkwFzKjG2e0XRSkSzcylly5Yt/Bu57FhhXatmeuPG jSyiLLr8EkLIhg0bWP1sgh1/GzZsUHPOzzqdzs2bNzudTlZ4/fr1bDk7gvlpk+eSimyeyFhh 9L4uP2B2uVwul4sd9pTSS22HKmtujV3+5PKZk6MDPcHBXmd0rOvTs2G5PxbdK9VveOONN9SY 9AV6Z011LJjiu/mev/7HLf/07jvv9SsXpt99m3z0V/GO38758pf/9m+WHzp8SC2vhrOkpKS0 tHTRokXr168/f/58XV2dGiJJkv50rsvW8RYX1960ZORSrdzXLCu94aijat6iJWteONna//r/ +Rnb6ZRSVt7pdFZNiV+8+PnP168PDV26eK69uNDhcDqKiz3LH1r8b788ULH0Cb68yRVmnpXe NV1xtRtjK+20si0Vu4yszrL3hNj//JK1a9euW7dOnWVH1ebNmxMrZAtZnZoBtjrLJvhH+WlN /59RVvZzJvDbMjpT4KPrcDhYDxSNRufNmxccG9v3by/+/H//2OuIlBRQVzxY6nUUul3Tp5f+ zd/+N3LnQ5s2bVIP+4qpU++546bpJZ4V619577e//8P+ffF4/PrrZi759mba+e4Xv3znqdbL hIsJyyebdbvdjzzySH9//+LFi9X3ddlO+1N0w+Gwem3aXT6zqnZh3fz5DV/8s76Bwa3P/d+z Zz9lV8BYAVb+xhtvnDl37tiMWZ6KiqKCgi8tKYpEImVlZZTSD6PeG1es9nq96sVu1iz+01T8 n83KJ6JSGTCnMvBOpWdOBV/npk2bWHQJIRs3bkz64rndFe1Gy+5Lod2TFP4SgJX6rVyD4I8x 3bapV4DZYV9dXb3llV8sXbr0odWvGp3r8jEpnzpj7l8u93l9//qLXxw9epSNh9s72kpKim+7 5aunWi9HlDhfnsXwwoULoVDokUceqa6uvuuuu0KhkBppFkMXIcTv9x87dqyjo+PcuXPss8cs YP/5n/vVvltt0JUrVyKRSF9fX0dHRzweb2tra21tVQsYld+/f397e/uFCxfC4bC6a+x+aNGI 3RjzMtHzG7EyUjBx7733sokPP/zQ1nZ5dl+e7I50jKLF/x2NPvZg1B7+b8QPaFOpn8evq9vr xuPx7u7uWCzGDvvi4uLu7u5XXnllwsOeldfESi3f3Nz8Lz83LO9yuT7++GO32z1jxoy2trbE +q/uiJMnT544cWJkZIR9zlE9Y2afpuBn2ftOdsv/8pe/7OnpGRwcDAaDursvlR7VqJ50Lbfb e9iNaCYGirl6vkbfrDKKh1G0jNblrwZnon6jddlbm5mOCV++q6srEolMmTKlu7tbt7ykfsm+ s71F90kCQB4a9x7A/NqFuWoHAFgkSVJne4v27buzHa05aQ0AWPHhvr1sYuKTeADIQ4gugJAQ XQAhIboAQkJ0AYRkNbo1dfXqP1urJNuwLEnieakrplg46U0n3YwcboWvIbna8v9YyrKr3xyy UlT9zEZNXf2En9+wUibnNI3Mfptt7VIAXvIDZvYqqL4W8r1Hig9pXqGtz6aID5J5w2w9C01h o02b1KaZ1n3WVtqszprsxuTab469MGlq0G1D4hPnt46Ol6fzjWoj6o5L7Cs0E+zvpPuQrQlb s+nZH+NrS8sT5Atb37rRKroFrLSZ/PEPN+FuTKX9Fhm1weiJZ6INorv6zSErY2bdHapOm7wi ah4yWcvob8P/XfmFbDYLf1HzTVh8FhYlPsfEg9tKPdabkd72J1auvnBoXkQgFTZ6XXMmf4zk HrJSPhO9bhLSu/UJa0v7k8303sNANxPS/OaQ9b7X4kO6BTJ05pNihamfDerWZjRWtLvTrLTB VnmLdbIht/oPZ63pkp5e12TsmtxDugXMZ1NptjqrWTjhOJk/HK0UTlyo2ZDdfZL4RKxXZatY eoc2Rn9K3SUZaoPoxn1fd37tQnxzaHLAUT5Zfbhv7yPffawz8Ut/unSHN6IfGUZjNtGfV17B Ts4cS9GdlDt6Uj4pVZ48uzxpxqSEzzADCAnRBRCSdsCs/nwGAOSzcdHN5s/PA0Aqxn1zCBcV AESBc10AIaXtM8z5QPTfkcbnYcA6G98cynOT4KNg+AgUWKftdUtLp+akHcCu7Wd//w8PD2Z5 i5AW46JbWjr1+Ccf56opKbpv6YO5bkIaZH//L7l/Gbp6EeEy1TXtk6bDuW4CJAnRBRASogsg JEQXQEiTPLq6v7RgUixxgnC/M6r7qPVNA6SRpY9kLLl/mTr9/m9/bWsDS+5fZneV9EritxSJ 8Y+bW3/rNS2Xbfk9TxJ2Ptu36h7O+a6GbJo4upoDYnIcH0a/ZqwuMYpo4i/RJr4uJP6acWIx 68GecG9Pgj8HJCHJATPrDZbcv4zvFjSzmvLqQ4kTmmKaAta3oov/FcIJf2CNWA6V5jfl+J8+ 1Ay2dYulMpxO3CGa/4nxnkx6o5BvbNxzSEMzTjMZtlkc0fGPJq6Sb4PDpH9B2m5oNWcr/B7g ixntnPzZY5BeyX/9IPE4MHpR1z1iLB5J1rdiIq9ue2G3GUZ7iWU19XpAUOn85lB2Do78ueiV yor581ICgnIQQthPMaeL7hksP2u3u7C4FVtYP2z+RpGmJPtn/svmiWXU5fwvg6cltzhxvcZN 3Otqkjbh+C2xgO5DJsWS24ou/lYARhPWH9VdoruKleUWaXY+vwd0XyX5MiTXgxTInHF3P8ja N4cyccnkvqUPCv19Xfar9llO2idNh9c+uwtDdxHl4NNUuNQJkLocRBe5BUjdJP8MM8BkhegC CEl7k85ctyd5Ql+jUgn9J4DskCRJ5yadkyMA4sL+B4swYAYQiXpXMEQXQEgOkuw3hwAgh9Dr AggJ0QUQUvq/OQQAWYBeF0BIiC6AkBBdACEhugBCQnQBhIToAggJ0QUQEqILICREF0BIiC6A kBBdACEhugBCQnQBhJTO24VBNigKCQZJWJbCYaIoRFFIJEqiERKNkXic0DihlFBKJIlIEpEc xOEgLidxFZACF3G7idtNPR7iKSQ+H3G7c/1kIHmIbt4LBqXhYXJlhIyOkrExq2uxAJM4iRES IYSE1EckvlhRESkuJlNKaGkp8fnS12jIOEQ3LwVDUiBABgbI8HBmNzQ2RsbGyKVLV/NcWkrK y2lFBfF5M7tdSBmim09GRqXeXnK5j8SiuWnA8DAZHpa6uojTRaZX0qoqUlKcm5bARBDdPBCL SRc+J59/TqI5SmyiWJT09Eg9PcTlItdfT2deT5zOXLcJxkF0c2psTDp3ngQCuW6HsWiUnD8v nT9PKiro3DmkqCjXDYKrEN0cGRuTOs9m/FQ2jQIBKRAgpaW0Zj4CnA8Q3ayLx6W2dtLXl+t2 JGV4WDp6jFRW0hvqiAMfCsglRDe7enqljo5cNyJlfX1SXx+trSXVVbluyrUL0c0eqaU1r09r bZI6OsjAAK3HrQlzA2OerAiHpUNHJlNurwoEpENHSDic63ZcixDdzBsdlY40EUXOdTsyQ5Gl I01kdDTX7bjmILoZFgxJx47nuhEZJx07ToKhictB+iC6mUSpdM3cFEby+wmluW7FNQTRzSDp TBuRkxknf2/F9ydckro01ynL0pm2dFYIpnCFOWP6A6m8efu9Fd//yas/Vqc1S5Kr0HwradDX RyorybSKtFUIxtDrZop0/nx6K7SbMT6rfER/8uqP+el0NY9J+7MGI+h1M2NoyMZ3a8djkdN0 uXzGrHeVmvTabQPPasjHxsjQECkrs74tSA6imxFSf0pv4SbmRJMl6+n9yas/VsNvMb26lVvf otQfoIhu5mHAnBlXriS3nnpay8+yzGR0oJtOyT53sAXRzYxQGj5gxDo6zciZJOQ2xQvFRpev kq8xHc8dJoQBc2Yk9TMXLKuaiGpGqib9LZ83i8V0r12nMlomJMnnDnYhupnhdCVxBBvFgx8/ a65X8ROJ/fOEm0i8Bqa7dXvjcycOqmzAgDkzvJ60VKMJoeZSk3oOTMbn1ihpSZwhJ/PGb5qe O5hDdDNjypQ0Vpbek9s0VqIvrc8djLgIIQ0NDbluxmRDp1VIFy+mWInuaJZ1vEbv36gTiYPn 5D5cmURHTfFpqqzAaUlmlJWRoqKkP5VBJhqp8u8SqSUTL2vpXujSbCXpFuorKsLnMbIDA+ZM oXPmpLK6ldyqdBOYkzeBU3zWYJ2LEOL3+zFmTr9pFaSyMvWfjzPvGDXvJ1nvRY3eJU4sYyP5 +O5BFqHXzSC64AZSWJjEipp3WTXXkBNL6n61wMom0tkhFxbSBTekrTaYiOT3+wkhDQ0Nne0t 82sXnu1ozXWTJpdgSPrkk1w3IhvorbfiTkVZ8OG+vY9897HO9hb0uhnm89Kbb8p1IzKO3nwT cptliG7mFRfT228j7mRGzgJwF9LbbyPFuKtYtiG6WeHx0MW3k4pJdwmnooIuvp148PGpHEB0 s4fWL6S1tbluRdrQ2lr8fnoO4SMZ2VVdRWdMF/ieQwzuOZQHEN2sczjoFxeQ2bMEu9Mfgzv9 5Q1EN0eKiuiiGwW4v64K99fNM4huThUV0fqF+XhXexXuap+v8M2hPOB00jmzyZzZZGRU6u0l l/ty/0MTTheZXkmrqkgJ3vXJU+h180lJMS2pIbU1JBiSAgEyMJDtk+HSUlJeTisq8PmK/Ifo 5iWfl/pmklkzCSEkGJSGh8mVETI6msq3CPUVFZHiYjKlhJaWEp8vzZVDJuGbQ3nP56M+H6mu vjqrKCQYJGFZCoeJohBFIZEoiUZINEbicULjhFJCKZEkIklEchCHg7icxFVAClzE7SZuN/V4 iKeQ+HzE7c7pE4OUoNcVjdvNIoeb6l3j8K46gJAQXQAhIboAQkJ0AYSE6AIICdEFEBKiCyAk RBdASIgugJAcBN8cAhAQel0AISG6AEJyEELYDRAAQCDodQGEhOgCCAnRBRASogsgJJ1fyZhf i7tRAOQjSZL++Z9eYNP6P3CDu+wC5JsP9+3lZzFgBhASogsgJEQXQEiILoCQ8M0hACFZ7XVr 6uqtF+P/t1ibxfrTi99oTV19TtoAkJw03/2gs70lyyumRU1dfW4bAGBXkt8cUjsozYR5x6Xp 2RK76MRHE9fiF6prGbVHd6Oa2qy0HCDfZO+eQ2rPpgmSeXfHr6UpqVmuW5XmUd3C/HIAUSR5 hZkd7uqsrUOfL5mYRrUPVB9K4ixUXZ1VmGJtAHlIgDv9pdgfarpZ9K4wOST/vq46zrQ72jTv 9IwqtNhVJg4HkmgDQP7LXq+rhkqTLutr2dqW7urJ1QaQh6xGV/dYTxyC8ksSV+ETpbui7rZM Nq07Yd5y3Q0hySCcyfZBSFwrhmvEZIsucgvXiMkWXYBrBKILICQX0fvmkOanNAAg3+hcYZYk KfvtAABbdKKLKz0AeUsdEeOeQwBCwmUqACEhugBCQnQBhIQblwAIAzcuARAPblwCMBkgugBC QnQBhIToAggJ0QUQktV7Dqk/WZ6JH2rDj7wB2GXjZ+X4nzJO71cU8IUHALtSGjBPeEsRwt0W RPfuIbr/m5QEAMZFCPH7/RbHzGzC5I4hutMmdw9J3ITFkgDXOBu9bmd7C/tnfiMv3RUtLrde EuAal9JPqCNRALmShjeHkh7NWl8RA2YADRu9ruZcV/cmIPxw2mT0a/EOJsnd6wTgWpCGG5do ppO4UYjJfUwwJgfQlZubdE7YMydREuCakpvoJncfbQBQ4TPMAEJCdAGEpD9gxo1LAPKczj2H cOMSgPyHG5cAiGTcjUsAQDi45xCAkNDrAggJ0QUQEm5cAiAM3LgEQDy4cQnAZIDoAggJ0QUQ EqILICREF0BIiC6AkKzecwgA8gp6XQAhIboAQsI3hwCEhF4XQEiILoCQEF0AISG6AEJCdAGE hOgCCAnRBRASogsgJNy4BEBIOtHFjUsA8h9uXAIgEty4BEBsiC6AkBBdACEhugBCwo1LAISB G5cAiAc3LgGYDBBdACEhugBCQnQBhIToAgjJanRr6upNZvNQTV19/jcSIGmTs9etqavvbG/p bG9BemGySjW6rHNTE2IyYVKen00Mm26d5hvFl59g0tP/SIYu3VCpIeGnTSSWN5kwaobFjVps EoCIbESXj4HRQJSNUc2jpVnXSrVGVZlAbmFysxHdtOC71sRHETYAi9J/mUrteJPu9xK75SSu NuFVACa3lHpdPlQWo6KukhhI/iHdFY02qpttDJhhcrMaXU0M+CAZFTZKjsm61vOfxBKAyUSA 93XRfwIkEiC6yC1AIgGiCwCJEF0AIeHGJQBCwo1LAISEG5cAiGTcjUsaGhpy2hgAsA2XqQCE hOgCCMlBCPH7/bluBgDYg14XQEiILoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiI LoCQ8M0hACGh1wUQEqILICR8cwhASOh1AYSE6AIICdEFEBKiCyAkRBdASIgugJAQXQAh6dz9 YH7twuy3I5EkSZTSrG0L93wAsejfLuxsR2uW26Gh3p0hCy3BvdFARBgwAwgJ3xwCEBJ6XQAh IboAQsI3hwCEZKnXramrr6mr52etrDLhkuSwxqSrNgBB6b85lLdq6urVN2D5aYBrjdVz3c72 Ft2OdMIOMLEAvySVLpTllq+Kn9DUzC9MYlsA+Sb5XtdKB6gu5yOkLulsb7HbhfKvIOblE2tO nAAQl43ostgkd9DzkUvshO1Wpa7Iwm/0IqKpGXGFySQH57p8hBK7ZXPWXzvs1gwgFnvv6+qe 8VqRuQvOhBsOmAcbGYbJJPle18ppp1pGdyJx+YQ9qq1zXfNNAwjNUnT5Y91o2mgVkwnz5VYa o1loUjNCC5NMRs51LXaMSVfLQxrh2uQiGfjmUIYME65jAAADGUlEQVTilEq1SDhMMvj6AYCQ EF0AIbkIIX6/XzNmzp/ffMmflgDkFZ3LVJIkZb8duvKnJQD5Rie6uKIDkP9wrgsgJEQXQEiI LoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiILoCQEF0AISG6AEJCdAGEhOgCCAnR BRASogsgJEQXQEiILoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiILoCQEF0AISG6 AEJCdAGEpL1JJ25FDSCEcdHFragBRDEuurgpNoAocK4LIKSrvW53d3ckEpFlORaLRSIRRVEI IcFgcGBg4MqVKw8//DB7lFJqUpdmvB2JRPjZaDTKz8bjcX5WU7OmKtYei49qthuLxUw2xJNl mZ91OMa9rmkanMqspg3mj6Zx1uJDEz5qLnO7gv9TZm4vWd+HEz7q8Xj42aKiIn7W6/Wq0z6f r6urq7m5ecWKFSZJvPfee9mjra2tV6OrKMrIyEggEGClFUWhlIbD4Y6Ojs7OzuXLl4+Ojg4M DGhSYX5ubCu6Gpo9oqlKQxNdzYbMo8s3Q7OVVKKbq3BmJ7rmj2p2eIZ2VD7sw8QGa2YLCwv5 WZ/Px8/y0S0sLDx+/PiBAwceffRRkyTefffd7NGTJ0+6CCENDQ2nT58OBAKdnZ2hUCgajSqK EovFZFlubm7u7u6ORqP9/f1nzpwJhULW223+J7T1aCqz1g+OXB0N2ZnN3FZy8sKUn92s5lE+ nImzfJIdDkdTU9OJEycURTFJovroqVOnrva6R44caWpqOnfuXDgcZqVZSi9cuDA6Ojo2NjY4 OBgMBjX9W9bCaWvnmtP0pSZHg0bm/sCZezTpXjdrhdO4bibqSbHmgoICi7PRaDQSiUSjUfMk qo8eOXLkanRPnjx54sSJkZERlvVYLBYMBgkhoVAoEol861vf6unpYem1/qzSmLfsHOvmDdac HZjPaqTyaLpk7hUhlR1lflaieQV3Op1GK2qY16OJkPWNprhd86rY+Zp5EtVHg8Gg5Pf7CSEN DQ2EEHWaTQDkuYaGhsx1sHnu/wPur6N3B7/qtwAAAABJRU5ErkJggg== --------------010503000008060104000107 Content-Type: image/png; name="zh_CN.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="zh_CN.png" iVBORw0KGgoAAAANSUhEUgAAAT0AAAFPCAIAAACwE44AAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wYbCSwoU3MZxAAAIABJREFUeJzt3Xt0HNWB JvBb3S31Q2/JsiXbAhvLwrEDJIEsLGQhOwNOxpyQ2Sw+ZuYc4MTMMMPZ2QOxIcaG2NiyZRsb G1geh4zzYjabTHICLBCy4XgSG8z4hY0fkrAlGcluIcmW1Hp3d3V39d0/rqe4ru6qru6uftzW 9zs+PvW4VXW7VF/dW9WPks6dOzcxMTE8PBwOhwkhlNJwOKwoiqIo/KgsyxcuXOjq6mpubk6q /J49eyYnJ30+HyvPSJJE4uHLRCIRdTgajcYtTymNuywvFArFXSercOx6+G3x67TZbHHL6A3r rZOfnolhnlXT+X2Vb6/XzH7Qq7PT6VSHPR6POux2u9UCn3zyyYEDB375y19mNCZ8+ZkzZxJC QqFQf3+/XnlHKBQaHh7u6uqSZTkajXp7vWfPnB32XXK5XA1zrq6bXedxl0QiEVmWOzs7vV4v K7927dr+/n722ioqKtQBu93ONlBfXy9JktfrDYfDIyMj586dk2U54b7mj49kjxU+Y3wZfj18 Gb316x1/vGSPy1wdx2bOd8ke9/n8epPNrZpPzbCa4aKiok8//bSzs5Md9suWLZNl2W6319TU 1NTUhMPhmpoau91us9mKi4sXLVpUXV3d2tqqxuTosaMTo5OSJFVWVhCJRCKRaDQajUZlOTQy OmyzSY6ios+6utXyLIZ33XVXJBKx2+2vvfba2NhYNBqllCqKwsfQoShKOByWZXlycvKdd985 fOiQzSFdXVNGldDAhbNXXXVVY9NN7tISWZYDgUAwGGTlfT7fHXfcUeEpfvGVV23h8f3v/8E3 ODA8dOlif1/7p5+2t7Xd8O1vHz58OBgMslNFKBTi2z29XOntX70yZqbrDeu159k5tjZt2rR+ /Xp1enNz89NPP51afbZv3044TzzxhPlld+3a9YMf/CALrzf94Uz8jRwOR9xh/vzODl122FNK R0dH29rajh8/Pjp08VLfhYt9F0KBqbFRX2Q8tP+tg08/99OjR4+qMens6vjt737nKXbNnzf/ r769jBKqKEowKL/00ouVJdGrZ9ff/Jf38LGSZTkYDPp8vnfeeWdkZOR73/vez3/+c0VRotEo +z8YDLLyDnWnvPPuO0cOH55T61l0VZ3L5VQmR0YDgfHu031EXvjVb7G4q6/H4XDcsHjh/3zk 75SIvP+9t/7v737T33t++NJAJBKWJFLhtt92220fffRROByWJEmSJEqpmTbTzN/JzPRk+7FW Seq4aW5ufuqpp9jw008/vWXLlnXr1qWw0TVr1jz77LOUUvXq4/HHHze/+PPPP//YY4+lsF2T MtF+Zg07btXDZv78+S+//HJXV9fhA38e6vd6iiVXkeR0SEV2yS6RsmLpvvvu27NnjxqTYECe HBu3uyfGhzwHD/77jTfeKMvy88/vLrbR/zTH1TCv9pp5806fbFPLs235fL6enp4DBw5MTk7e c889b775phpdNYYOFipvr/fwocNzat1/vfS/3nLzV7vb2/t7Pxv19Qem5OClsxMXm2wVs2RZ ZjmklNbW1g5f7P3B/3i43/vZYN8FhxR1OSS3ndiLbJJEKCVut1stz46ndM6pVmU1nX5jRo+t zZs3U0q3bNny1FNPbdmyhRCiZnjr1q2EkLVr127duvXJJ58khGzbto3NWrNmDRtQ29gnnniC Urpjxw514s6dO9ms1atXs4HnnnuOELJq1Sp167t37yaE8A2vydebb3nTu2/CT+frxt+z0BuO RCKKorDDvr6+vru7+zvf+c6KFSuqq6vLyso8Hk9NTY3b7VYX4WNSUzmjqrxyZnFwln0gPFj0 728cHhgaayqTFs5zNjZ97d5/2nbs9Cm+PDtNFBUVRaPRQCBw8OBBSZLuueeet99+2+/3R6NR 1lUOh8MOWZZDodDxY8dsEpnfUH/LzV9b8Q/rjvxmx5/2fu4Ke4IkGIgEw4OnG65ZzHrnrPyt t946t6Fh8Y3/JRQKTUxM9PT0VFdXL1iwYO7cuWNjY1VVVWwb0WiUdZJZH13dF+nc20g2n3r3 n3J+LtdoaWnZsmULi25LSwuldN26dS0tLWvXrt22bRur7fbt2ymlTz75JOsbU0rV6Kp27Njx +OOPP/fcc5TS1atXr169eteuXazwqlWrdu3atWrVqt27d1NKWVAppY899tgLL7xAKX300UdT rr9eZvTK6O1/q6bz9M7XdrtdHeb7yWoIJUliy7LD/uDBg/v27fvZz35mcH3Lx+Sqqxv++/J7 //SnvVWukXllF53VlMwtk8NEqlv890+/9tGRI8ePHePLsxaVXV26XC5Jkj799FOPx/Pd7373 rbfempiYYO1tNBp1hEIhWZYvXDjvckgV7uKe9rbDv9nZd+ZYhV0mJVE/JS7FRaJjTU0Lfv// opRSVr6ysnJ4ePjSpUt+v//48ePOye5ZM6op/U5bW9vU1JSiKOz0oF7cso3F3Y+ZHhYLO7JZ u7p169aWlpZt27atWbPmySefVJvZ7du3//CHP2TH67PPPsvaWDaLDezcuZM1s7t27Vq9erU6 d/fu3bt27dq9e/eqVatWr179/PPP7969m22RZfjFF1+M22fOdMbMTDeTz2TLFBUVqcN8bvk8 S5Jks9nYYU8p7Th19JpF10UmvaGRgf1/ePvcmdNKyD/mG7SRqK/95JJ/eOn9999XYxIOh+fM nvvN2/9i4PA7s8pCbpdECAkGyaJlyw9/fPTI4YOsY8yXZ6NFRUUej8ftdhcXFw8MDBw6dMjp dI6OjqrlHazldbqc5cVUmRzt8577896+SntQkoMVjqDTRahCZEqvXbiQZY+VZyeG0dHR/fv3 X1Xif/Dum+pqKt48sDda/3X1koCVZxfc/EWCwd8jn69d9Vjehj/11FOa9fDdNsZut6tlNMPk ymZt586d6gUwvzi5snetzuIPX1Wu8pbO/jSzbMLcsr4rIYQd9vPnzz9y8MPXX9s13NfT+9mZ YhIqddpKim2uIqnYIZUWk/vuu2/Hjh2amFRVVZ0YHi5ZXP7IY39FCHn1+fckxXaq9TQfE748 IcTtdpeXl3s8nvr6+tra2qGhobq6uv7+frW8g9Xsxq/ddFQeHgn4q0YGXBE3KaUVdlkiUkWl S56it9xxz8DgoKIooVCIlVcUxefzHThwoKmavrT+sZl3/OPe7ctnyl2TQ2Si5ibyH1cF7B4y S7LoWdXrB8aGijFz7PLndYMV2u325uZmzRRNVhn14Fu3bh3rchNCnn32Wc0dL4fD0dLSok7k 1xC3Splo68zI9L1DPrdxdwJLkaIo7LCvr6/fd7R92bLlHo9H7/pWExNZDr7y8ks3VFJ/gL76 wntOV6U/QM6eOXvtoq+cPtU25R/WlI9Go1NTUyUlJTNmzGhoaKiqqiorKzt37lxra+uMGTPU WF2+L1VXV3f1VfPGuk8Hp+QgCQYodbpslZXO+79/+x/eaPv6g80t218OhULqBfTw8PAf//jH a2fYVn//3trbvtnzxtOnPzlqo0p1oNMTcJVf/99OnTrFyttsttj7Upl4v15POtdd6bQnCaer A5s2beIL8AfQxo0bWbFnnnnmmWeeYQPqghs2bCBXZthms6lvL61fv76lpcVms7HRH/3oR5RS 9j8bZf1won+Zl/C16Ml0O2nVevT6xmoI1bu47LA3c33LxyQUCr/86sszi+R5s92hWbcs+soN Y0ODoWh70ZnfykX0L7659O133+XLq/elKioqlixZMnv27GuvvXbPnj1tbW2NjY2sJqy8g118 ulzuxqYb+4gcvHQ2EAm6FBdRaHCK/uHttm893HLiVOfZjrNqRz8Sibz55psNpeG/W37vzSuW d7z1f44f+jAs+4uLHGVlrvpib3Hw+A33f//DDz+02WzsDGHQT04nw8nePzSTz+zcO9myZQv/ hi07UFijqhnetGkTyyfLLT+FELJx40a2fjbADr6NGzeqIedH7Xb75s2b7XY7K7xhwwY2nR2+ /LDBa0lHNq9fzNB7/5bvJzscDofjckwopRfPHqptvEm59PGlMycnff3+kQF7ZKr7s3NBeUiJ 7JWWbHzjjTfUmAwODzRU2RaVe752x1//05Yfv/vOe0Oh3pm3f10+9pto5++v/sY3/vZvVhw6 fEgtryazrKysoqLihhtu2LBhw/nz55uamtQQsRg6IpEIW8BdWrrwq0snLi6UB1vl0EAwYqub f8PStS+cbB/a85Ofsz1OKWXl7XZ7XXm0r+/z1zdsCIxe7OvpKHXabHZbaalrxX23/OuvD9Qs e5wvb3A/mWemXbUqq8lm2Ew9zWxLxW4aq6Ps7R/2Pz9l3bp169evV0fZIbV58+bYFbKJbJ2a frU6ygb4ufywpuXPKDP7ORP4beldIPC5tdlsrPmJRCLz58/3T03t+9cXX//n/+W2hcuKqCPq r3DbnMWOmTMr/uZv/zO59b7m5mb1sK+pqrrj5q/OLHM9suGV937/xz/v3xeNRufMnrv0wc20 690vfePWU+2XCBcTFk42WlxcvHLlyqGhoVtuuUV9/1aNoSMSiQSDQfU2dHH13LqFi5sWLLju S18e9I1sfe5/nzv3GaVU/dQIK3/99dfPnTdvalaDq6ampKjoK0tLwuFwZWUlpfSDiPv6R9a4 3W71vjarE/95Kf5vZuYzT+n0k9Ppb6fTJqeDX2dzczPLLSFk06ZNKd8qT3bBZHOV7Hkw2WsT /rLfzPrN3Hfgj7G4dVPv37LDvr6+fssrv1q2bNl9a17Vu77lY1JdNWveX67wuD3/8qtfHTt2 jHWDOzrPlpWVfv3Gb51qvxQORfnyLIa9vb2BQGDlypX19fW33XZbIBBQ86zG0DE4ONjZ2dnT 08M+V8zS9W//tl9tstXajI+Ph8NhVj4ajZ49e7a9vV0toFd+//79HR0dvb29wWBQ3S96+dQb 1pNshnmZaPP1mOkjGLjzzjvZwAcffJDUdnnJnpuS7ePo5Yr/O+p9tkGvPvzfiO/HprN+Hr9s 3PY2Go16vV5FUdhhX1pa6vV6X3nllYSHfdxYqeVbW1t/8bpueYfD8dFHHxUXF8+aNevs2bNx 1+84efLkiRMnJiYm2Oen1Etk9pEJfpS9v5Rs+V//+tf9/f0jIyN+vz/h3ymdHGbiWjTZdiPZ fGaif5ir16v3fSm9bOjlSm9Z/t5vJtavtyx7FzPTMeHLd3d3h8Ph8vJyr9erV14ihHR1tMV9 hQCQhxqbllzueyxYuDi3VQGAhCRJYq3sF9cM5zrbc1cfAEjgg3171eHE1+4AkG+QWwDxILcA 4kFuAcSD3AKIJ3FuG5uWqP9MrjSpwrmSwutSF0yzcMqbTrkaOdwKv4bU1pb/x1L2xfnSViz1 gxmNTUsSfkjDTJmc01Qy+3VOapcCaKTST2bnP/UsyLcbac7SnJvNj6aJT5FxxZJ6FZrCeps2 WJtmOO6rNlNnddRgN6ZWf2PsrKRZQ9w6xL5wfutocjVMtbfqXottJTQD7I8Ud1ZSA0mNWrUv +LVZ8gL5wua3rrdI3AJm6kz+4w+XcDemU3+T9Oqg98IzUYcCkFw/Oe4Ug3OhZpbBUnp/GP6P yk9ko1n4cxpvwuSrMCn2NcYe2WbWY74a1tY/duXqWUNzBoE0mcqtMYO/RGqzzJTPRHubAmu3 nnBtlr/YTO899G8zxLL3gcy3uiZnxS2QoaudNFeY/hVg3LXpdRGT3Wlm6pBUeZPrZD1t9R+u VC2Ubntr0GVNbVbcAsaj6VRbHdVMTNg95o9FM4VjJ2o2lOw+iX0h5leVVDFrOzV6f8q4UzJU hwJw+fu3CxYuxveBCgMO8UL1wb69Kx9+lJ3XErS3cXs1oh8Wel010V9XXsFOzqgEuS3IvVyQ L0qVJ68uT6pRqPD5ZADxILcA4vmin8z/CgYA5LPLuc3mD8YDQJou5xZ3EQAEgutbAPFY8Pnk fCD67z/jQy+QlELIbQF82AsfcoKkfJHbioqqHNZjOmN38rO//8fGRrK8RbDK5dxWVFR98vFH ua1Kyu5adm+uq2CB7O//pXcvRyMvKNyXmqY+Pno411WA1CG3AOJBbgHEg9wCiKdgcxv3NxMM isUOEO4nQuPONb9pAGsleP926d3L1eH3f//bpFa99O7lyS5irRR+CZHo/yK5+bdYLblJy+95 ErPz2b5V93DOdzVkmVFuNUdDYRwcer9CrE7Ry2fsj8jGnhRif4U4tpj5VCfc2wXw54DUJN1P Zu3A0ruX8w2CZlRTXp0VO6Appilgfitx8b8hmPAX0ojpRGl+FI7/4UJNHztusXR60bE7RPM/ 0d+TKW8U8lAqn3PUdM8MemsmO3L83NhF8q1PmPIvPyebWM1FCr8H+GJ6Oyd/9hhYLpXcxh4E eqfzuIeLycPI/FYM5NVTKpKtht5eYkFNfz0gLmu+V5CdIyN/7nKls2D+nEdAXFZ+H8ign8wk 21CY3EpSDK4wNYmK+9voxiuMu7hVv9WuwsUqGOVWE7OE3bbYAnFnGRRLbStx8T/erzdgfm7c KXEXMTPdJM3O5/dA3Bt7fBmS6+4JZNTl5xVk7ftAmbhHcteye4X+/i37Hfosx+zjo4fXPbMT PXYRNTYtyernpXBjE8ASWc0tQgtgiYL9fDJAAUNuAcTzxXM0c12T1Al9U0ol9J8AskOSJO1z NAvj6BcX9j+Yh34ygBj4J3ghtwDiQW4BxIPcAogHuQUQD3ILIB7kFkA8yC2AeJBbAPEgtwDi QW4BxIPcAogHuQUQD3ILIB7kFkA8yC2AeKz83XPILEUhwSCRZSKHpHCIhCMkHCaKQhSFKFES VQglhFJCKCESkSQiEWKzE7uN2O3EbidFRaTIQYuKibOYOJ3E5SJ2e65fEqQIuc1jfj+ZmpIm p0ggQAIBEo2aXpISSgklJBolkStmSPyIzUbcbuJ209ISUlJCPB5rqg2Zh9zmmfEJaWyMjI8T vz/j24pGydQUmZqShoYuT/F4SHk5ragg5WUZ3zqkAbnNA9EoGRqSfCNkYiLHNfH7id8vDQwQ QkhZGa2uIjNmEBtuguQd5DanBgelS4PZaFpTMDEhTUyQ8xeIx0Nn1pLa2lxXCL6A3OaC3y/1 DxCfL9f1MMfvl3rOk57zpLqa1tfhMjgfILfZNToq9X5OAoFc1yMlPp/k8xG3m86dQyorc12b aQ25zZaxMen8BSLLua5H2gIBqbOLOJ306qtIRUWuazNNIbeZFwxK3T1kcjLX9bCULEsdnaS0 lM6fR1yuXNdm2kFuM0vy9hJ2e7YgTU5Kp1tJXR1tmJvrqkwvyG3GBINSZxcJBnNdj8wbGJBG R+nCRjS8WYO35jJjeFg63TotQssEg9LpVjI8nOt6TBdob60n9fWRz/tyXYsckD7rJrJMZ8/O dUUKH9pbi0le7/QM7WWf90leb64rUfiQWytJn/eRgYu5rkWuDVyUpvOZKyuQW+sMDZM+HK+E EEL6+sgQrnUzCLm1SDAodXfnuhJ5ROrunka35bIOubWG1HM+11XIO9gnmYPcWsHnS/8reA88 +FDCKVbNTa1k0iYmhPnuhGjwPpAFJIvuRT3w4EOv/+In6rBmikH5uNmLu6z5kpaQBi7S6upM rHmaQ27TNjVFpqYytG6TcdIUY+FUI82fC17/xU80cw22EjfkySWc7ZySkiQWAROQ23RJI6Pp r0STn9g4aZpEg7zFXTbusPn68NOTbZylkVGK3FoN17dps+iLPnohYf+IfhdXM/r6L34Suyp1 ipnIGZwUDLrlugrsi1D5AblNWyDddzs0seRjw4dQzYymZGx006yPtetJf/9ALOQ2bZFI4jKm aRpMNTx8es00nsmmji/PNqHX/htvNw5L9w8wuL7NMf5eEYl3M4mYyEncJjfhvWjz5WNPH5Bb yG3aHA4SCae8dMKoxMZJbfT0bkElTJfB/ecUqpqAA8eY9dBPTpvb4i+LaxpPvjW2RGrxS72l tXr/AEFuLVBamom1xm0S+VmpXGrGMHlGSGsrmdk/0xxymy5aZeUvksZNY+y7L7E3rsysllz5 3pLB20sWsnb/AINrj7SVlJCSEks+MmV8JynudayZD0LEvdel2a5xrUjKTS7bOWA1tLcWoHWz LFlPsqHlC+hlL6lPXMTSvFecLKv2DGigvbVCdTW5NGjhU7kShiT2XaLUbl8lfIMn7l1rs8rK CL5UkBlob61B512d5ho0UVTTqClm8Nau3iIJN5qwm51aW53+PgE9EiGkq6NtwcLF5zrbc10Z wQ0N4ycvVHT+fDKjJte1KCgf7Nu78uFHuzraGpuWoL21zowagp8gZWbPRmgzCrm1Ep0zm+BO TN0sOgfnr8xCbi1GGxrIdD5q58ymDQ25rkThw/1k69HZs4nTKX027a516TXzSQ26x9mA3GZG TQ0tKZkuz/UihLhceK5XNqGfnDEuF73uy6SuLtf1yLy6OnrdlxHabEJ7m1m0YS6pnVGAz61m 8NzqHEFuM8/lol9aRMbGpPMXiCznujYWcTrp1VeRiopc12OaQm6zpaKCXn8dGR2Vej8ngUCu a5MGt5vOnUMq8S2fXEJus6uyklZWEr9f6h8Q77f8q6tpfR3xeHJdD0Buc8LjoQuuIQuuIYOD 0qVB4vfnukKGPB46s5bU1ua6HvAF5DanamtpbS2JRsnQkOQbsfAbRRYoK6PVVWTGDGLDmw55 B7nNAzYbmTmTzpxJCCHjE9LYGBkfz00j7PGQ8nJaUUHKy3KwdTANuc0z5WVUzYzfT6ampMkp EgiQQIBEoxZvy2Yjbjdxu2lpCSkpwYWrQJDbPObxEI+HqheWikKCQSLLRA5J4RAJR0g4TBSF KApRoiSqEEoIpYRQQiQiSUQixGYndhux24ndToqKSJGDFhUTZzFxOonLRez2nL48SB1yKw67 Xf25JprrukBu4ZYDgHiQWwDxILcA4kFuAcSD3AKI54r7yQsWLs5VPQDAgCRJP/3xC+qo9n0g /BorQL75YN9ezRT0kwHEg9wCiAe5BRAPcgsgHuQWQDzILYB4kFsA8STObWPTEjMrYsX4/02u zeT6rcVvtLFpSU7qAJAyy75/29XRluUFLdHYtCS3FQBIQdL9ZLVp0gwYN1maNi22cY6dG7sU P1FdSq8+cTeqWZuZmgPkoWz83oXapmlSZNzQ8UtpSmqmx12VZm7cwvx0AIEk3d6yY10dTeq4 50vGRlFt/dRZKVx5qouzFaa5NoD8lNe/L5VmS6hpYNGuQsFI5X0gtXuZbCfTuLnTW6HJRjK2 I5BCHQCEkI32Vk2UJlrml0pqW3EXT21tAPlJIoR0dbQtWLj4XGc7+z/XVUodbjJBQfpg396V Dz/60x+/sPLhR1kLVDifl0JoYfoonNwitDB9FE5uAaYP5BZAPMgtgHiQWwDxaN+/jf3FRwDI N1fkVpKkXNUDAMy7Ird4KwUgb/F9YVzfAogHuQUQD3ILIB7kFkA8eI4mgADwHE0AweA5mgCF ALkFEA9yCyAe5BZAPMgtgHiQWwDxILcA4jH1HE3+UVpxC6S8efwKOUAKTP3uOf+IHWu/64dv DgKkIMV+csInXBLuKZVxH2YZ93+DkgCgMtXeqskxeIBl3GGDh1nGbsJkSQAw1d52dbSxf8ZP lI67oMnp5ksCQIrP9UKcAHIorfeBUu7Eml8Q/WSAWKlc38Z9JiXfizbo9Jp8oGZqj94EmCYS 5zZuCDWJjVvSfBkzJQFAlY3nVvMStskplASYbrKdW/MhRFwB9ODzyQDiQW4BxIPcAogHuQUQ D56jCSAePEcTQDx4jiaAGPAcTQCxIbcA4kFuAcSD3AKIB8/RBBAAnqMJIBg8RxOgECC3AOJB bgHEg9wCiAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEg9wCiAe5BRAPcgsgHuQWQDzI LYB4kFsA8SC3AOJBbgHEg9wCiAe5BRAPcgsgHjxHE0A8eI4mgHjwHE0AMeA5mgBiQ24BxIPc AogHuQUQD56jCSAAPEcTQDB4jiZAIUBuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHgS57axaYnB aB5qbFqS/5UESEehtbeNTUu6Otq6OtoQXShgqeeWNWtqPAwGDMrzo7FJi7tO443iK8QwHWg/ 5xhX3ESpCeGHDcSWNxjQq4bJjZqsEoCgTOWWz4Be/5N1TY1zpVnWzGr1VmUAoYWCZyq3luAb 1di5SBqAeVbel1Kb3JRbvNgGOYXbSzgFQMFLsb3lE2UyJ+oisWnkZ8VdUG+jcYONfjIUvMS5 1WSAT5FeYb3YGCxrPvwpTAEoMHn9/i1aToC48jq3CC1AXHmdWwCIC7kFEA9yCyAe5BZAPHiO JoB48BxNAPHgOZoAYsBzNAHEhtwCiAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEg9wC iAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEc8XvXSxYuDhX9eBJkkQpzdq28CsfIBzt 78Kd62zPST1U6o9xZKEm+BE8EBT6yQDiQW4BxIPcAogHuQUQD3ILIJ4EuW1sWtLYtIQfTbjG 2DJmljKDVcaqtQGIS/s+UN7inz2P59DDNJe4n9zV0Ra3CU3Y9MUW4Kek03iy0PKr4gc0a+Yn prAtgDyUSntrpulTp/P5Uad0dbQl23jypw/j8rFrjh0AEJqp3LLMpHbE83mLbX6TXZW6IEu+ 3hlEs2ZkFQpMVq9v+fzENsjGzJ84kl0zgHDMvg8U9yrXjMzdXiZcR8A41QgwFJhU2lszl5pq mbgDsdMTtqVJXd8abxpAdAlyyx/oesN6ixgMGE83UxnNRIM1I7FQeCy+vjXZJKa8Wh6iCNOW xbnNUJbSWS3iDYUHn08GEA9yCyAebT85f366JX9qApBvrsitJEm5qodG/tQEIA9dkVvcwgEQ Aq5vAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHiQWwDJ/2rfAAACqElEQVTxILcA4kFuAcSD3AKI B7kFEA9yCyAe5BZAPMgtgHiQWwDxILcA4kFuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHiQWwDx ILcA4kFuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHi+eI4mnhMNIIrLucVzogEEcjm3eGI1gEBw fQsgHsnr9YbDYVmWFUUJh8OhUIgQ4vf7fT7f+Pj4/fffz+ZSSo3WcmU3OxwO86ORSIQfjUaj /KhmzZpVsfqYnKvZrqIoBhviybLMj9psV5zONBVOZ1RTB+O5Fo6anJVwrrHM7Qr+T5m5vWR+ Hyac63K5+NGSkhJ+1O12q8Mej6e7u7u1tfWRRx4xSOKdd97J5ra3t4+PjztCodDExMTw8DAr GgqFKKXBYLCzs7Orq2vFihWTk5M+n08TCePr4aRyq6HZHZpVaWhyq9mQcW75ami2kk5uc5XM 7OTWeK5mh2doR+XDPoytsGbU6XTyox6Phx/lc+t0Oj/55JMDBw489NBDBkm8/fbb2dyTJ092 dXU5QqHQ8PBwV1dXIBCIRCKhUEhRFFmWW1tbvV5vJBIZGho6c+ZMIBAwX2njv19Sc9MZNX9k 5OpQyM5o5raSk7NSfjawmrl8MmNH+RjbbLajR4+eOHHCOInq3FOnTnm9XseRI0eOHj3a09MT DAZZURbR3t7eycnJqampkZERv9+vadmylsyk9qwxTStqcChoZO6vm7m5Kbe3WSts4bKZWE+a ay4qKjI5GolEwuFwJBIxTqI698iRI5OTk46TJ0+eOHFiYmKCpVxRFL/fTwgJBALhcPiBBx7o 7+9n0TX/kiwMW3YOdOMKay4KjEc10plrlcydDtLZUcYXI5rTt91u11tQw3g9mvyY32ia2zVe FbtMM06iOtfv94fD4f8PcKaec5T2mGIAAAAASUVORK5CYII= --------------010503000008060104000107-- From morwen@evilmagic.org Fri Jun 27 09:32:54 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by mail.gnome.org (Postfix) with ESMTP id 28C28183AD for ; Fri, 27 Jun 2003 09:32:54 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030627133252.SDSC21249.mta01-svc.ntlworld.com@ganymede.arrow>; Fri, 27 Jun 2003 14:32:52 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganymede.arrow (8.11.2/8.11.2) with ESMTP id h5RDWb302018; Fri, 27 Jun 2003 14:32:37 +0100 Subject: Re: Unexpected font rendering with pango From: Abigail Brady To: stephan.hegel@gmx.de Cc: gtk-i18n-list@gnome.org In-Reply-To: <3EFC3811.2090705@gmx.de> References: <3EFC3811.2090705@gmx.de> Content-Type: text/plain Organization: Message-Id: <1056720756.1971.3.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 27 Jun 2003 14:32:37 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 13:26, Stephan Hegel wrote: > Recently I have found an unusual behaviour in Chinese font rendering > with Pango.Please have a look at the attached, little screenshots. The > only difference between both is the setting of the locale before starting > the application. The first one uses LC_ALL=en_US and the second one > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing > antialiasing - fine on the second pix, but not o.k. in the first > case. It somehow uses a different size of fonts in just one string ... > > Anyone out there who has an idea or a hint how to track this and/or to > fix this ? It's doing this because of the preference order of the fonts. With en_US its picking up a japanese or korean font first, and using that to display any characters it has support for - and only then moving to the chinese font. When in the chinese locale, it knows to use chinese fonts first... So you'll need to fiddle with the config files. -- Abi From pablo@mandrakesoft.com Fri Jun 27 11:45:11 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chanae.alphanet.ch (212-100-178-141.adsl.easynet.be [212.100.178.141]) by mail.gnome.org (Postfix) with ESMTP id 0033418587 for ; Fri, 27 Jun 2003 11:45:10 -0400 (EDT) Received: (from srtxg@localhost) by chanae.alphanet.ch (8.9.0/8.9.0) id RAA19301 for gtk-i18n-list@gnome.org; Fri, 27 Jun 2003 17:52:27 +0200 Date: Fri, 27 Jun 2003 17:52:27 +0200 From: Pablo Saratxaga To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango Message-ID: <20030627155227.GA19166@chanae.alphanet.ch> Mail-Followup-To: Pablo Saratxaga , gtk-i18n-list@gnome.org References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <1056720756.1971.3.camel@ganymede.arrow> User-Agent: Mutt/1.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kaixo! On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote: > > Recently I have found an unusual behaviour in Chinese font rendering > > with Pango.Please have a look at the attached, little screenshots. The > > only difference between both is the setting of the locale before starti= ng > > the application. The first one uses LC_ALL=3Den_US and the second one > > LC_ALL=3Dzh_CN.GB2312. The font rendering is - despite the missing > > antialiasing - fine on the second pix, but not o.k. in the first > > case. It somehow uses a different size of fonts in just one string ... > >=20 > > Anyone out there who has an idea or a hint how to track this and/or to > > fix this ? >=20 > It's doing this because of the preference order of the fonts. With > en_US its picking up a japanese or korean font first, and using that to > display any characters it has support for - and only then moving to the > chinese font. When in the chinese locale, it knows to use chinese fonts > first... So you'll need to fiddle with the config files. The problem is that it is using a *non scalable* font at a *wrong size*. Imho pango (well, Xft actually I think) should first look at scalable fonts, and only if no scalable fonts are found ressort to non scalable ones, if that is already doable trough a config option, then I would be interested to know what option it is, in order to enable that by default. It is simply too bad that a single text get in mixed sizes, just because the first matching font is used, without checking it has the character=20 at the right size. Such an output is acceptable if the only other alternative would be to display an empty square, but that is not the case here. Even worst: the first character of the paragraphe is a traditional chinese one, and taken from a traditional chinese font; imho in such case=20 pango should continue with the same font as long as possible, instead of switching to the default one for the next (for every?) character (that behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it makes sense to stick when the same font as long as possible; that is, if a given character was not on the default font, nor in the first CJK font ('ja' or 'ko' covering one in this case), and was on another CJK font, then it should stick with that one, as it is likely that other characters w= ill be in the same case. Following that ordering will give a much better output in all cases of normal CJK text. But if that is too complex to do, pango must at least give priority to scalable fonts, having a word with some letters near 3 or 4 times the size of some others is horrendous. --=20 Ki =E7a vos v=E5ye b=E9n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portugue= se] --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/GhQpSX1mtm4VGYRAn2cAJ9pNE4F7/8K768x4noZ3dem7uyISQCaA8L/ DmDwmnCOlRzB/aZ2XfJNljA= =Fddk -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From otaylor@redhat.com Fri Jun 27 15:16:57 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 03D6618389 for ; Fri, 27 Jun 2003 15:16:57 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5RJGqK30609; Fri, 27 Jun 2003 15:16:52 -0400 Subject: Re: Unexpected font rendering with pango From: Owen Taylor To: Pablo Saratxaga Cc: gtk-i18n-list@gnome.org In-Reply-To: <20030627155227.GA19166@chanae.alphanet.ch> References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> <20030627155227.GA19166@chanae.alphanet.ch> Content-Type: text/plain Message-Id: <1056741412.6045.10.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 27 Jun 2003 15:16:52 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 11:52, Pablo Saratxaga wrote: > Kaixo! > > On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote: > > > > Recently I have found an unusual behaviour in Chinese font rendering > > > with Pango.Please have a look at the attached, little screenshots. The > > > only difference between both is the setting of the locale before starting > > > the application. The first one uses LC_ALL=en_US and the second one > > > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing > > > antialiasing - fine on the second pix, but not o.k. in the first > > > case. It somehow uses a different size of fonts in just one string ... > > > > > > Anyone out there who has an idea or a hint how to track this and/or to > > > fix this ? > > > > It's doing this because of the preference order of the fonts. With > > en_US its picking up a japanese or korean font first, and using that to > > display any characters it has support for - and only then moving to the > > chinese font. When in the chinese locale, it knows to use chinese fonts > > first... So you'll need to fiddle with the config files. > > The problem is that it is using a *non scalable* font at a *wrong size*. > Imho pango (well, Xft actually I think) should first look at scalable fonts, > and only if no scalable fonts are found ressort to non scalable ones, > if that is already doable trough a config option, then I would be interested > to know what option it is, in order to enable that by default. I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd have to have a very exotic configuration (basically, no scalable CJK fonts) to get those results with fontconfig/Xft. > It is simply too bad that a single text get in mixed sizes, just because > the first matching font is used, without checking it has the character > at the right size. Such an output is acceptable if the only other > alternative would be to display an empty square, but that is not the case > here. > > Even worst: the first character of the paragraphe is a traditional chinese > one, and taken from a traditional chinese font; imho in such case > pango should continue with the same font as long as possible, instead of > switching to the default one for the next (for every?) character (that > behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it > makes sense to stick when the same font as long as possible; that is, > if a given character was not on the default font, nor in the first CJK > font ('ja' or 'ko' covering one in this case), and was on another CJK font, > then it should stick with that one, as it is likely that other characters will > be in the same case. Following that ordering will give a much better > output in all cases of normal CJK text. Unfortunately, you can't autodetect traditional vs. modern Chinese, so I don't think we'll ever be able to do much better than supplied language tag for that situation... if you have a section of text that has only shared characters, it's going to get one or the other font arbitrarily. For other languages, there is possibility of improvement - see http://bugzilla.gnome.org/show_bug.cgi?id=112503. For Stephan, there is a easy solution ... since the app knows the language of the text it is displaying, it can explicitely set the language tag, and override the language tag of the locale. Regards, Owen From pablo@mandrakesoft.com Fri Jun 27 16:26:23 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chanae.alphanet.ch (212-100-178-141.adsl.easynet.be [212.100.178.141]) by mail.gnome.org (Postfix) with ESMTP id 4DE3118FA5 for ; Fri, 27 Jun 2003 16:26:22 -0400 (EDT) Received: (from srtxg@localhost) by chanae.alphanet.ch (8.9.0/8.9.0) id WAA25904 for gtk-i18n-list@gnome.org; Fri, 27 Jun 2003 22:33:40 +0200 Date: Fri, 27 Jun 2003 22:33:40 +0200 From: Pablo Saratxaga To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango Message-ID: <20030627203340.GB24947@chanae.alphanet.ch> Mail-Followup-To: Pablo Saratxaga , gtk-i18n-list@gnome.org References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> <20030627155227.GA19166@chanae.alphanet.ch> <1056741412.6045.10.camel@poincare.devel.redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline In-Reply-To: <1056741412.6045.10.camel@poincare.devel.redhat.com> User-Agent: Mutt/1.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kaixo! On Fri, Jun 27, 2003 at 03:16:31PM -0400, Owen Taylor wrote: > I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd probably. > > one, and taken from a traditional chinese font; imho in such case=20 > > pango should continue with the same font as long as possible, instead of > > switching to the default one for the next (for every?) character (that > Unfortunately, you can't autodetect traditional vs. modern Chinese, so I idn't mean that. I meant, if a char "X" is searched in first font, and not found there then found in the second font; then, when displaying the second char "Y", first look at the last used font (the second) instead of looking again at the first, then second. If the search was done like that for CJK (only for CJK, as for latin, greek, and cyrillic it won't be desirable) then a text will be properly displayed in most cases; at worst only the few chars at the begining of the text will be in a different style; not a mixed style in all the document. In the particular case shown in the examples, it would have given a correct display, that is the same display that in the chinese locale.=20 Is such behaviour doable ? It would be a big improvement imho. --=20 Ki =E7a vos v=E5ye b=E9n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portugue= se] --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/Ko5pSX1mtm4VGYRAmidAJ0bHr8/eIYufQ5aPFZtdDws0y1UMgCfai21 3/EbR70DpOnbrXuDYMi+JNo= =8BqY -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From keithp@keithp.com Fri Jun 27 17:21:51 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from localhost (unknown [63.227.221.253]) by mail.gnome.org (Postfix) with ESMTP id 11A0318FDA for ; Fri, 27 Jun 2003 17:21:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=keithp.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19W0ex-0001aT-00; Fri, 27 Jun 2003 14:21:31 -0700 X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev To: Pablo Saratxaga Cc: gtk-i18n-list@gnome.org, Keith Packard Subject: Re: Unexpected font rendering with pango From: Keith Packard In-reply-to: Your message of "Fri, 27 Jun 2003 22:33:40 +0200." <20030627203340.GB24947@chanae.alphanet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 14:21:29 -0700 Message-Id: Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Around 22 o'clock on Jun 27, Pablo Saratxaga wrote: > I meant, if a char "X" is searched in first font, and not found there > then found in the second font; then, when displaying the second char "Y", > first look at the last used font (the second) instead of looking again > at the first, then second. And if the characters are in the opposite order, you'll still get 'ransom note' typography. A particular counter example is a document which is largely in English but which happens to start with a Japanese glyph. With a 'sticky font' mechanism, the whole document will be rendered with a Japanese font. The current mechanism is also designed to be 'stable' so that the glyphs selected for any particular character don't change as the document is edited; this makes layout significantly easier. The correct solution is to inform the font system what languages are in use so that appropriate fonts can be selected. -keith From keithp@keithp.com Fri Jun 27 18:03:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from localhost (unknown [63.227.221.253]) by mail.gnome.org (Postfix) with ESMTP id 0D5F318FDB for ; Fri, 27 Jun 2003 18:03:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=keithp.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19W1Iu-0001bw-00; Fri, 27 Jun 2003 15:02:48 -0700 X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev To: Eric Mader Cc: Keith Packard , Pablo Saratxaga , gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango From: Keith Packard In-reply-to: Your message of "Fri, 27 Jun 2003 14:37:26 PDT." <3EFCB916.1050702@bigfoot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 15:02:48 -0700 Message-Id: Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Around 14 o'clock on Jun 27, Eric Mader wrote: > It might also make sense to take the language into account too; possibly > with a notion of what characters are used to write a given language in a > given script. I haven't thought about that enough to say for sure. That's precisely what fontconfig does. It calculates language coverage based on Unicode coverage of language orthography. It's a relatively straightforward technique aside from the collection of language orthographies; fontconfig is still missing orthographies for 17 of the 139 languages in ISO 639-1. > Another point: for complex text like Arabic and Hindi, you really, > really want to try and keep it all in the same font, because that's the > only way to get the correct contextual behavior. Arabic is not horribly problematic as most fonts provide coverage for most languages. One issue for Arabic is that newer fonts are less likely to include the presentation forms and are starting to expect shapers to perform compositing. That may require some additional information for font matching. I've seen significantly more trouble with languages presented in Latin or Cyrillic scripts where the lack of a language tag often results in uncommon glyphs being presented in an unexpected font. If an application wants to ensure that a complete document is presented in a single font, it can pass the set of Unicode values from the document to the font selection mechanism and request a single font covering those values. Language tags simply provide a convenient shorthand for this mechanism. -keith From stephan.hegel@gmx.de Sat Jun 28 20:24:45 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id DF74418926 for ; Sat, 28 Jun 2003 20:24:44 -0400 (EDT) Received: (qmail 18026 invoked by uid 65534); 29 Jun 2003 00:24:42 -0000 Received: from unknown (EHLO gmx.de) (61.155.124.129) by mail.gmx.net (mp027) with SMTP; 29 Jun 2003 02:24:42 +0200 Message-ID: <3EFE316D.9080609@gmx.de> Date: Sun, 29 Jun 2003 08:23:09 +0800 From: Stephan Hegel Reply-To: stephan.hegel@gmx.de Organization: Private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en, de, zh-CN MIME-Version: 1.0 To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango References: <20030628160014.14571.48469.Mailman@moniker.gnome.org> In-Reply-To: <20030628160014.14571.48469.Mailman@moniker.gnome.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi all, Thanks for the quick replies. Here just a few more notes on the issue. 1. The mentioned application lingoteach is not my work, I have just downloaded it from freshmeat since I'm looking for a vocabulary trainer what is able to display Simplified Chinese chars. However, I will have deeper look into it to figure out how it is done, but it looks like the apps uses only gtk_set_label calls. 2. A language tag as proposed by Owen is certainly a good solution to display a consistent, nice looking layout. However the mentioned application allows to add new languages and one doesn't know in advance what the user want to add. 3. I do use fontconfig/Xft. At least pango is telling me that when I configure it. checking for fontconfig >= 1.0.1... yes checking FONTCONFIG_CFLAGS... -I/usr/local/include checking FONTCONFIG_LIBS... -L/usr/local/lib -lfontconfig checking for freetype-config... /usr/bin/freetype-config checking for FT_Get_Next_Char in -lfreetype... yes checking for xft >= 2.0.0... yes checking XFT_CFLAGS... -I/usr/local/include -I/usr/include/freetype2 -I/usr/X11R6/include checking XFT_LIBS... -L/usr/local/lib -L/usr/X11R6/lib -lXft -lfreetype -lz -lXrender -lfontconfig ... configuration: backends: FreeType X Xft The shared libraries are all available, finally: libpango, libpangoft2, libpangox, and libpangoxft. 4. Beside Arial Unicode MS, there are other TTF Simplified Chinese fonts available on the system like MsSong, MsHei, SimHei, etc. xlsfonts and fc-list reports them all. I would like to find out what font is really selected by what backend in this application. Is there a simple log/trace/track mechanism available in Pango (kind of environment variable or whatever) which can be easily activated ? Thanks & regards, Stephan. From morwen@evilmagic.org Sun Jun 29 05:39:25 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by mail.gnome.org (Postfix) with ESMTP id 7119018655 for ; Sun, 29 Jun 2003 05:39:25 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030629093925.XPQR18592.mta07-svc.ntlworld.com@ganymede.arrow> for ; Sun, 29 Jun 2003 10:39:25 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganymede.arrow (8.11.2/8.11.2) with ESMTP id h5T9d4f01372 for ; Sun, 29 Jun 2003 10:39:05 +0100 Subject: Re: Unexpected font rendering with pango From: Abigail Brady To: gtk-i18n-list@gnome.org In-Reply-To: <3EFE316D.9080609@gmx.de> References: <20030628160014.14571.48469.Mailman@moniker.gnome.org> <3EFE316D.9080609@gmx.de> Content-Type: text/plain Organization: Message-Id: <1056879544.1119.2.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Jun 2003 10:39:04 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Sun, 2003-06-29 at 01:23, Stephan Hegel wrote: > 3. I do use fontconfig/Xft. At least pango is telling me that when > I configure it. > > checking for fontconfig >= 1.0.1... yes > checking FONTCONFIG_CFLAGS... -I/usr/local/include > checking FONTCONFIG_LIBS... -L/usr/local/lib -lfontconfig > checking for freetype-config... /usr/bin/freetype-config > checking for FT_Get_Next_Char in -lfreetype... yes > checking for xft >= 2.0.0... yes > checking XFT_CFLAGS... -I/usr/local/include -I/usr/include/freetype2 > -I/usr/X11R6/include > checking XFT_LIBS... -L/usr/local/lib -L/usr/X11R6/lib -lXft -lfreetype > -lz -lXrender -lfontconfig > ... > configuration: > backends: FreeType X Xft > > The shared libraries are all available, finally: > libpango, libpangoft2, libpangox, and libpangoxft. All this is telling you is that Xft was built, not that you are using it. Have you set GDK_USE_XFT? -- Abi From emader@bigfoot.com Fri Jun 27 17:37:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mail.gnome.org (Postfix) with ESMTP id AECFD1810B for ; Fri, 27 Jun 2003 17:37:29 -0400 (EDT) Received: (qmail 31091 invoked from network); 27 Jun 2003 21:37:28 -0000 Received: from unknown (HELO bigfoot.com) (emader@[66.93.135.240]) (envelope-sender ) by mail9.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Jun 2003 21:37:28 -0000 Message-ID: <3EFCB916.1050702@bigfoot.com> Date: Fri, 27 Jun 2003 14:37:26 -0700 From: Eric Mader User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Packard Cc: Pablo Saratxaga , gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: You can make the font 'sticky' only for that script. In general, it seems to be a good idea to try and display all characters in a given script in the same font. It might also make sense to take the language into account too; possibly with a notion of what characters are used to write a given language in a given script. I haven't thought about that enough to say for sure.. Another point: for complex text like Arabic and Hindi, you really, really want to try and keep it all in the same font, because that's the only way to get the correct contextual behavior. Regards, Eric Mader IBM GCoC - San José 5600 Cottle Rd. M/S 50-2/B11 San Jose, CA 95193 Keith Packard wrote: > Around 22 o'clock on Jun 27, Pablo Saratxaga wrote: > > >>I meant, if a char "X" is searched in first font, and not found there >>then found in the second font; then, when displaying the second char "Y", >>first look at the last used font (the second) instead of looking again >>at the first, then second. > > > And if the characters are in the opposite order, you'll still get 'ransom > note' typography. > > A particular counter example is a document which is largely in English but > which happens to start with a Japanese glyph. With a 'sticky font' > mechanism, the whole document will be rendered with a Japanese font. > > The current mechanism is also designed to be 'stable' so that the glyphs > selected for any particular character don't change as the document is > edited; this makes layout significantly easier. > > The correct solution is to inform the font system what languages are in use > so that appropriate fonts can be selected. > > -keith > > > _______________________________________________ > gtk-i18n-list mailing list > gtk-i18n-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-i18n-list > > From otaylor@redhat.com Sun Jun 29 11:55:41 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DFF921835F for ; Sun, 29 Jun 2003 11:55:40 -0400 (EDT) Received: from vpn50-32.rdu.redhat.com (vpn50-32.rdu.redhat.com [172.16.50.32]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5TFtaK03645; Sun, 29 Jun 2003 11:55:36 -0400 Subject: Re: Unexpected font rendering with pango From: Owen Taylor To: Eric Mader Cc: Keith Packard , Pablo Saratxaga , gtk-i18n-list@gnome.org, morwen@evilmagic.org In-Reply-To: <3EFCB916.1050702@bigfoot.com> References: <3EFCB916.1050702@bigfoot.com> Content-Type: text/plain Organization: Message-Id: <1056902111.15837.55.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 29 Jun 2003 11:55:12 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 17:37, Eric Mader wrote: > You can make the font 'sticky' only for that script. In general, it > seems to be a good idea to try and display all characters in a given > script in the same font. It might also make sense to take the language > into account too; possibly with a notion of what characters are used to > write a given language in a given script. I haven't thought about that > enough to say for sure.. This is basically what http://bugzilla.gnome.org/show_bug.cgi?id=112503 is about. Once we have script run information for shaper selection, we need to push it into the font selection algorithm in some fashion, for one thing, because shapers are only fed runs of glyphs in the same font. (The other thing that needs dealing with is dealing omitting non-rendering characters such as ZWJ from font selection to avoid having them break runs... fonts shouldn't have to claim to cover these languages) The language is already taken into consideration by fontconfig - it orders fonts returned by how well they match the language tag, and I think that will automatically carry over into any future script-run based system ... as long as we select fonts in the order that fontconfig returns them, we'll get the best font for the current language. I used to worry about font selection algorithms where subsequent characters could affect previous characters, figuring that would seem confusing while editing, but I've stopped worrying about that. For one, thing, it only matters if the font you have selected doesn't itself include all the characters in the language you are typing. It certainly doesn't make layout harder in any fundamental way since Pango never lays out less than a paragraph at a time. There *is* some question in my mind whether script-range font selection should apply to anything other than COMMON/INHERITED characters. - Pro: it's the only way that ransom-note effects will be reduced for wrong-tagged text for CJK or Roman where fonts commonly don't cover the entire script range. - Con: it can actually make things worse because it means that a single foreign name might throw an entire paragraph of text into a different font. In fact, I think the Con: here wins ... yes, script-run consideration for font selection is important, but no it shouldn't be used to fix problems like the one that started this thread. Regards, Owen [ Abi - since you asked for suggestions of things to work on, I think 91542/112503 is the most serious problem that Pango has at the moment. Assignment of ZWJ/ZWNJ to the wrong shaper has serious consequences for the correct rendering of Farsi and Indic languages. And, I think it's also likely fairly *interesting* to work on, which is definitely an added bonus ] From otaylor@redhat.com Sun Jun 29 12:24:22 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D5F71183EA; Sun, 29 Jun 2003 12:24:21 -0400 (EDT) Received: from vpn50-32.rdu.redhat.com (vpn50-32.rdu.redhat.com [172.16.50.32]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5TGOLK05478; Sun, 29 Jun 2003 12:24:21 -0400 Subject: [admin] List rules and FAQs added to www.gtk.org From: Owen Taylor Reply-To: gtk-list@gnome.org To: gtk-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-doc-list@gnome.org, gtk-i18n-list@gnome.org, gtk-devel-list@gnome.org Content-Type: text/plain Organization: Message-Id: <1056903836.15837.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 29 Jun 2003 12:23:56 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: I just added a short "List Rules and FAQs" section to http://www.gtk.org/mailinglists.html. Nothing there should be that surprising to current list members, but it wouldn't hurt to take a quick look. If you have any comments or suggestions for additional material which would be useful there, please let me know. Regards, Owen From jshin@mailaps.org Sun Jun 29 13:08:08 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from atlas.jtan.com (atlas.jtan.com [207.106.84.159]) by mail.gnome.org (Postfix) with ESMTP id 8926318A29 for ; Sun, 29 Jun 2003 13:08:07 -0400 (EDT) Received: from callisto.jtan.com (root@callisto.jtan.com [207.106.84.134]) by atlas.jtan.com (8.12.8p1/8.12.8) with ESMTP id h5TH86uN000310 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 29 Jun 2003 13:08:07 -0400 (EDT) Received: from callisto.jtan.com (jshin@localhost [127.0.0.1]) by callisto.jtan.com (8.12.1/8.12.1) with ESMTP id h5TH84OW013528 for ; Sun, 29 Jun 2003 13:08:04 -0400 (EDT) Received: from localhost (jshin@localhost) by callisto.jtan.com (8.12.1/8.12.1/Submit) with ESMTP id h5TH834w013202 for ; Sun, 29 Jun 2003 13:08:04 -0400 (EDT) X-Authentication-Warning: callisto.jtan.com: jshin owned process doing -bs Date: Sun, 29 Jun 2003 13:08:03 -0400 (EDT) From: Jungshik Shin X-X-Sender: To: Subject: Re: Unexpected font rendering with pango In-Reply-To: <1056902111.15837.55.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On 29 Jun 2003, Owen Taylor wrote: > (The other thing that needs dealing with is dealing omitting > non-rendering characters such as ZWJ from font selection to > avoid having them break runs... fonts shouldn't have to claim to > cover these languages) You meant 'claim to cover these characters', didn't you? If that's what you meant, it may not be so clear-cut for some 'invisible' characters. For characters like 'invisible times' (sorry I forgot the code point, it's somewhere in U+206x? or can be easily found in 'Default_Ignorable' list at Unicode ftp site) and 'invisible apply a function to'(?), there's no question that they should be ignored. [1] It gets a bit murky for ZWJ and ZWNJ (or CGJ).Some opentype fonts have to claim to cover characters like ZWJ and ZWNJ because ZWJ and ZWNJ take part in glyph substitutions (via GSBU look-up) and their presence and absence affect the rendering result. [1] Some aggressive fonts have visible glyphs for truly invisible characters. In presence of those fonts, not taking 'truly invisible' characters into account in font selection is essential to prevent the visible glyph of 'invisible times' from one of those fonts from popping up in the middle of a text-run rendered with another font. Jungshik From vivek@lantana.tenet.res.in Tue Jun 3 01:40:39 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 8939618A4D for ; Tue, 3 Jun 2003 01:40:34 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h535df530262 for ; Tue, 3 Jun 2003 11:09:44 +0530 Subject: utf-8 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-huysmgQWAktM7Ldxz9Kk" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jun 2003 11:10:40 +0530 Message-Id: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-huysmgQWAktM7Ldxz9Kk Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi In Pango, the strings are stroed in the UTF-8 standard. But, while i read the characters as integer, it gives some negative values. For example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the case for all the characters. How can I get the exact UTF-8 value ? I get the above values in Pango-context.c and shape.c with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-huysmgQWAktM7Ldxz9Kk Content-Type: text/html; charset=utf-8 Hi
  In Pango, the strings are stroed in the UTF-8 standard.  But, while i read the characters as integer, it gives some negative values. For example,  -32 -92 -107 is stored there for Devanagari 'ka'. This is the case for all the characters. How can I get the exact UTF-8 value ?  

I get the above values in Pango-context.c and shape.c

with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-huysmgQWAktM7Ldxz9Kk-- From nlevitt@computer.cc.columbia.edu Tue Jun 3 01:48:16 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id 90CD518135 for ; Tue, 3 Jun 2003 01:48:16 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19N4eS-0005OJ-00; Tue, 03 Jun 2003 01:48:04 -0400 Date: Tue, 3 Jun 2003 01:48:04 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: utf-8 Message-ID: <20030603054804.GI20359@columbia.edu> References: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Use g_utf8_get_char_validated or g_utf8_get_char to get the unicode character. You are looking at the byte values, which are not generally useful. If you are sure you want the UTF-8 bytes, you might want to cast to guchar if you want the unsigned values. gtk-list or gtk-app-devel-list would be better for this type of question. Noah On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while i > read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the > case for all the characters. How can I get the exact UTF-8 value ? > > I get the above values in Pango-context.c and shape.c > > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda From vivek@lantana.tenet.res.in Tue Jun 3 02:18:40 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 76639183C4 for ; Tue, 3 Jun 2003 02:18:35 -0400 (EDT) Received: from lantana.iitm.ernet.in (lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h536J4C23735 for ; Tue, 3 Jun 2003 11:49:04 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h536Hl531438 for ; Tue, 3 Jun 2003 11:47:47 +0530 Subject: Re: utf-8 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-D2E9hJukNaaTHzX9XosU" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jun 2003 11:48:47 +0530 Message-Id: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-D2E9hJukNaaTHzX9XosU Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Naoh. I have one more doubt. If we give 8bit value in the input (gtk), whether it is converted to UTF-8, before it gets stored ? Can we store the 8-bit value as it is (instead of converting to UTF-8) in GTK applications ? with regards vivek On Tue, 2003-06-03 at 11:18, Noah Levitt wrote: Use g_utf8_get_char_validated or g_utf8_get_char to get the unicode character. You are looking at the byte values, which are not generally useful. If you are sure you want the UTF-8 bytes, you might want to cast to guchar if you want the unsigned values. gtk-list or gtk-app-devel-list would be better for this type of question. Noah On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while i > read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the > case for all the characters. How can I get the exact UTF-8 value ? > > I get the above values in Pango-context.c and shape.c > > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-D2E9hJukNaaTHzX9XosU Content-Type: text/html; charset=utf-8 Thanks Naoh.
   I have one more doubt.  If we give 8bit value in the input (gtk), whether it is converted to UTF-8, before it gets stored ? Can we store the 8-bit value as it is (instead of converting to UTF-8) in GTK applications ?

with regards
vivek

On Tue, 2003-06-03 at 11:18, Noah Levitt wrote: 
Use g_utf8_get_char_validated or g_utf8_get_char to get the
unicode character. You are looking at the byte values, which
are not generally useful.

If you are sure you want the UTF-8 bytes, you might want to
cast to guchar if you want the unsigned values.

gtk-list or gtk-app-devel-list would be better for this type
of question.

Noah

On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote:
> Hi
>   In Pango, the strings are stroed in the UTF-8 standard.  But, while i
> read the characters as integer, it gives some negative values. For
> example,  -32 -92 -107 is stored there for Devanagari 'ka'. This is the
> case for all the characters. How can I get the exact UTF-8 value ?   
> 
> I get the above values in Pango-context.c and shape.c
> 
> with regards
> vivek
> -- 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
> Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> All condemnation of others really condemns ourselves - Swami Vivekananda
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda

--=-D2E9hJukNaaTHzX9XosU-- From nlevitt@computer.cc.columbia.edu Tue Jun 3 02:52:52 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id C4FF318110 for ; Tue, 3 Jun 2003 02:52:52 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19N5XT-0006CR-00; Tue, 03 Jun 2003 02:44:55 -0400 Date: Tue, 3 Jun 2003 02:44:55 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: utf-8 Message-ID: <20030603064455.GA23823@columbia.edu> References: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: I don't understand the question at all. (8bit value? input? converted? stored? What do you mean by these?) Noah On Tue, Jun 03, 2003 at 11:48:47 +0530, Viveka Nathan K wrote: > Thanks Naoh. > I have one more doubt. If we give 8bit value in the input (gtk), > whether it is converted to UTF-8, before it gets stored ? Can we store > the 8-bit value as it is (instead of converting to UTF-8) in GTK > applications ? > > with regards > vivek > From morwen@evilmagic.org Tue Jun 3 12:14:12 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail1-gui.server.ntli.net (mail1-gui.server.ntli.net [194.168.222.13]) by mail.gnome.org (Postfix) with ESMTP id 2CA1818285 for ; Tue, 3 Jun 2003 12:14:12 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mail1-gui.server.ntli.net (Post.Office MTA v3.1 release PO203a ID# 0-33929U70000L2S50) with ESMTP id AAA12970; Tue, 3 Jun 2003 17:14:00 +0100 Subject: Re: utf-8 From: Abigail Brady To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org In-Reply-To: <1054618844.955.31.camel@dodo.lli.tenet.res.in> References: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Content-Type: text/plain Organization: Message-Id: <1054656653.17407.4.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 17:10:53 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Tue, 2003-06-03 at 06:40, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while > i read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is > the case for all the characters. How can I get the exact UTF-8 value > ? I don't see why this is a surprise at all to you - that IS the correct UTF-8 encoding for KA. (E0, A4, 95, treated as 8-bit twos complement is -32 -92 -107). Perhaps you misunderstand UTF-8 or C. What are you expecting to see? -- Abi From vantr@touchtunes.com Tue Jun 3 10:39:54 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.touchtunes.com (operator.touchtunes.com [207.96.182.163]) by mail.gnome.org (Postfix) with ESMTP id 7C8E7184F5; Tue, 3 Jun 2003 10:39:54 -0400 (EDT) Received: from touchtunes.com (vantr.touchtunes.com [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 59921159E4; Tue, 3 Jun 2003 10:11:04 -0400 (EDT) Message-ID: <3EDCA50F.7030008@touchtunes.com> Date: Tue, 03 Jun 2003 09:39:27 -0400 From: Tristan Van Berkom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "B. Souliotis" Cc: gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org, gtk-list-request@gnome.org Subject: Re: Making Signal For A Widget. References: <3EDC8E7E.4010901@beta-cae.gr> In-Reply-To: <3EDC8E7E.4010901@beta-cae.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: You might do well to note also that gtkwidget.c is like a HUB for all theese events. As input, you get your GdkEvents and as output, you have a bunch of basic signals that are "emmited" at the GtkWidget level and handlers are "implemented" by various subclasses. you should probably read this: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Event-Structures.html#GdkEventButton when a "clicked" signal is emitted (by the GtkButtonClass); the mouse button has already been "released". now wether you mean the "Left button", the "button down" or "button press" by "First" is an entirely different question. Hope this helps, -Tristan From vivek@lantana.tenet.res.in Thu Jun 5 01:52:53 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id AEBEE18237 for ; Thu, 5 Jun 2003 01:52:44 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h555pP531885 for ; Thu, 5 Jun 2003 11:21:30 +0530 Subject: compiling gtk program From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-rozlI9E79IeeDf+2jH1O" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Jun 2003 11:22:49 +0530 Message-Id: <1054792374.916.23.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-rozlI9E79IeeDf+2jH1O Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi.. I took the sample program given in GTK documentation (helloworld.c) and I compiled it. It gives the error as : : /usr/include/gtk-1.2/glib/gtypes.h:41: syntax error before "typedef" : : /usr/include/gtk-1.2/glib/garray.h:32: parse error before "G_BEGIN_DECLS" /usr/include/gtk-1.2/glib/garray.h:34: syntax error before "typedef" : : what is that 'G_BEGIN_DECLS' I went through that gtypes.h.. there it is like as follows. What should I do to compile the program ? : : #include G_BEGIN_DECLS /* Provide type definitions for commonly used types. typedef char gchar; typedef short gshort; : : -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-rozlI9E79IeeDf+2jH1O Content-Type: text/html; charset=utf-8 Hi..
  I took the sample program given in GTK documentation (helloworld.c) and I compiled it.
It gives the error as

:
:
/usr/include/gtk-1.2/glib/gtypes.h:41: syntax error before "typedef"
:
:
/usr/include/gtk-1.2/glib/garray.h:32: parse error before "G_BEGIN_DECLS"
/usr/include/gtk-1.2/glib/garray.h:34: syntax error before "typedef"
:
:

what is that 'G_BEGIN_DECLS'

I went through that gtypes.h.. there it is like as follows.  What should I do to compile the program ?

:
:
#include <glibconfig.h>

G_BEGIN_DECLS

/* Provide type definitions for commonly used types.
typedef char   gchar;
typedef short  gshort;
:
: 

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-rozlI9E79IeeDf+2jH1O-- From vivek@lantana.tenet.res.in Thu Jun 5 07:17:43 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 069B818130 for ; Thu, 5 Jun 2003 07:17:39 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h55BGS511062 for ; Thu, 5 Jun 2003 16:46:31 +0530 Subject: pango ? From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-KgCMtsNS3UFlBsYuXcN4" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Jun 2003 16:47:56 +0530 Message-Id: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-KgCMtsNS3UFlBsYuXcN4 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi.. I am going to create one application in GTK with pango. In the normal program, if it contains the English string in the following label, button = gtk_button_new_with_label ("Hai!"); It displayed correctly. If i replace the string with 'UTF-8' characters, it didn't display anything. What should I add to display the UTF-8 characters using pango? Thanking you with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-KgCMtsNS3UFlBsYuXcN4 Content-Type: text/html; charset=utf-8 Hi..
 
  I am going to create one application in GTK with pango. In the normal program, if it contains
the English string in the following label,
  button = gtk_button_new_with_label ("Hai!");
  It displayed correctly.

If i replace the string with 'UTF-8' characters, it didn't display anything.
What should I add to display the UTF-8 characters using pango?

Thanking you
with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-KgCMtsNS3UFlBsYuXcN4-- From nlevitt@computer.cc.columbia.edu Thu Jun 5 11:28:12 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id 0476E18216 for ; Thu, 5 Jun 2003 11:28:12 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19Nwel-0006kJ-00; Thu, 05 Jun 2003 11:27:59 -0400 Date: Thu, 5 Jun 2003 11:27:59 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: pango ? Message-ID: <20030605152759.GA25898@columbia.edu> References: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Either it wasn't valid UTF-8 or you don't have fonts with the characters you were trying to draw. Noah On Thu, Jun 05, 2003 at 16:47:56 +0530, Viveka Nathan K wrote: > Hi.. > > I am going to create one application in GTK with pango. In the normal > program, if it contains > the English string in the following label, > button = gtk_button_new_with_label ("Hai!"); > It displayed correctly. > > If i replace the string with 'UTF-8' characters, it didn't display > anything. > What should I add to display the UTF-8 characters using pango? > > Thanking you > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda From vivek@lantana.tenet.res.in Fri Jun 6 02:59:00 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 0603A18121 for ; Fri, 6 Jun 2003 02:58:58 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h566wjQ04641; Fri, 6 Jun 2003 12:28:47 +0530 Subject: gtk program compilation error. From: Viveka Nathan K To: gtk-i18n-list@gnome.org Cc: cyrille@chepelov.org, nlevitt@columbia.edu Content-Type: multipart/alternative; boundary="=-H3/KZLLR0Pn0k2xeOhCD" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jun 2003 12:28:47 +0530 Message-Id: <1054882734.913.7.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-H3/KZLLR0Pn0k2xeOhCD Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Noah and Cyrille.. Now I installed gtk+-2.0 and compiled my program. Now it says the error as /tmp/ccNUHBNN.o: In function `main': /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:62: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:65: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:74: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:81: undefined reference to `g_type_check_instance_cast' /tmp/ccNUHBNN.o:/home/smilax2/vivekanathan/gtk/helloworld.c:81: more undefined references to `g_type_check_instance_cast' follow collect2: ld returned 1 exit status Before this, it said errors on some header files as 'No such file or directory'. I copied those files in the location as it needed. Now I dont know what to do for the above problem. Can you help me ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-H3/KZLLR0Pn0k2xeOhCD Content-Type: text/html; charset=utf-8 Thanks Noah and Cyrille..

Now I installed gtk+-2.0 and compiled my program.
Now it says the error as

/tmp/ccNUHBNN.o: In function `main':
/home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:62: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:65: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:74: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:81: undefined reference to `g_type_check_instance_cast'
/tmp/ccNUHBNN.o:/home/smilax2/vivekanathan/gtk/helloworld.c:81: more undefined references to `g_type_check_instance_cast' follow
collect2: ld returned 1 exit status 
Before this, it said errors on some header files as 'No such file or directory'.
I copied those files in the location as it needed.  Now I dont know what to do
for the above problem.  Can you help me ?
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-H3/KZLLR0Pn0k2xeOhCD-- From cyrille@chepelov.org Fri Jun 6 04:26:44 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chepelov.net1.nerim.net (chepelov.net1.nerim.net [62.212.101.212]) by mail.gnome.org (Postfix) with ESMTP id 4FFEE18363 for ; Fri, 6 Jun 2003 04:26:44 -0400 (EDT) Received: from muscat-eth0.intra.chepelov.org ([2001:7a8:29d4:0:2a0:24ff:fea6:57a0] helo=muscat.intra.chepelov.org) by chepelov.net1.nerim.net with esmtp (Exim 3.35 #1 (Debian)) id 19OCaP-0005bp-00; Fri, 06 Jun 2003 10:28:33 +0200 Received: from cyrille by muscat.intra.chepelov.org with local (Exim 3.36 #1 (Debian)) id 19OCYP-0006tQ-00; Fri, 06 Jun 2003 10:26:29 +0200 Date: Fri, 6 Jun 2003 10:26:29 +0200 To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: gtk program compilation error. Message-ID: <20030606082629.GA26487@chepelov.org> Mail-Followup-To: Viveka Nathan K , gtk-i18n-list@gnome.org References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1054882734.913.7.camel@dodo.lli.tenet.res.in> X-Face: "99`N"mZV/:OLp[>#d3R;u.!ivtwAEpIQDL8rD#;L3Wm)~^)Uv=#;S!LZf1y8oRY7J#JR\Lr{*4Cn*32C89ln>0~5~tm--}j%hvhj+vtW> Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Le Fri, Jun 06, 2003, à 12:28:47PM +0530, Viveka Nathan K a écrit: > Thanks Noah and Cyrille.. > > Now I installed gtk+-2.0 and compiled my program. > Now it says the error as > > /tmp/ccNUHBNN.o: In function `main': > /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to > `g_type_check_instance_cast' What arguments did you give to ld ? did you pass `pkg-config --libs gtk+-2.0` ? > Before this, it said errors on some header files as 'No such file or directory'. > I copied those files in the location as it needed. Now I dont know what to do > for the above problem. Can you help me ? What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0` ? -- Cyrille -- From vivek@lantana.tenet.res.in Fri Jun 6 05:03:28 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 8E68D184D4 for ; Fri, 6 Jun 2003 05:03:25 -0400 (EDT) Received: from lantana.iitm.ernet.in (lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h56942C22089 for ; Fri, 6 Jun 2003 14:34:02 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h56931Q08465; Fri, 6 Jun 2003 14:33:01 +0530 Subject: Re: gtk program compilation error. From: Viveka Nathan K To: Cyrille Chepelov Cc: gtk-i18n-list@gnome.org In-Reply-To: <20030606082629.GA26487@chepelov.org> References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> <20030606082629.GA26487@chepelov.org> Content-Type: multipart/alternative; boundary="=-/KP8l3ifKKUoAc1WvTY5" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jun 2003 14:33:04 +0530 Message-Id: <1054890184.939.13.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-/KP8l3ifKKUoAc1WvTY5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Cyrille.. Its working now. I compiled the source previously as gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags`=20 `gtk-config --libs` now, as I did as you told. Its going on and working properly :) Thank you once again On Fri, 2003-06-06 at 13:56, Cyrille Chepelov wrote: Le Fri, Jun 06, 2003, =E0 12:28:47PM +0530, Viveka Nathan K a =E9crit: > Thanks Noah and Cyrille.. >=20 > Now I installed gtk+-2.0 and compiled my program. > Now it says the error as >=20 > /tmp/ccNUHBNN.o: In function `main': > /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined referenc= e to > `g_type_check_instance_cast' =20 What arguments did you give to ld ? =20 did you pass `pkg-config --libs gtk+-2.0` ? =20 =20 > Before this, it said errors on some header files as 'No such file or= directory'. > I copied those files in the location as it needed. Now I dont know = what to do > for the above problem. Can you help me ? =20 What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0`= ? =20 -- Cyrille =20 --=20 =20 --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D=20 Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D All condemnation of others really condemns ourselves - Swami Vivekananda --=-/KP8l3ifKKUoAc1WvTY5 Content-Type: text/html; charset=utf-8 Thanks Cyrille.. Its working now.

I compiled the source previously as
gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags`  `gtk-config --libs`

now, as I did as you told. Its going on and working properly :)
Thank you once again

On Fri, 2003-06-06 at 13:56, Cyrille Chepelov wrote: 
Le Fri, Jun 06, 2003, à 12:28:47PM +0530, Viveka Nathan K a écrit:
>    Thanks Noah and Cyrille..
> 
>    Now I installed gtk+-2.0 and compiled my program.
>    Now it says the error as
> 
>    /tmp/ccNUHBNN.o: In function `main':
>    /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to
>    `g_type_check_instance_cast'

What arguments did you give to ld ?

did you pass `pkg-config --libs gtk+-2.0` ?


>  Before this, it said errors on some header files as 'No such file or directory'.
>  I copied those files in the location as it needed.  Now I dont know what to do
>  for the above problem.  Can you help me ?

What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0` ?

	-- Cyrille

-- 

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-/KP8l3ifKKUoAc1WvTY5-- From cyrille@chepelov.org Fri Jun 6 05:48:33 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chepelov.net1.nerim.net (chepelov.net1.nerim.net [62.212.101.212]) by mail.gnome.org (Postfix) with ESMTP id BB4A3184D4 for ; Fri, 6 Jun 2003 05:48:32 -0400 (EDT) Received: from muscat-eth0.intra.chepelov.org ([2001:7a8:29d4:0:2a0:24ff:fea6:57a0] helo=muscat.intra.chepelov.org) by chepelov.net1.nerim.net with esmtp (Exim 3.35 #1 (Debian)) id 19ODre-0005qM-00; Fri, 06 Jun 2003 11:50:26 +0200 Received: from cyrille by muscat.intra.chepelov.org with local (Exim 3.36 #1 (Debian)) id 19ODpd-0006hx-00; Fri, 06 Jun 2003 11:48:21 +0200 Date: Fri, 6 Jun 2003 11:48:21 +0200 To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: gtk program compilation error. Message-ID: <20030606094821.GA25745@chepelov.org> Mail-Followup-To: Viveka Nathan K , gtk-i18n-list@gnome.org References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> <20030606082629.GA26487@chepelov.org> <1054890184.939.13.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1054890184.939.13.camel@dodo.lli.tenet.res.in> X-Face: "99`N"mZV/:OLp[>#d3R;u.!ivtwAEpIQDL8rD#;L3Wm)~^)Uv=#;S!LZf1y8oRY7J#JR\Lr{*4Cn*32C89ln>0~5~tm--}j%hvhj+vtW> Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Le Fri, Jun 06, 2003, à 02:33:04PM +0530, Viveka Nathan K a écrit: > I compiled the source previously as > gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags` `gtk-config > --libs` Oh, I see. No wonder you had gtk 1.2 files coming in; gtk-config is for the 1.2 versions. Happy to know it's working now. -- Cyrille -- From otaylor@redhat.com Mon Jun 9 01:04:55 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 037D218169; Mon, 9 Jun 2003 01:04:54 -0400 (EDT) Received: from vpn50-35.rdu.redhat.com (vpn50-35.rdu.redhat.com [172.16.50.35]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5954sK32431; Mon, 9 Jun 2003 01:04:54 -0400 Subject: Pango-1.2.3 released From: Owen Taylor To: gnome-announce-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org Content-Type: text/plain Organization: Message-Id: <1055135072.1665.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 09 Jun 2003 01:04:32 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Pango-1.2.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.2/ As compared to Pango-1.2.1 (Pango-1.2.2 was a short-lived release and never announced), this release contains various bug fixes, a large speedup to layout with the Xft and FT2 backends (as much as 5 times faster for short strings), and new shapers to allow Indic and Thai to be used with the FT2 backend. About Pango =========== Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most usage so far as been in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+ 2. Pango is designed to be modular; the core Pango layout can be used with four different font backends: - Core X windowing system fonts - Client-side fonts on X using the Xft2 library - Direct rendering of scalable fonts using the FreeType library - Native fonts on Microsoft platforms Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango-1.2 ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango depends on version 2.2.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of Changes in Pango 1.2.2 ================================== * Fix operation with --disable-debug [Jeff Waugh] * Improve handling of ink rectangle extents for empty runs * Fix problem with keynav at line boundaries for RTL text [Matthias Clasen] Overview of Changes in Pango 1.2.2 ================================== * Cache fontsets for the Xft and FT2 backends, a large speedup for short strings [Owen Taylor, Soeren Sandmann] * Make built in rendering functions, especially the FT2 one, work more like the GDK implementation [Sven Neumann] * Add an indic-ft2 module [Kapil Chowskey], Add a thai-ft2 module [Theppitak Karoonboonyanan] * Optimize pango_x_render() by drawing multiple character with a single request when possible [Morten Welinder] * Change the handling of attributes that cover only partial glyphs [Owen, Taneem Ahmed, Sunil Mohan Adapa] * Fix problems with Arial Unicode and the Opentype code [Owen, Noah Levitt] * Fix common crash for fonts missing a GDEF table * Fix common portability problem with informative output at end of configure. * Build cleanups and fixes [Tim Mooney, Chris Ross, Akira Tagoh, Will Partain, James Su] * Miscellaneous bug fixes and cleanups [Simon Budig, Rick Jones, Noah, Padraig O'Briain, Benjamin Otte, Andrey Panov, Federic Zhang] * Documentation fixes [Tim, Sven] Owen Taylor 9 June 2003 From sky@icqus.dyndns.org Mon Jun 9 16:32:24 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from icqus.dyndns.org (12-215-147-200.client.mchsi.com [12.215.147.200]) by mail.gnome.org (Postfix) with ESMTP id 67E75187AD for ; Mon, 9 Jun 2003 16:32:24 -0400 (EDT) Received: from icqus.dyndns.org (sky@localhost.my.domain [IPv6:::1]) by icqus.dyndns.org (8.12.9/8.12.9) with ESMTP id h59KWNpp005422 for ; Mon, 9 Jun 2003 16:32:23 -0400 (EDT) Received: (from sky@localhost) by icqus.dyndns.org (8.12.9/8.12.9/Submit) id h59KU0bD021164 for gtk-i18n-list@gnome.org; Mon, 9 Jun 2003 16:30:00 -0400 (EDT) Date: Mon, 9 Jun 2003 16:30:00 -0400 (EDT) From: Teardrop Sky Message-Id: <200306092030.h59KU0bD021164@icqus.dyndns.org> To: gtk-i18n-list@gnome.org Subject: unicode fonts Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: i had a question about unicode fonts that i posted to gtk-list, but i just discovered this list and realized it had been more appropriate here, but in short i'm looking for examples of unicode code written for gtk+2. (specifically with greek and hebrew fonts, but anything to sift through would be welcome) links or short examples, whatever. thanks :) ~sky From vivek@lantana.tenet.res.in Tue Jun 10 08:40:48 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id F3849180EE for ; Tue, 10 Jun 2003 08:40:45 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5ACea804262 for ; Tue, 10 Jun 2003 18:10:39 +0530 Subject: compiling gtk+-2.2.1 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-ttvrksX/Kvt+Z581nOPE" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Jun 2003 18:10:54 +0530 Message-Id: <1055248857.10655.3.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-ttvrksX/Kvt+Z581nOPE Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii I am upgrading the gtk (which is available with RH 8.0) to gtk+-2.2.1. After completing the make and make install, While starting the gnome-session, I got the following error. gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name This lib is linked with the lib which is currently created as follows lrwxrwxrwx 1 root root 25 Jun 10 17:55 /usr/lib/libgdk-x11-2.0.so.0 -> libgdk-x11-2.0.so.0.200.1 What should I do ? with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-ttvrksX/Kvt+Z581nOPE Content-Type: text/html; charset=utf-8 Hii
I am upgrading the gtk (which is available with RH 8.0) to gtk+-2.2.1. After completing the make and make install,  While starting the gnome-session, I got the following error.

gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name

This lib is linked with the lib which is currently created as follows
lrwxrwxrwx    1 root     root           25 Jun 10 17:55 /usr/lib/libgdk-x11-2.0.so.0 -> libgdk-x11-2.0.so.0.200.1

What should I do ?

with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-ttvrksX/Kvt+Z581nOPE-- From vivek@lantana.tenet.res.in Thu Jun 12 04:35:17 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id EFFD318D26 for ; Thu, 12 Jun 2003 04:35:14 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5C8Yk830183 for ; Thu, 12 Jun 2003 14:04:48 +0530 Subject: [Fwd: Use of Bonobo (fwd)] From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-v4j5dv3CjxL1ERGc2Gfa" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 12 Jun 2003 14:05:32 +0530 Message-Id: <1055406934.20734.4.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-v4j5dv3CjxL1ERGc2Gfa Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii all, Can anyone please tell me what is the role of Bonobo object in gedit? with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-v4j5dv3CjxL1ERGc2Gfa Content-Type: text/html; charset=utf-8 
Hii all,
	Can anyone please tell me what is the role of Bonobo object in gedit?

with regards
vivek
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-v4j5dv3CjxL1ERGc2Gfa-- From chutz@gg3.net Sat Jun 14 04:00:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from tiger.gg3.net (142.13.111.219.st.bbexcite.jp [219.111.13.142]) by mail.gnome.org (Postfix) with SMTP id 855E618512 for ; Sat, 14 Jun 2003 04:00:29 -0400 (EDT) Received: (qmail 23398 invoked by uid 0); 14 Jun 2003 08:00:28 -0000 Received: from tiger.gg3.net (10.0.0.9) by 0 with SMTP; 14 Jun 2003 08:00:28 -0000 Received: from lion.gg3.net (10.0.0.2) by tiger.gg3.net (tmda-ofmipd) with ESMTP; Sat, 14 Jun 2003 17:00:27 +0900 Received: by lion.gg3.net (sSMTP sendmail emulation); Sat, 14 Jun 2003 17:00:27 +0900 Date: Sat, 14 Jun 2003 17:00:27 +0900 To: gtk-i18n-list@gnome.org Subject: Regarding selection of alternate fonts (with untagged text) Message-ID: <20030614080027.GA4590%chutz@gg3.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.5.4i-ja.1 From: Georgi Georgiev Mail-Followup-To: gtk-i18n-list@gnome.org X-Delivery-Agent: TMDA/0.74 (Citation) X-Primary-Address: chutz@gg3.net Reply-To: Georgi Georgiev Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello list, I have a question/problem which was partially answered at http://www.pango.org/font-selection.shtml (I hope this is the right list to post my question to). My question is related to language auto-tagging and the selection of an alternate font that Pango makes in different locales. My problem is that basically, it chooses different fonts for Cyrillic text when LC_ALL is set to bg_BG or ja_JP. There were a few interesting posts I found in the mailing list archive, but the talk being too broad, I had trouble understanding if this problem is being tackled or not. Here goes a more detailed description of what I mean. What happens is that I for example have my locale set to ja_JP. Actually it is only LC_CTYPE=ja_JP LC_COLLATE=ja_JP LC_MONETARY=ja_JP and the rest LC_*=C (LC_ALL is unset). I need the few ja_JP because I want to be able to properly display Japanese in all applications, but I prefer to read messages in English. I also need it for Japanese input. However, I sometimes also work with Cyrillic (actually pretty often). What happens when Pango is asked for a font that does not have the Cyrillic characters is that it of course does that auto-tagging and substitution (I guess) and hands me a different font that has the characters that I need. In my /etc/fonts/fonts.conf I have the following: sans-serif Bitstream Vera Sans Arial Verdana Nimbus Sans L Luxi Sans Helvetica Kochi Gothic AR PL KaitiM GB AR PL KaitiM Big5 Baekmuk Dotum SimSun When I run a program with LC_ALL=bg_BG, Cyrillic is displayed in Arial. However, when I run it with LC_ALL=ja_JP I see Cyrillic displayed in Kochi Gothic (meaning ugly, square letters). I am also attaching two small screenshots to illustrate what I mean. So my question is, how do I make Pango "prefer" Arial over Kochi when my locale is ja_JP (short of specifying Arial explicitly, which works). I don't know if it is possible, but I just wanted to state my problem. -- /^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\ / Georgi Georgiev (-< / A pencil with no point needs no \ \ chutz@chubaka.net /\ .o)\ eraser. / / +81(90)6266-1163 V_/_ |(/)/ \ \___________________________/\__________________________________/ --HlL+5n6rz5pIUxbD Content-Type: image/png Content-Disposition: attachment; filename="bg_BG.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASkAAAAcCAAAAAAYMhb0AAAC2UlEQVR4nO1YPWsVQRQ9J0LA 4CchoCLa2QQbkYCViGBra6MIVhZ2/gNbi7RK7BRBQbDTfxCD6Q3YaCEBSVKkU8ix2Llz7+zb F+Yl4CMwh7A792vm7tkzs49QaKjCzLQbODKYAZmGZB52pl8xEOmDzBMwTFUmk6WHJLFzZ+5A vQ/3Md5/uFzXFCGBwcQECwIAlCZgHo1J6zmWv/yYcKWMbjkGayiJI9m9TFaMZtxU+RAjDzSy ODn4SgiNlncqI8BUlioF4MPtBZBYI0G+mb+xaZbpNAcBEt9uzs0ufuqKRdKmtEs3aXjVki3G 3CGNX8UAoLwdos8yJcluhu5RNRhNVUiMhIpYEt3FdKkuDz/jhQToASDg8Qrum+U5KSgBuvb6 7zoueGuCINmiKU2Q+eB39JtCqkR+Ethf8uXRREzBufVb4A+BrbwyBqYsSZvdkIDflwABW9tY MMtzUrDzrD29Csqe0pZVXD9cFBtw1oyDgpIY6JM4/ts3sLEiJQOQn04jWRw+OgXg/Z8nAPDq IQDg7GnsuGWI5vLSxkqWJZ2uJJssWXT7hiL7G425vXRQyLoUu6D7SoWMaKqQZ62mgm48Mmb3 BUnsXeZ3AVd+AQI2t3HOrD0cS+kpKAE6gd1dF4FJKZCfheSNmGk6ifIph954GXZNCRzUUaEA a23fj80+n71eTfpNcU9vAVw/DwB49hF3zdrCUspMQQDAKay/9GLjOz/RyOICUHqp7nNkvVB9 mfV97i9PtUJTZVKUmksuCM6GxSvvneE9aX3FooDVzvP85K1ts45f/JnyVr0XvJs/8ygvnU/v UkOFSrLpmbLtNTxH6etuJW0Tgzhc/QHmKzqmCFlZUUynNg2pWOvJlM/KoKjkK1wHA6GpM/Uf 0V/Xvl1VtQiH0pT6/3+Y1hs6emj/S6hFY6oWjalaNKZq0ZiqRWOqFo2pWjSmatGYqkVjqhaN qVo0pmrRmKrFPw6cTkdTqI2EAAAAAElFTkSuQmCC --HlL+5n6rz5pIUxbD Content-Type: image/png Content-Disposition: attachment; filename="ja_JP.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAATgAAAAcAQAAAADdTp5TAAABd0lEQVR4nO3Rv0sCURwA8EvD lsihpSByiVwLV+9uDP+B/oRGHYQkOLuiQaLBwSXRvKHRwaGhoU4Ho5KMm4LA6IRCqdDnD+R5 3vO+PU/Loij/AL88vjz4fnjfL+/LwGjBjOqkLCQEKAOs8DxRyLCimAeADFwUZoTezSXxBL64 mxRSIFyVCe6CiBiJB68AJQd13JyHvRQ/3IOFefQ1q/IRJg7TGRsCPCvUufPX0cqnk9aNQ5QJ FV92gve2ib6rOZXefPlctFKPS/PFenwtHJvaS5Qzr7qGt9SA+Z6N9rWDC7jpXOxJ53wnLZ1D WFax/GYtBM7wZt+RhlBbUpoucOdzsUonjZItmkIZGyOjIHVI5DB1UerofKbbj1S1tC92p6VR gFURi7oF7ywS09TtZklj0l5ytv1gWfZELvyL0uptc2HqgE0hVtWT3WN1O4jVwT7Kw38zzIyh 41cM/urUEM81XeF/OiLCL8GAYe0tqW3/Z79/l8du7L7FO3330tQ/Xb18AAAAAElFTkSuQmCC --HlL+5n6rz5pIUxbD-- From vivek@lantana.tenet.res.in Tue Jun 17 05:15:02 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 0299418653 for ; Tue, 17 Jun 2003 05:14:56 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5H9EEC02535; Tue, 17 Jun 2003 14:44:19 +0530 Subject: gtk+-2.2.1 compilation From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-Q1Eg8cjg6cVUshCdvynd" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 17 Jun 2003 15:45:16 +0530 Message-Id: <1055844921.801.99.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-Q1Eg8cjg6cVUshCdvynd Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all I compiled the gtk+-2.2.1 using the source. After the compilation, while starting gnome, it says the error, gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name what is this 'relocation error' ? what should I do for this ? with regards Vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-Q1Eg8cjg6cVUshCdvynd Content-Type: text/html; charset=utf-8 Hi all
I compiled the gtk+-2.2.1 using the source.
After the compilation, while starting gnome, it says the error,

gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name

what is this 'relocation error' ? what should I do for this ?

with regards
Vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-Q1Eg8cjg6cVUshCdvynd-- From klchxbec@yahoo.com Wed Jun 18 01:02:20 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from web13901.mail.yahoo.com (web13901.mail.yahoo.com [216.136.175.27]) by mail.gnome.org (Postfix) with SMTP id C46961823F for ; Wed, 18 Jun 2003 01:02:19 -0400 (EDT) Message-ID: <20030618050219.94343.qmail@web13901.mail.yahoo.com> Received: from [203.200.195.2] by web13901.mail.yahoo.com via HTTP; Tue, 17 Jun 2003 22:02:19 PDT Date: Tue, 17 Jun 2003 22:02:19 -0700 (PDT) From: klchxbec Subject: fix to pango GSUB To: gtk-i18n-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Here is a one-liner to fix pango's GSUB code for rendering kannada text. ftp://ftp.gtk.org/incoming/ftxgsub-bad.png ftp://ftp.gtk.org/incoming/ftxgsub-good.png Index: pango/opentype/ftxgsub.c =================================================================== RCS file: /cvs/gnome/pango/pango/opentype/ftxgsub.c,v retrieving revision 1.6 diff -u -r1.6 ftxgsub.c --- pango/opentype/ftxgsub.c 16 Apr 2003 03:58:17 -0000 1.6 +++ pango/opentype/ftxgsub.c 17 Jun 2003 12:26:01 -0000 @@ -3823,7 +3823,7 @@ /* we are starting for lookahead glyphs right after the last context glyph */ - curr_pos = j; + curr_pos += j; s_in = &in->string[curr_pos]; lc = ccsf3->LookaheadCoverage; __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From zenithlau@i-cable.com Wed Jun 18 11:12:43 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from virgo.i-cable.com (virgo.i-cable.com [203.83.111.75]) by mail.gnome.org (Postfix) with SMTP id 2AA1B180E4 for ; Wed, 18 Jun 2003 11:12:42 -0400 (EDT) Received: (qmail 8987 invoked by uid 706); 18 Jun 2003 15:12:36 -0000 Received: from cm61-10-38-94.hkcable.com.hk (HELO ?192.168.0.34?) (61.10.38.94) by 0 with SMTP; 18 Jun 2003 15:12:13 -0000 Subject: Font configuration issues. From: Zarick Lau Reply-To: zenithlau@i-cable.com To: gtk-i18n-list@gnome.org Content-Type: text/plain Organization: NixStyle.Net Message-Id: <1055949103.5609.8.camel@zlap> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 18 Jun 2003 23:11:43 +0800 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi list, I am using gtk 2.2.1 with Gnome 2.2, I found that if the selection of font is effectively determined by LC_CTYPE, why?? In my understanding, LC_CTYPE should only influence how a apps process the data from external. Though I am not sure.. Another important issues is, is it possible to configuration the system (fonts.conf right?) so that, when in non en locale, the system will still use en fonts to render the latin messages, while taking another fonts for other language? If it is only a configuration issues, would you mind show me a bit examples? Regards, Zarick Lau From Tony.Graham@Sun.COM Wed Jun 18 11:22:48 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.gnome.org (Postfix) with ESMTP id B3BEB180E4 for ; Wed, 18 Jun 2003 11:22:47 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5IFMkLv026967 for ; Wed, 18 Jun 2003 08:22:46 -0700 (PDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5IFMjg6025853 for ; Wed, 18 Jun 2003 16:22:45 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5IFP1i04287; Wed, 18 Jun 2003 16:25:01 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16112.33869.254511.67633@tenso.ireland.sun.com> Date: Wed, 18 Jun 2003 16:25:01 +0100 To: gtk-i18n-list@gnome.org Subject: PangoPDF 1.2.3.0 released X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: PangoPDF is a version of Pango with additional PDF/PostScript backends and support for additional XSL-related text attributes. This release updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and Xft backends to match Pango 1.2.3. Download PangoPDF from http://sourceforge.net/projects/pangopdf/. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From vivek@lantana.tenet.res.in Thu Jun 19 00:26:38 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 75EA4181CD for ; Thu, 19 Jun 2003 00:26:36 -0400 (EDT) Received: from swan.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5J4PkC11643; Thu, 19 Jun 2003 09:55:48 +0530 Subject: GTK+- runtime error From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-c3mWW04KSiClVd8B3bqY" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Jun 2003 10:06:33 +0530 Message-Id: <1055997396.1426.4.camel@swan.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-c3mWW04KSiClVd8B3bqY Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii all. I am compiling the GTK+ from the source. The version I am using is 2.0.6. Previously i went through the latest versions, but it needs the latest, xft, glib etc.. There also I got a problem of 'relocation error'. so, I thought to use the same version of GTK installed in Redhat 8.0. After that, while i start 'gedit' or 'gnome-session' anything, i got the following error. What i have to do to make the compilation successfully ? The program 'gedit' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 46 error_code 16 request_code 154 minor_code 20) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Or can anyone tell me, with 'which version of which', I can successfully compile the Pango and GTK from source? Thanking you, with regards Vivek. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-c3mWW04KSiClVd8B3bqY Content-Type: text/html; charset=utf-8 Hii all.

I am compiling the GTK+ from the source. The version I am using is 2.0.6.  Previously i went through the latest versions, but it needs the latest, xft, glib etc..  There also I got a problem of
'relocation error'. so, I thought to use the same version of GTK installed in Redhat 8.0.

After that, while i start 'gedit' or 'gnome-session' anything, i got the following error.  What i have to
do to make the compilation successfully ?

The program 'gedit' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 46 error_code 16 request_code 154 minor_code 20)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Or can anyone tell me, with 'which version of which', I can successfully compile the Pango and GTK from source?

Thanking you,
with regards
Vivek. 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-c3mWW04KSiClVd8B3bqY-- From ittay@qlusters.com Sun Jun 22 10:17:59 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from hirame.qlusters.com (adsl-139-109.barak.net.il [62.90.139.109]) by mail.gnome.org (Postfix) with ESMTP id 2FA62181E0 for ; Sun, 22 Jun 2003 10:17:58 -0400 (EDT) Received: from ittay ([10.100.0.13]) by hirame.qlusters (8.10.2/8.10.2) with ESMTP id h5MEFge26386 for ; Sun, 22 Jun 2003 17:15:42 +0300 Subject: how do i add windows-1255 encoding? From: Ittay Dror To: gtk-i18n-list@gnome.org In-Reply-To: <20030622133801.28246.23535.Mailman@moniker.gnome.org> References: <20030622133801.28246.23535.Mailman@moniker.gnome.org> Content-Type: text/plain Message-Id: <1056291353.18485.6.camel@ittay> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0-1mdk Date: 22 Jun 2003 17:15:53 +0300 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: i'm using the new evolution, and the only hebrew encoding i have is iso-8859-8. unfortunately, all the words are in reverse order. i thought adding windows-1255 encoding would solve this. how do i add it? thanx, ittay -- ======================================= Ittay Dror (ittay@qlusters.com) User Space, R&D Qlusters Inc. Tel: +972-3-6081956 Fax: +972-3-6081841 From Takao.Fujiwara@Sun.COM Fri Jun 20 10:49:28 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.gnome.org (Postfix) with ESMTP id E5DBA1843D for ; Fri, 20 Jun 2003 10:49:27 -0400 (EDT) Received: from udsylm-mail1.Japan.Sun.COM ([129.158.26.30]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5KEnQep002428 for ; Fri, 20 Jun 2003 08:49:27 -0600 (MDT) Received: from requiem (requiem [129.158.28.20]) by udsylm-mail1.Japan.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.1p1) with SMTP id h5KEnPY25373; Fri, 20 Jun 2003 23:49:26 +0900 (JST) Message-Id: <200306201449.h5KEnPY25373@udsylm-mail1.Japan.Sun.COM> Date: Fri, 20 Jun 2003 23:49:19 +0900 (JST) From: Takao Fujiwara - Tokyo S/W Center Reply-To: Takao Fujiwara - Tokyo S/W Center Subject: alias in pangox.alias To: gtk-i18n-list@gnome.org Cc: Takao.Fujiwara@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zu2WY8a+lt3tBgPe0y0esA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 sun4u sparc Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi experts, I have quality issues about Japanese fonts in Pango. When we choose small size fonts in GNOME2.0.2 (pango 1.0.5) + Solaris 9, The rendering in Japanese fonts are very ugly. I have one remedy to add some alias to pangox.alias. However I don't have an explicit answer that it is no problem for pango specification. I would like to ask you it. Do you have any ideas to add gothic and mincho as aliases to pangox.alias below? gothic normal normal normal normal \ "-ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0201.1976-0,\ -ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0212.1990-0,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-1,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-2,\ -adobe-helvetica-medium-r-normal--*-*-*-*-*-*-iso8859-1" mincho normal normal normal normal \ "-ricoh-hg mincho l-medium-r-normal--*-*-*-*-c-*-jisx0201.1976-0,\ -ricoh-hg mincho l-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0212.1990-0,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-1,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-2,\ -adobe-utopia-medium-r-normal--*-*-*-*-*-*-iso8859-1" This remedy can fix problems that characters are very ugly in small Japanese fonts when gtk applications(Mozilla, etc) choose any fonts beside sans, serif, and monospace. I think that the issue occurs because 'gothic' in jisx0208 does not have small point size but 'hg gothic b' in jisx0208 has small point size. % xlsfonts -fn '-sun-minchou-bold-r-normal--*-*-*-*-c-*-jisx0208.1983-0' -sun-gothic-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0 -sun-gothic-medium-r-normal--14-120-75-75-c-120-jisx0208.1983-0 <---- -sun-gothic-medium-r-normal--16-140-75-75-c-140-jisx0208.1983-0 -sun-gothic-medium-r-normal--18-160-75-75-c-160-jisx0208.1983-0 -sun-gothic-medium-r-normal--22-200-75-75-c-200-jisx0208.1983-0 -sun-gothic-medium-r-normal--26-240-75-75-c-240-jisx0208.1983-0 % xlsfonts -fn '-ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0' -ricoh-hg gothic b-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--0-0-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--10-100-72-72-c-100-jisx0208.1983-0 <---- -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-120-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--14-140-72-72-c-140-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--16-160-72-72-c-160-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--18-180-72-72-c-180-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--20-200-72-72-c-200-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--24-240-72-72-c-240-jisx0208.1983-0 Sans, serif, and monospace have similar problems. If sans has only sun-gothic as jisx0208 font, pango renders ugly glyph. But If sans has ricoh-hg gothic b as jisx0208 font, pago renders fine glyph. So when pango refers 'gothic', I would like to point 'hg gothic b' in jisx0208/0201 against 'gothic', and when pango refers 'mincho', I would like to point 'hg mincho l' in jisx0208/0201 against 'mincho'. pangox.alias in Solaris has distinct directory(/etc/pango/$locale/pangox.alias) by locale, so pangox.alias can be set in each locale. I think this remedy has a pretty pit, i.e. If set 'gothic bold normal normal normal' in pangox.alias, user can see duplicated 'Bold' fonts in gnome-font-properties. It is no problem in 'gothic normal normal normal normal' because gothic fonts originally have 'medium' style but not 'normal' style. I do not join this mail alias, so please mail to me directly. Thanks in advance, Sun Microsystems Software Engineer Tokyo Software Center Takao Fujiwara E-Mail: Takao.Fujiwara@Sun.COM Tel: +81-45-227-9287(direct)/Fax: +81-45-225-5295 From otaylor@redhat.com Mon Jun 23 06:20:33 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1CFD018848 for ; Mon, 23 Jun 2003 06:20:33 -0400 (EDT) Received: from vpn50-2.rdu.redhat.com (vpn50-2.rdu.redhat.com [172.16.50.2]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5NAJxK02035; Mon, 23 Jun 2003 06:19:59 -0400 Subject: Re: PangoPDF 1.2.3.0 released From: Owen Taylor To: Tony Graham Cc: gtk-i18n-list@gnome.org In-Reply-To: <16112.33869.254511.67633@tenso.ireland.sun.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> Content-Type: text/plain Organization: Message-Id: <1056363575.13947.45.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 23 Jun 2003 06:19:36 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > PangoPDF is a version of Pango with additional PDF/PostScript backends > and support for additional XSL-related text attributes. This release > updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and > Xft backends to match Pango 1.2.3. > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. I'm being incredibly lazy here, and really should go look at the code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps the real question is, what do you mean by "backend" here?) I can't really see how you'd replace the Pango backend libraries and/or the shapers and keep keep things working reasonably. Regards, Owen From maclas@gmx.de Mon Jun 23 07:24:44 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by mail.gnome.org (Postfix) with SMTP id 5398F183F0 for ; Mon, 23 Jun 2003 07:24:44 -0400 (EDT) Received: (qmail 27486 invoked by uid 0); 23 Jun 2003 11:24:42 -0000 Date: Mon, 23 Jun 2003 13:24:42 +0200 (MEST) From: Matthias Clasen To: Owen Taylor Cc: gtk-i18n-list@gnome.org MIME-Version: 1.0 References: <1056363575.13947.45.camel@localhost.localdomain> Subject: Re: PangoPDF 1.2.3.0 released X-Priority: 3 (Normal) X-Authenticated-Sender: #0014083743@gmx.net X-Authenticated-IP: [195.243.100.246] Message-ID: <15429.1056367482@www60.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > > PangoPDF is a version of Pango with additional PDF/PostScript backends > > and support for additional XSL-related text attributes. This release > > updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and > > Xft backends to match Pango 1.2.3. > > > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > I'm being incredibly lazy here, and really should go look at the > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > the real question is, what do you mean by "backend" here?) > > I can't really see how you'd replace the Pango backend libraries > and/or the shapers and keep keep things working reasonably. > From the PangoPDF homepage: PangoPDF implements a version of the Pango (http://www.pango.org/) library with a PDF backend for creating PDF output. This library also implements several of the inline properties defined by XSL (http://www.w3.org/TR/xsl/) that are not currently implemented by Pango. PangoPDF is designed to be API-compatible with the corresponding Pango version. The version number of the PangoPDF library, therefore, reflects the version number of the Pango version upon which library is based. The current PangoPDF version is 1.2.0.1, since it is based upon Pango 1.2.0. The goal of this project is to make itself redundant by implementing PDF support and XSL support so well that the additions are incorporated into Pango itself. The PangoPDF library tracks the official Pango library so the PangoPDF library can incorporate non PDF-related improvements and API changes as they are incorporated into Pango. -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! From vivek@lantana.tenet.res.in Tue Jun 24 07:00:39 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 238F4181D4; Tue, 24 Jun 2003 07:00:36 -0400 (EDT) Received: from lantana.iitm.ernet.in (IDENT:DcG7BlZfrrIv1KNv03I8HUSr4W9KMQwn@lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h5OB0wC16387; Tue, 24 Jun 2003 16:30:58 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5OAwsC00995; Tue, 24 Jun 2003 16:28:55 +0530 Subject: Encoding other than UTF-8 ? From: Viveka Nathan K To: gtk-list@gnome.org Cc: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-e35IJaWRw9jjkFMGgWt7" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Jun 2003 16:30:58 +0530 Message-Id: <1056452459.6174.30.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-e35IJaWRw9jjkFMGgWt7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all.. How can I use the encoding other than UTF-8, in GNOME ? If I set the LOCALE to en_US.ISO-8859-1, it saves the file in UTF-8 format only. How can I change it ? Applications like 'gtk2edit' are having the options to store in different encodings, but in 'gedit', I couldnt do that. Is there any way to do that ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Phone - Mobile: 0-9444167493 Off:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-e35IJaWRw9jjkFMGgWt7 Content-Type: text/html; charset=utf-8 Hi all..
How can I use the encoding other than UTF-8, in GNOME ?
If I set the LOCALE to en_US.ISO-8859-1, it saves the file in UTF-8 format only.
How can I change it ?  Applications like 'gtk2edit' are having the options to store
in different encodings, but in  'gedit', I couldnt do that.

Is there any way to do that ? 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. 
Phone - Mobile: 0-9444167493 Off:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves 
- Swami Vivekananda
--=-e35IJaWRw9jjkFMGgWt7-- From Tony.Graham@Sun.COM Wed Jun 25 06:36:05 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.gnome.org (Postfix) with ESMTP id A477318237 for ; Wed, 25 Jun 2003 06:36:04 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PAa3vc007545 for ; Wed, 25 Jun 2003 04:36:03 -0600 (MDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PAa2g6012556 for ; Wed, 25 Jun 2003 11:36:02 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5PAcGo09573; Wed, 25 Jun 2003 11:38:16 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16121.31640.237024.593290@tenso.ireland.sun.com> Date: Wed, 25 Jun 2003 11:38:16 +0100 To: gtk-i18n-list@gnome.org Subject: Re: PangoPDF 1.2.3.0 released In-Reply-To: <1056363575.13947.45.camel@localhost.localdomain> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400: > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: ... > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > I'm being incredibly lazy here, and really should go look at the > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > the real question is, what do you mean by "backend" here?) PangoPDF includes all of the backends so PangoPDF can be used as a drop-in replacement for Pango. To use PangoPDF instead of Pango in an application, just edit the application's configure.in (or configure.ac) to prefix Pango's pkg-config package names with 'pangopdf-', then rerun autoconf and configure. That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF. The FT2/X/Xft backends in PangoPDF are really just vanilla Pango. I expect that PangoPDF will add support for the 'XSL' attributes (which are also CSS3 attributes) to the FT2 and Xft backends (as one person has done for FT2 in his version of PangoPDF), but I expect to first implement the 'XSL' attributes as (conditionally) part of the PangAttrType enumeration instead of registering them with pango_attr_type_register() because it's so much easier to work with attribute types as constants rather than variables. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From otaylor@redhat.com Wed Jun 25 11:22:11 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DD55918C6E for ; Wed, 25 Jun 2003 11:22:10 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5PFM5K27129; Wed, 25 Jun 2003 11:22:05 -0400 Subject: Re: PangoPDF 1.2.3.0 released From: Owen Taylor To: Tony Graham Cc: gtk-i18n-list@gnome.org In-Reply-To: <16121.31640.237024.593290@tenso.ireland.sun.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> <16121.31640.237024.593290@tenso.ireland.sun.com> Content-Type: text/plain Message-Id: <1056554525.14257.195.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 25 Jun 2003 11:22:05 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Wed, 2003-06-25 at 06:38, Tony Graham wrote: > Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400: > > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > ... > > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > > > I'm being incredibly lazy here, and really should go look at the > > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > > the real question is, what do you mean by "backend" here?) > > PangoPDF includes all of the backends so PangoPDF can be used as a > drop-in replacement for Pango. > > To use PangoPDF instead of Pango in an application, just edit the > application's configure.in (or configure.ac) to prefix Pango's > pkg-config package names with 'pangopdf-', then rerun autoconf and > configure. > > That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF. > > The FT2/X/Xft backends in PangoPDF are really just vanilla Pango. I > expect that PangoPDF will add support for the 'XSL' attributes (which > are also CSS3 attributes) to the FT2 and Xft backends (as one person > has done for FT2 in his version of PangoPDF), but I expect to first > implement the 'XSL' attributes as (conditionally) part of the > PangAttrType enumeration instead of registering them with > pango_attr_type_register() because it's so much easier to work with > attribute types as constants rather than variables. While it's fine to experiment with a fork of Pango, I'd really strongly encourage you to try to get API additions into the main Pango. Pango really isn't a big enough of a project to need two competing versions, and there are some definately potential problems with what you are doing. For example, if you modify libgnomeprint-2.2.1.2 as you describe then you'll link against *both* Pango and PangoPDF when you have an app that uses GTK+ and uses libgnomeprint. And the effects of that will be unpredicatable and probably bad. But why is pango_attr_type_register() so hard to use? I don't really understand the problem. Sure, it's a few more lines of code, but that doesn't quite seem worth maintaining a fork. Regards, Owen From Tony.Graham@Sun.COM Wed Jun 25 18:38:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.gnome.org (Postfix) with ESMTP id 3984118C60 for ; Wed, 25 Jun 2003 18:38:30 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PMcRvc013790 for ; Wed, 25 Jun 2003 16:38:28 -0600 (MDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PMcRg6025351 for ; Wed, 25 Jun 2003 23:38:27 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5PMefA10115; Wed, 25 Jun 2003 23:40:41 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16122.9449.263238.517090@tenso.ireland.sun.com> Date: Wed, 25 Jun 2003 23:40:41 +0100 To: gtk-i18n-list@gnome.org Subject: Re: PangoPDF 1.2.3.0 released In-Reply-To: <1056554525.14257.195.camel@poincare.devel.redhat.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> <16121.31640.237024.593290@tenso.ireland.sun.com> <1056554525.14257.195.camel@poincare.devel.redhat.com> X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Owen Taylor wrote at 25 Jun 2003 11:22:05 -0400: ... > While it's fine to experiment with a fork of Pango, I'd really > strongly encourage you to try to get API additions into the > main Pango. Pango really isn't a big enough of a project > to need two competing versions, and there are some definately > potential problems with what you are doing. I don't want to fork Pango, and, as Matthis Clasen posted, the goal of PangoPDF is to make itself obsolete. > For example, if you modify libgnomeprint-2.2.1.2 as you > describe then you'll link against *both* Pango and PangoPDF > when you have an app that uses GTK+ and uses libgnomeprint. > And the effects of that will be unpredicatable and probably > bad. I know that. I still don't have a good solution to the fact that PangoPDF's GNOME Print backend depends on GNOME Print which depends on Pango. The effect of that will be unpredictable and probably bad too. As such, I don't think that part's ready to come into the fold. > But why is pango_attr_type_register() so hard to use? I don't > really understand the problem. Sure, it's a few more lines of > code, but that doesn't quite seem worth maintaining a fork. That's not why I'm maintaining a fork. I talked about pango_attr_type_register() when explaining what I would do if I were to add extra attributes to the FT2 and Xft backends. I am interested in seeing the fruits of what you wrote about in the "Merging code between Xft and FT2 shapers" thread on April 14 since that would make it easier to add FreeType-using backends to Pango. I will submit some enhancement requests. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From stephan.hegel@gmx.de Fri Jun 27 08:28:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id 02E8B18100 for ; Fri, 27 Jun 2003 08:28:30 -0400 (EDT) Received: (qmail 12482 invoked by uid 65534); 27 Jun 2003 12:28:18 -0000 Received: from unknown (EHLO gmx.de) (61.155.125.80) by mail.gmx.net (mp023) with SMTP; 27 Jun 2003 14:28:18 +0200 Message-ID: <3EFC3811.2090705@gmx.de> Date: Fri, 27 Jun 2003 20:26:57 +0800 From: Stephan Hegel Reply-To: stephan.hegel@gmx.de Organization: Private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en, de, zh-CN MIME-Version: 1.0 To: gtk-i18n-list@gnome.org Subject: Unexpected font rendering with pango Content-Type: multipart/mixed; boundary="------------010503000008060104000107" Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------010503000008060104000107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Recently I have found an unusual behaviour in Chinese font rendering with Pango.Please have a look at the attached, little screenshots. The only difference between both is the setting of the locale before starting the application. The first one uses LC_ALL=en_US and the second one LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing antialiasing - fine on the second pix, but not o.k. in the first case. It somehow uses a different size of fonts in just one string ... Anyone out there who has an idea or a hint how to track this and/or to fix this ? The application used in this case is called "lingoteach" and available on freshmeat. However, I have noticed that stardict behaves in the same strange way ... Kind regards, Stephan. --------------010503000008060104000107 Content-Type: image/png; name="en_US.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="en_US.png" iVBORw0KGgoAAAANSUhEUgAAAT4AAAFSCAIAAADkbCRGAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wYbCS03x2AlcAAAIABJREFUeJzt3XtwHNWB LvDTM6PRzEiyZMmyJfAzloRjrXB4+0IuZHfByZoK2ZuLy+xWkVRgNxvX3RTEhhgbYuOX/MQG wiPs5W6y2Vs32aQCLBCyobzEBrN+CD9Hkq2HkY2MJVsaPSxpZrrnce4fx+kc9XS3uud95O9X Lld3z+nTZ1r9zTnd82jJ7/c3NDT4/X5CSENDAyGETQPkv4aGhk/8nbluRW5ILKhlZWWRSESW 5VgsRgiRJElRlGg0Go/HKaXqbCwWGx4evnLlyr333mur/MMPP8zKU0r12yFJ6nQkElGno9Go Oh2Px9Vpvh5+XUVRJlzO18/an1gnT5ZlddrhcOi2x+40vy2j5alM8+wuN5Ku52W0zzMxzTNa 7vF41OmioiJ12uv1sgmfz9fV1dXc3LxixYqMxsRWeRdrnKIoIyMjgUCAHdaU0kgkEovFWBXq rCzLn332WWdn5913322r/PLly0dHRwcGBvjY8NHiWYmu0Z+EX5fHR5ev0+gw4rfF12k3upmO aCaia7Sc31f59nyt7AejNhcWFqrTPp9PnVajW1hYePz48QMHDjz66KMZjQlffvr06YQQRVF6 enp0y/8puoFAoLOzU5bleDzefaG77UxbYOCyx+OZdf2cquuqfN6iaDQqy3JHR0d3dzcrv2bN mp6eHlZDaWmpOuF0Otk2qqurJUnq7u6ORCKDg4Nnz57lezCj3c0fInYPFz5mfBm+HqNe18oh yLN7aObqULbykmf30M/n52s3umpENdNqjAsKCk6fPt3R0cEO+6VLl8qy7HQ6KyoqKioqIpFI RUWF0+l0OBxut3vBggXl5eXNzc1qTJqONo0MjUqSVFZWSiTCetF4PC7LyuBQwOGQXAUFn3Z2 qeVZDO+7775oNOp0Ol977bXh4WHW8cZiMTWGV6Mbi8VYTz06OvrOu+8cPnTI4ZLmVJTQmNL7 Wdvs2bNr6m71FhfJshwKhcLhMCs/MDBwzz33lPrcL77yqiNyZf/7vxvo6w30X77Uc7H19OnW lpZFX/va4cOHw+Ewe8FQFIXv/YyiZbSLjcpYWW40bWVAnrnpjRs3rlu3Tl2+adOmZ555Jrn2 bN++nXCefPJJ6+vu3r37Bz/4QRaeb+rTmfgbuVwu3Wn+JZ4duuywp5QODQ21tLQcO3ZsqP/S 5YufXbr4mRIaGx4aiF5R9r918Jnn/rmpqUmNSUdn+69/8xuf2zNv7ry/+tpSSmgsFguH5Zde erGsKD7nuuo7/vIBPlayLIfD4YGBgXfeeWdwcPCb3/zmz372s1gsFo/H2f/hcDgUCv2poWy/ vPPuO0cOH76+0rdgdpXHUxgbHRwKha50+S8Sufamr7LQq0/J5XItWlj7/RV/F4vK+997699/ 86ueC+cDl3uj0YgkkVKv86677vr4448jkYgkSZIkUUqt9JxW/lRWltsd0KaLrUNn06ZNTz/9 NJt+5plntmzZsnbt2iQ2unr16h07drAzIrbkiSeesL76888///jjjyexXYsy0YtmDTtu1cNm 3rx5L7/8cmdn5+EDf+jv6fa5JU+BVOiSCpySUyIlbumhhx56/fXX1ZiEQ/Lo8BWnd+RKv+/g wf+65ZZbZFl+/vk9bge9/XrPrLmVX5g713+yRS3PtjUwMHDu3LkDBw6Mjo4+8MADb775pppe FsOr0WW56r7QffjQ4esrvX+95M8X33FTV2trz4VPhwZ6QmNy+HLbyKU6R+kMWZZZFCmllZWV gUsXfvC/vtvT/Wnfxc9cUtzjkrxO4ixwSBKhlHi9XrU8O6RSeWVNV1xTGUBm9PDavHkzpXTL li1PP/30li1bCCFqjLdu3UoIWbNmzdatW5966ilCyLZt29hDq1evZhNqT/vkk09SSnfu3Kku 3LVrF3to1apVbOK5554jhKxcuVLd+p49ewghfPdr8fnmW+SMrqHwy/m28dcvjKbZxSF22FdX V3d1dX39619fvnx5eXl5SUmJz+erqKjwer3qKnxMKsqmTZ1SNt0dnuHsjfQV/Ncbh3v7h+tK pNq5hTV1Nz/4j9uO+k/x5dkrRUFBQTweD4VCBw8elCTpgQceePvtt4PBYDweZ2Nml7olRVGO HT3qkMi8WdWL77h5+T+sPfKrnR/s/dwT8YVJOBQNR/r8s76wkI3UWfk777xz5qxZC2/57+wq 17lz58rLy+fPnz9z5szh4eGpU6eyzcTjcTZaZuN1dXekcqnDbkStXNXMB42NjVu2bGHpbWxs pJSuXbu2sbFxzZo127ZtY63dvn07pfSpp55ig2RKqZpe1c6dO5944onnnnuOUrpq1apVq1bt 3r2bFV65cuXu3btXrly5Z88eSinLKqX08ccff+GFFyiljz32WNLtN4qNURmj/Z+u5Tyjl2yn 06lO8wNmNYeSJLF12WF/8ODBffv2/fSnPzU51+VjMnvOrP+57MEPPtg71TM4t+RSYTklM0vk CJGqFv79M699fOTIsaNH+fKsX2WnmR6PR5Kk06dP+3y+b3zjG2+99dbIyMi4XldRFFmWP/vs vMcllXrd51pbDv9q18UzR0udMimKBynxxDwkPlxXN/+3/xGnlLLyZWVlgUDg8uXLwWDw2LFj haNdM6aVU/r1lpaWsbGxWCzGXiTUE13WPt1dmelpsbCDm/WuW7dubWxs3LZt2+rVq5966im1 s92+ffsPf/hDdsju2LGD9bTsITaxa9cu1tnu3r171apV6qN79uzZvXv3nj17Vq5cuWrVquef f37Pnj1siyzGL774ou7gOdMxs7LcSkTtlikoKFCn+ejykZYkyeFwsMOeUtp+qukLCxqio93K YO/+37199ow/pgSHB/ocJD7QerL+H156//331ZhEIpHrr5v5lbv/ovfwOzNKFK9HIoSEw2TB 0mWHP2k6cvggGyHz5dlsQUGBz+fzer1ut7u3t/fQoUOFhYVDQ0Os/NWGsi640FM4xU1jo0MX u8/+Ye/FMmdYksOlrnChh9AYkSm9obaWxY+VZy8PQ0ND+/fvn10U/Pb9t1ZVlL55YG+8+jb1 9ICVZ+ff/AmDyZ8kn89jjaS9J3/66ac19fDjN8bpdKplNNNkfOe2a9cu9WSYX52MH2arD/FH sCpXkUtlf1pZd8LoskEs+WNM5s2bd+TgRz9/bXfg4rkLn55xE6W40FHkdngKJLdLKnaThx56 aOfOnZqYTJ069UQgULRwyorH/4oQ8urz70kxx6lmPx8TvjwhxOv1TpkyxefzVVdXV1ZW9vf3 V1VV9fT0sJIuvnG33HxrkxwYDAWnDvZ6ol5STEudskSk0jKPPEYX3/NAb19fLBZTFIWVj8Vi AwMDBw4cqCunL617fPo939u7fdl0uXO0n4xU3Er+eIbAriqzMIseV6MBYWKuGCuHL//qblKh 0+nctGmTZokmrox6/K1du5aNvQkhO3bs0FwAc7lcjY2N6kK+Bt0mZaLHsyLTlxL56OruBBak WCzGDvvq6up9Ta1Lly7z+XxG57qamMhy+JWXX1pURoMh+uoL7xV6yoIh0nam7YYFX/KfahkL BjTl4/H42NhYUVHRtGnTZs2aNXXq1JKSkrNnzzY3N0+bNo3Fatxlqqqqqjmz5w53+cNjcpiE Q5QWehxlZYUPf+fu373Rctu3NzVuf1lRFPV8OhAI/P73v79hmmPVdx6svOsr5954xn+8yUFj 5aEOX8gz5cb/cerUKVbe4XAkXqbKxFv5RlI5B0ulV5lwuTqxceNGvgB/DG3YsIEVe/bZZ599 9lk2oa64fv16Mj7GDodDfc9p3bp1jY2NDoeDzf7oRz+ilLL/2SwbkBPjU74Jn4uRTPeW6arH aJCs5lC9rssOeyvnunxMFCXy8qsvTy+Q517nVWYsXvClRcP9fUq8teDMr+UC+hdfWfL2u+/y 5dXLVKWlpfX19dddd90NN9zw+uuvt7S01NTUsJYoiuIihDQ0NHzwwQfRaNTj8dbU3XKRyOHL baFo2BPzkBgNj9Hfvd3y1e82njjV0dbepg76o9Hom2++Oas48nfLHrxj+bL2t/7fsUMfReSg u8BVUuKpdne7w8cWPfydjz76yOFwsNcJkwFzKjG2e0XRSkSzcylly5Yt/Bu57FhhXatmeuPG jSyiLLr8EkLIhg0bWP1sgh1/GzZsUHPOzzqdzs2bNzudTlZ4/fr1bDk7gvlpk+eSimyeyFhh 9L4uP2B2uVwul4sd9pTSS22HKmtujV3+5PKZk6MDPcHBXmd0rOvTs2G5PxbdK9VveOONN9SY 9AV6Z011LJjiu/mev/7HLf/07jvv9SsXpt99m3z0V/GO38758pf/9m+WHzp8SC2vhrOkpKS0 tHTRokXr168/f/58XV2dGiJJkv50rsvW8RYX1960ZORSrdzXLCu94aijat6iJWteONna//r/ +Rnb6ZRSVt7pdFZNiV+8+PnP168PDV26eK69uNDhcDqKiz3LH1r8b788ULH0Cb68yRVmnpXe NV1xtRtjK+20si0Vu4yszrL3hNj//JK1a9euW7dOnWVH1ebNmxMrZAtZnZoBtjrLJvhH+WlN /59RVvZzJvDbMjpT4KPrcDhYDxSNRufNmxccG9v3by/+/H//2OuIlBRQVzxY6nUUul3Tp5f+ zd/+N3LnQ5s2bVIP+4qpU++546bpJZ4V619577e//8P+ffF4/PrrZi759mba+e4Xv3znqdbL hIsJyyebdbvdjzzySH9//+LFi9X3ddlO+1N0w+Gwem3aXT6zqnZh3fz5DV/8s76Bwa3P/d+z Zz9lV8BYAVb+xhtvnDl37tiMWZ6KiqKCgi8tKYpEImVlZZTSD6PeG1es9nq96sVu1iz+01T8 n83KJ6JSGTCnMvBOpWdOBV/npk2bWHQJIRs3bkz64rndFe1Gy+5Lod2TFP4SgJX6rVyD4I8x 3bapV4DZYV9dXb3llV8sXbr0odWvGp3r8jEpnzpj7l8u93l9//qLXxw9epSNh9s72kpKim+7 5aunWi9HlDhfnsXwwoULoVDokUceqa6uvuuuu0KhkBppFkMXIcTv9x87dqyjo+PcuXPss8cs YP/5n/vVvltt0JUrVyKRSF9fX0dHRzweb2tra21tVQsYld+/f397e/uFCxfC4bC6a+x+aNGI 3RjzMtHzG7EyUjBx7733sokPP/zQ1nZ5dl+e7I50jKLF/x2NPvZg1B7+b8QPaFOpn8evq9vr xuPx7u7uWCzGDvvi4uLu7u5XXnllwsOeldfESi3f3Nz8Lz83LO9yuT7++GO32z1jxoy2trbE +q/uiJMnT544cWJkZIR9zlE9Y2afpuBn2ftOdsv/8pe/7OnpGRwcDAaDursvlR7VqJ50Lbfb e9iNaCYGirl6vkbfrDKKh1G0jNblrwZnon6jddlbm5mOCV++q6srEolMmTKlu7tbt7ykfsm+ s71F90kCQB4a9x7A/NqFuWoHAFgkSVJne4v27buzHa05aQ0AWPHhvr1sYuKTeADIQ4gugJAQ XQAhIboAQkJ0AYRkNbo1dfXqP1urJNuwLEnieakrplg46U0n3YwcboWvIbna8v9YyrKr3xyy UlT9zEZNXf2En9+wUibnNI3Mfptt7VIAXvIDZvYqqL4W8r1Hig9pXqGtz6aID5J5w2w9C01h o02b1KaZ1n3WVtqszprsxuTab469MGlq0G1D4hPnt46Ol6fzjWoj6o5L7Cs0E+zvpPuQrQlb s+nZH+NrS8sT5Atb37rRKroFrLSZ/PEPN+FuTKX9Fhm1weiJZ6INorv6zSErY2bdHapOm7wi ah4yWcvob8P/XfmFbDYLf1HzTVh8FhYlPsfEg9tKPdabkd72J1auvnBoXkQgFTZ6XXMmf4zk HrJSPhO9bhLSu/UJa0v7k8303sNANxPS/OaQ9b7X4kO6BTJ05pNihamfDerWZjRWtLvTrLTB VnmLdbIht/oPZ63pkp5e12TsmtxDugXMZ1NptjqrWTjhOJk/HK0UTlyo2ZDdfZL4RKxXZatY eoc2Rn9K3SUZaoPoxn1fd37tQnxzaHLAUT5Zfbhv7yPffawz8Ut/unSHN6IfGUZjNtGfV17B Ts4cS9GdlDt6Uj4pVZ48uzxpxqSEzzADCAnRBRCSdsCs/nwGAOSzcdHN5s/PA0Aqxn1zCBcV AESBc10AIaXtM8z5QPTfkcbnYcA6G98cynOT4KNg+AgUWKftdUtLp+akHcCu7Wd//w8PD2Z5 i5AW46JbWjr1+Ccf56opKbpv6YO5bkIaZH//L7l/Gbp6EeEy1TXtk6bDuW4CJAnRBRASogsg JEQXQEiTPLq6v7RgUixxgnC/M6r7qPVNA6SRpY9kLLl/mTr9/m9/bWsDS+5fZneV9EritxSJ 8Y+bW3/rNS2Xbfk9TxJ2Ptu36h7O+a6GbJo4upoDYnIcH0a/ZqwuMYpo4i/RJr4uJP6acWIx 68GecG9Pgj8HJCHJATPrDZbcv4zvFjSzmvLqQ4kTmmKaAta3oov/FcIJf2CNWA6V5jfl+J8+ 1Ay2dYulMpxO3CGa/4nxnkx6o5BvbNxzSEMzTjMZtlkc0fGPJq6Sb4PDpH9B2m5oNWcr/B7g ixntnPzZY5BeyX/9IPE4MHpR1z1iLB5J1rdiIq9ue2G3GUZ7iWU19XpAUOn85lB2Do78ueiV yor581ICgnIQQthPMaeL7hksP2u3u7C4FVtYP2z+RpGmJPtn/svmiWXU5fwvg6cltzhxvcZN 3Otqkjbh+C2xgO5DJsWS24ou/lYARhPWH9VdoruKleUWaXY+vwd0XyX5MiTXgxTInHF3P8ja N4cyccnkvqUPCv19Xfar9llO2idNh9c+uwtDdxHl4NNUuNQJkLocRBe5BUjdJP8MM8BkhegC CEl7k85ctyd5Ql+jUgn9J4DskCRJ5yadkyMA4sL+B4swYAYQiXpXMEQXQEgOkuw3hwAgh9Dr AggJ0QUQUvq/OQQAWYBeF0BIiC6AkBBdACEhugBCQnQBhIToAggJ0QUQEqILICREF0BIiC6A kBBdACEhugBCQnQBhJTO24VBNigKCQZJWJbCYaIoRFFIJEqiERKNkXic0DihlFBKJIlIEpEc xOEgLidxFZACF3G7idtNPR7iKSQ+H3G7c/1kIHmIbt4LBqXhYXJlhIyOkrExq2uxAJM4iRES IYSE1EckvlhRESkuJlNKaGkp8fnS12jIOEQ3LwVDUiBABgbI8HBmNzQ2RsbGyKVLV/NcWkrK y2lFBfF5M7tdSBmim09GRqXeXnK5j8SiuWnA8DAZHpa6uojTRaZX0qoqUlKcm5bARBDdPBCL SRc+J59/TqI5SmyiWJT09Eg9PcTlItdfT2deT5zOXLcJxkF0c2psTDp3ngQCuW6HsWiUnD8v nT9PKiro3DmkqCjXDYKrEN0cGRuTOs9m/FQ2jQIBKRAgpaW0Zj4CnA8Q3ayLx6W2dtLXl+t2 JGV4WDp6jFRW0hvqiAMfCsglRDe7enqljo5cNyJlfX1SXx+trSXVVbluyrUL0c0eqaU1r09r bZI6OsjAAK3HrQlzA2OerAiHpUNHJlNurwoEpENHSDic63ZcixDdzBsdlY40EUXOdTsyQ5Gl I01kdDTX7bjmILoZFgxJx47nuhEZJx07ToKhictB+iC6mUSpdM3cFEby+wmluW7FNQTRzSDp TBuRkxknf2/F9ydckro01ynL0pm2dFYIpnCFOWP6A6m8efu9Fd//yas/Vqc1S5Kr0HwradDX RyorybSKtFUIxtDrZop0/nx6K7SbMT6rfER/8uqP+el0NY9J+7MGI+h1M2NoyMZ3a8djkdN0 uXzGrHeVmvTabQPPasjHxsjQECkrs74tSA6imxFSf0pv4SbmRJMl6+n9yas/VsNvMb26lVvf otQfoIhu5mHAnBlXriS3nnpay8+yzGR0oJtOyT53sAXRzYxQGj5gxDo6zciZJOQ2xQvFRpev kq8xHc8dJoQBc2Yk9TMXLKuaiGpGqib9LZ83i8V0r12nMlomJMnnDnYhupnhdCVxBBvFgx8/ a65X8ROJ/fOEm0i8Bqa7dXvjcycOqmzAgDkzvJ60VKMJoeZSk3oOTMbn1ihpSZwhJ/PGb5qe O5hDdDNjypQ0Vpbek9s0VqIvrc8djLgIIQ0NDbluxmRDp1VIFy+mWInuaJZ1vEbv36gTiYPn 5D5cmURHTfFpqqzAaUlmlJWRoqKkP5VBJhqp8u8SqSUTL2vpXujSbCXpFuorKsLnMbIDA+ZM oXPmpLK6ldyqdBOYkzeBU3zWYJ2LEOL3+zFmTr9pFaSyMvWfjzPvGDXvJ1nvRY3eJU4sYyP5 +O5BFqHXzSC64AZSWJjEipp3WTXXkBNL6n61wMom0tkhFxbSBTekrTaYiOT3+wkhDQ0Nne0t 82sXnu1ozXWTJpdgSPrkk1w3IhvorbfiTkVZ8OG+vY9897HO9hb0uhnm89Kbb8p1IzKO3nwT cptliG7mFRfT228j7mRGzgJwF9LbbyPFuKtYtiG6WeHx0MW3k4pJdwmnooIuvp148PGpHEB0 s4fWL6S1tbluRdrQ2lr8fnoO4SMZ2VVdRWdMF/ieQwzuOZQHEN2sczjoFxeQ2bMEu9Mfgzv9 5Q1EN0eKiuiiGwW4v64K99fNM4huThUV0fqF+XhXexXuap+v8M2hPOB00jmzyZzZZGRU6u0l l/ty/0MTTheZXkmrqkgJ3vXJU+h180lJMS2pIbU1JBiSAgEyMJDtk+HSUlJeTisq8PmK/Ifo 5iWfl/pmklkzCSEkGJSGh8mVETI6msq3CPUVFZHiYjKlhJaWEp8vzZVDJuGbQ3nP56M+H6mu vjqrKCQYJGFZCoeJohBFIZEoiUZINEbicULjhFJCKZEkIklEchCHg7icxFVAClzE7SZuN/V4 iKeQ+HzE7c7pE4OUoNcVjdvNIoeb6l3j8K46gJAQXQAhIboAQkJ0AYSE6AIICdEFEBKiCyAk RBdASIgugJAcBN8cAhAQel0AISG6AEJyEELYDRAAQCDodQGEhOgCCAnRBRASogsgJJ1fyZhf i7tRAOQjSZL++Z9eYNP6P3CDu+wC5JsP9+3lZzFgBhASogsgJEQXQEiILoCQ8M0hACFZ7XVr 6uqtF+P/t1ibxfrTi99oTV19TtoAkJw03/2gs70lyyumRU1dfW4bAGBXkt8cUjsozYR5x6Xp 2RK76MRHE9fiF6prGbVHd6Oa2qy0HCDfZO+eQ2rPpgmSeXfHr6UpqVmuW5XmUd3C/HIAUSR5 hZkd7uqsrUOfL5mYRrUPVB9K4ixUXZ1VmGJtAHlIgDv9pdgfarpZ9K4wOST/vq46zrQ72jTv 9IwqtNhVJg4HkmgDQP7LXq+rhkqTLutr2dqW7urJ1QaQh6xGV/dYTxyC8ksSV+ETpbui7rZM Nq07Yd5y3Q0hySCcyfZBSFwrhmvEZIsucgvXiMkWXYBrBKILICQX0fvmkOanNAAg3+hcYZYk KfvtAABbdKKLKz0AeUsdEeOeQwBCwmUqACEhugBCQnQBhIQblwAIAzcuARAPblwCMBkgugBC QnQBhIToAggJ0QUQktV7Dqk/WZ6JH2rDj7wB2GXjZ+X4nzJO71cU8IUHALtSGjBPeEsRwt0W RPfuIbr/m5QEAMZFCPH7/RbHzGzC5I4hutMmdw9J3ITFkgDXOBu9bmd7C/tnfiMv3RUtLrde EuAal9JPqCNRALmShjeHkh7NWl8RA2YADRu9ruZcV/cmIPxw2mT0a/EOJsnd6wTgWpCGG5do ppO4UYjJfUwwJgfQlZubdE7YMydREuCakpvoJncfbQBQ4TPMAEJCdAGEpD9gxo1LAPKczj2H cOMSgPyHG5cAiGTcjUsAQDi45xCAkNDrAggJ0QUQEm5cAiAM3LgEQDy4cQnAZIDoAggJ0QUQ EqILICREF0BIiC6AkKzecwgA8gp6XQAhIboAQsI3hwCEhF4XQEiILoCQEF0AISG6AEJCdAGE hOgCCAnRBRASogsgJNy4BEBIOtHFjUsA8h9uXAIgEty4BEBsiC6AkBBdACEhugBCwo1LAISB G5cAiAc3LgGYDBBdACEhugBCQnQBhIToAgjJanRr6upNZvNQTV19/jcSIGmTs9etqavvbG/p bG9BemGySjW6rHNTE2IyYVKen00Mm26d5hvFl59g0tP/SIYu3VCpIeGnTSSWN5kwaobFjVps EoCIbESXj4HRQJSNUc2jpVnXSrVGVZlAbmFysxHdtOC71sRHETYAi9J/mUrteJPu9xK75SSu NuFVACa3lHpdPlQWo6KukhhI/iHdFY02qpttDJhhcrMaXU0M+CAZFTZKjsm61vOfxBKAyUSA 93XRfwIkEiC6yC1AIgGiCwCJEF0AIeHGJQBCwo1LAISEG5cAiGTcjUsaGhpy2hgAsA2XqQCE hOgCCMlBCPH7/bluBgDYg14XQEiILoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiI LoCQ8M0hACGh1wUQEqILICR8cwhASOh1AYSE6AIICdEFEBKiCyAkRBdASIgugJAQXQAh6dz9 YH7twuy3I5EkSZTSrG0L93wAsejfLuxsR2uW26Gh3p0hCy3BvdFARBgwAwgJ3xwCEBJ6XQAh IboAQsI3hwCEZKnXramrr6mr52etrDLhkuSwxqSrNgBB6b85lLdq6urVN2D5aYBrjdVz3c72 Ft2OdMIOMLEAvySVLpTllq+Kn9DUzC9MYlsA+Sb5XtdKB6gu5yOkLulsb7HbhfKvIOblE2tO nAAQl43ostgkd9DzkUvshO1Wpa7Iwm/0IqKpGXGFySQH57p8hBK7ZXPWXzvs1gwgFnvv6+qe 8VqRuQvOhBsOmAcbGYbJJPle18ppp1pGdyJx+YQ9qq1zXfNNAwjNUnT5Y91o2mgVkwnz5VYa o1loUjNCC5NMRs51LXaMSVfLQxrh2uQiGfjmUIYME65jAAADGUlEQVTilEq1SDhMMvj6AYCQ EF0AIbkIIX6/XzNmzp/ffMmflgDkFZ3LVJIkZb8duvKnJQD5Rie6uKIDkP9wrgsgJEQXQEiI LoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiILoCQEF0AISG6AEJCdAGEhOgCCAnR BRASogsgJEQXQEiILoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiILoCQEF0AISG6 AEJCdAGEpL1JJ25FDSCEcdHFragBRDEuurgpNoAocK4LIKSrvW53d3ckEpFlORaLRSIRRVEI IcFgcGBg4MqVKw8//DB7lFJqUpdmvB2JRPjZaDTKz8bjcX5WU7OmKtYei49qthuLxUw2xJNl mZ91OMa9rmkanMqspg3mj6Zx1uJDEz5qLnO7gv9TZm4vWd+HEz7q8Xj42aKiIn7W6/Wq0z6f r6urq7m5ecWKFSZJvPfee9mjra2tV6OrKMrIyEggEGClFUWhlIbD4Y6Ojs7OzuXLl4+Ojg4M DGhSYX5ubCu6Gpo9oqlKQxNdzYbMo8s3Q7OVVKKbq3BmJ7rmj2p2eIZ2VD7sw8QGa2YLCwv5 WZ/Px8/y0S0sLDx+/PiBAwceffRRkyTefffd7NGTJ0+6CCENDQ2nT58OBAKdnZ2hUCgajSqK EovFZFlubm7u7u6ORqP9/f1nzpwJhULW223+J7T1aCqz1g+OXB0N2ZnN3FZy8sKUn92s5lE+ nImzfJIdDkdTU9OJEycURTFJovroqVOnrva6R44caWpqOnfuXDgcZqVZSi9cuDA6Ojo2NjY4 OBgMBjX9W9bCaWvnmtP0pSZHg0bm/sCZezTpXjdrhdO4bibqSbHmgoICi7PRaDQSiUSjUfMk qo8eOXLkanRPnjx54sSJkZERlvVYLBYMBgkhoVAoEol861vf6unpYem1/qzSmLfsHOvmDdac HZjPaqTyaLpk7hUhlR1lflaieQV3Op1GK2qY16OJkPWNprhd86rY+Zp5EtVHg8Gg5Pf7CSEN DQ2EEHWaTQDkuYaGhsx1sHnu/wPur6N3B7/qtwAAAABJRU5ErkJggg== --------------010503000008060104000107 Content-Type: image/png; name="zh_CN.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="zh_CN.png" iVBORw0KGgoAAAANSUhEUgAAAT0AAAFPCAIAAACwE44AAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wYbCSwoU3MZxAAAIABJREFUeJzt3Xt0HNWB JvBb3S31Q2/JsiXbAhvLwrEDJIEsLGQhOwNOxpyQ2Sw+ZuYc4MTMMMPZ2QOxIcaG2NiyZRsb G1geh4zzYjabTHICLBCy4XgSG8z4hY0fkrAlGcluIcmW1Hp3d3V39d0/rqe4ru6qru6uftzW 9zs+PvW4VXW7VF/dW9WPks6dOzcxMTE8PBwOhwkhlNJwOKwoiqIo/KgsyxcuXOjq6mpubk6q /J49eyYnJ30+HyvPSJJE4uHLRCIRdTgajcYtTymNuywvFArFXSercOx6+G3x67TZbHHL6A3r rZOfnolhnlXT+X2Vb6/XzH7Qq7PT6VSHPR6POux2u9UCn3zyyYEDB375y19mNCZ8+ZkzZxJC QqFQf3+/XnlHKBQaHh7u6uqSZTkajXp7vWfPnB32XXK5XA1zrq6bXedxl0QiEVmWOzs7vV4v K7927dr+/n722ioqKtQBu93ONlBfXy9JktfrDYfDIyMj586dk2U54b7mj49kjxU+Y3wZfj18 Gb316x1/vGSPy1wdx2bOd8ke9/n8epPNrZpPzbCa4aKiok8//bSzs5Md9suWLZNl2W6319TU 1NTUhMPhmpoau91us9mKi4sXLVpUXV3d2tqqxuTosaMTo5OSJFVWVhCJRCKRaDQajUZlOTQy OmyzSY6ios+6utXyLIZ33XVXJBKx2+2vvfba2NhYNBqllCqKwsfQoShKOByWZXlycvKdd985 fOiQzSFdXVNGldDAhbNXXXVVY9NN7tISWZYDgUAwGGTlfT7fHXfcUeEpfvGVV23h8f3v/8E3 ODA8dOlif1/7p5+2t7Xd8O1vHz58OBgMslNFKBTi2z29XOntX70yZqbrDeu159k5tjZt2rR+ /Xp1enNz89NPP51afbZv3044TzzxhPlld+3a9YMf/CALrzf94Uz8jRwOR9xh/vzODl122FNK R0dH29rajh8/Pjp08VLfhYt9F0KBqbFRX2Q8tP+tg08/99OjR4+qMens6vjt737nKXbNnzf/ r769jBKqKEowKL/00ouVJdGrZ9ff/Jf38LGSZTkYDPp8vnfeeWdkZOR73/vez3/+c0VRotEo +z8YDLLyDnWnvPPuO0cOH55T61l0VZ3L5VQmR0YDgfHu031EXvjVb7G4q6/H4XDcsHjh/3zk 75SIvP+9t/7v737T33t++NJAJBKWJFLhtt92220fffRROByWJEmSJEqpmTbTzN/JzPRk+7FW Seq4aW5ufuqpp9jw008/vWXLlnXr1qWw0TVr1jz77LOUUvXq4/HHHze/+PPPP//YY4+lsF2T MtF+Zg07btXDZv78+S+//HJXV9fhA38e6vd6iiVXkeR0SEV2yS6RsmLpvvvu27NnjxqTYECe HBu3uyfGhzwHD/77jTfeKMvy88/vLrbR/zTH1TCv9pp5806fbFPLs235fL6enp4DBw5MTk7e c889b775phpdNYYOFipvr/fwocNzat1/vfS/3nLzV7vb2/t7Pxv19Qem5OClsxMXm2wVs2RZ ZjmklNbW1g5f7P3B/3i43/vZYN8FhxR1OSS3ndiLbJJEKCVut1stz46ndM6pVmU1nX5jRo+t zZs3U0q3bNny1FNPbdmyhRCiZnjr1q2EkLVr127duvXJJ58khGzbto3NWrNmDRtQ29gnnniC Urpjxw514s6dO9ms1atXs4HnnnuOELJq1Sp167t37yaE8A2vydebb3nTu2/CT+frxt+z0BuO RCKKorDDvr6+vru7+zvf+c6KFSuqq6vLyso8Hk9NTY3b7VYX4WNSUzmjqrxyZnFwln0gPFj0 728cHhgaayqTFs5zNjZ97d5/2nbs9Cm+PDtNFBUVRaPRQCBw8OBBSZLuueeet99+2+/3R6NR 1lUOh8MOWZZDodDxY8dsEpnfUH/LzV9b8Q/rjvxmx5/2fu4Ke4IkGIgEw4OnG65ZzHrnrPyt t946t6Fh8Y3/JRQKTUxM9PT0VFdXL1iwYO7cuWNjY1VVVWwb0WiUdZJZH13dF+nc20g2n3r3 n3J+LtdoaWnZsmULi25LSwuldN26dS0tLWvXrt22bRur7fbt2ymlTz75JOsbU0rV6Kp27Njx +OOPP/fcc5TS1atXr169eteuXazwqlWrdu3atWrVqt27d1NKWVAppY899tgLL7xAKX300UdT rr9eZvTK6O1/q6bz9M7XdrtdHeb7yWoIJUliy7LD/uDBg/v27fvZz35mcH3Lx+Sqqxv++/J7 //SnvVWukXllF53VlMwtk8NEqlv890+/9tGRI8ePHePLsxaVXV26XC5Jkj799FOPx/Pd7373 rbfempiYYO1tNBp1hEIhWZYvXDjvckgV7uKe9rbDv9nZd+ZYhV0mJVE/JS7FRaJjTU0Lfv// opRSVr6ysnJ4ePjSpUt+v//48ePOye5ZM6op/U5bW9vU1JSiKOz0oF7cso3F3Y+ZHhYLO7JZ u7p169aWlpZt27atWbPmySefVJvZ7du3//CHP2TH67PPPsvaWDaLDezcuZM1s7t27Vq9erU6 d/fu3bt27dq9e/eqVatWr179/PPP7969m22RZfjFF1+M22fOdMbMTDeTz2TLFBUVqcN8bvk8 S5Jks9nYYU8p7Th19JpF10UmvaGRgf1/ePvcmdNKyD/mG7SRqK/95JJ/eOn9999XYxIOh+fM nvvN2/9i4PA7s8pCbpdECAkGyaJlyw9/fPTI4YOsY8yXZ6NFRUUej8ftdhcXFw8MDBw6dMjp dI6OjqrlHazldbqc5cVUmRzt8577896+SntQkoMVjqDTRahCZEqvXbiQZY+VZyeG0dHR/fv3 X1Xif/Dum+pqKt48sDda/3X1koCVZxfc/EWCwd8jn69d9Vjehj/11FOa9fDdNsZut6tlNMPk ymZt586d6gUwvzi5snetzuIPX1Wu8pbO/jSzbMLcsr4rIYQd9vPnzz9y8MPXX9s13NfT+9mZ YhIqddpKim2uIqnYIZUWk/vuu2/Hjh2amFRVVZ0YHi5ZXP7IY39FCHn1+fckxXaq9TQfE748 IcTtdpeXl3s8nvr6+tra2qGhobq6uv7+frW8g9Xsxq/ddFQeHgn4q0YGXBE3KaUVdlkiUkWl S56it9xxz8DgoKIooVCIlVcUxefzHThwoKmavrT+sZl3/OPe7ctnyl2TQ2Si5ibyH1cF7B4y S7LoWdXrB8aGijFz7PLndYMV2u325uZmzRRNVhn14Fu3bh3rchNCnn32Wc0dL4fD0dLSok7k 1xC3Splo68zI9L1DPrdxdwJLkaIo7LCvr6/fd7R92bLlHo9H7/pWExNZDr7y8ks3VFJ/gL76 wntOV6U/QM6eOXvtoq+cPtU25R/WlI9Go1NTUyUlJTNmzGhoaKiqqiorKzt37lxra+uMGTPU WF2+L1VXV3f1VfPGuk8Hp+QgCQYodbpslZXO+79/+x/eaPv6g80t218OhULqBfTw8PAf//jH a2fYVn//3trbvtnzxtOnPzlqo0p1oNMTcJVf/99OnTrFyttsttj7Upl4v15POtdd6bQnCaer A5s2beIL8AfQxo0bWbFnnnnmmWeeYQPqghs2bCBXZthms6lvL61fv76lpcVms7HRH/3oR5RS 9j8bZf1won+Zl/C16Ml0O2nVevT6xmoI1bu47LA3c33LxyQUCr/86sszi+R5s92hWbcs+soN Y0ODoWh70ZnfykX0L7659O133+XLq/elKioqlixZMnv27GuvvXbPnj1tbW2NjY2sJqy8g118 ulzuxqYb+4gcvHQ2EAm6FBdRaHCK/uHttm893HLiVOfZjrNqRz8Sibz55psNpeG/W37vzSuW d7z1f44f+jAs+4uLHGVlrvpib3Hw+A33f//DDz+02WzsDGHQT04nw8nePzSTz+zcO9myZQv/ hi07UFijqhnetGkTyyfLLT+FELJx40a2fjbADr6NGzeqIedH7Xb75s2b7XY7K7xhwwY2nR2+ /LDBa0lHNq9fzNB7/5bvJzscDofjckwopRfPHqptvEm59PGlMycnff3+kQF7ZKr7s3NBeUiJ 7JWWbHzjjTfUmAwODzRU2RaVe752x1//05Yfv/vOe0Oh3pm3f10+9pto5++v/sY3/vZvVhw6 fEgtryazrKysoqLihhtu2LBhw/nz55uamtQQsRg6IpEIW8BdWrrwq0snLi6UB1vl0EAwYqub f8PStS+cbB/a85Ofsz1OKWXl7XZ7XXm0r+/z1zdsCIxe7OvpKHXabHZbaalrxX23/OuvD9Qs e5wvb3A/mWemXbUqq8lm2Ew9zWxLxW4aq6Ps7R/2Pz9l3bp169evV0fZIbV58+bYFbKJbJ2a frU6ygb4ufywpuXPKDP7ORP4beldIPC5tdlsrPmJRCLz58/3T03t+9cXX//n/+W2hcuKqCPq r3DbnMWOmTMr/uZv/zO59b7m5mb1sK+pqrrj5q/OLHM9suGV937/xz/v3xeNRufMnrv0wc20 690vfePWU+2XCBcTFk42WlxcvHLlyqGhoVtuuUV9/1aNoSMSiQSDQfU2dHH13LqFi5sWLLju S18e9I1sfe5/nzv3GaVU/dQIK3/99dfPnTdvalaDq6ampKjoK0tLwuFwZWUlpfSDiPv6R9a4 3W71vjarE/95Kf5vZuYzT+n0k9Ppb6fTJqeDX2dzczPLLSFk06ZNKd8qT3bBZHOV7Hkw2WsT /rLfzPrN3Hfgj7G4dVPv37LDvr6+fssrv1q2bNl9a17Vu77lY1JdNWveX67wuD3/8qtfHTt2 jHWDOzrPlpWVfv3Gb51qvxQORfnyLIa9vb2BQGDlypX19fW33XZbIBBQ86zG0DE4ONjZ2dnT 08M+V8zS9W//tl9tstXajI+Ph8NhVj4ajZ49e7a9vV0toFd+//79HR0dvb29wWBQ3S96+dQb 1pNshnmZaPP1mOkjGLjzzjvZwAcffJDUdnnJnpuS7ePo5Yr/O+p9tkGvPvzfiO/HprN+Hr9s 3PY2Go16vV5FUdhhX1pa6vV6X3nllYSHfdxYqeVbW1t/8bpueYfD8dFHHxUXF8+aNevs2bNx 1+84efLkiRMnJiYm2Oen1Etk9pEJfpS9v5Rs+V//+tf9/f0jIyN+vz/h3ymdHGbiWjTZdiPZ fGaif5ir16v3fSm9bOjlSm9Z/t5vJtavtyx7FzPTMeHLd3d3h8Ph8vJyr9erV14ihHR1tMV9 hQCQhxqbllzueyxYuDi3VQGAhCRJYq3sF9cM5zrbc1cfAEjgg3171eHE1+4AkG+QWwDxILcA 4kFuAcSD3AKIJ3FuG5uWqP9MrjSpwrmSwutSF0yzcMqbTrkaOdwKv4bU1pb/x1L2xfnSViz1 gxmNTUsSfkjDTJmc01Qy+3VOapcCaKTST2bnP/UsyLcbac7SnJvNj6aJT5FxxZJ6FZrCeps2 WJtmOO6rNlNnddRgN6ZWf2PsrKRZQ9w6xL5wfutocjVMtbfqXottJTQD7I8Ud1ZSA0mNWrUv +LVZ8gL5wua3rrdI3AJm6kz+4w+XcDemU3+T9Oqg98IzUYcCkFw/Oe4Ug3OhZpbBUnp/GP6P yk9ko1n4cxpvwuSrMCn2NcYe2WbWY74a1tY/duXqWUNzBoE0mcqtMYO/RGqzzJTPRHubAmu3 nnBtlr/YTO899G8zxLL3gcy3uiZnxS2QoaudNFeY/hVg3LXpdRGT3Wlm6pBUeZPrZD1t9R+u VC2Ubntr0GVNbVbcAsaj6VRbHdVMTNg95o9FM4VjJ2o2lOw+iX0h5leVVDFrOzV6f8q4UzJU hwJw+fu3CxYuxveBCgMO8UL1wb69Kx9+lJ3XErS3cXs1oh8Wel010V9XXsFOzqgEuS3IvVyQ L0qVJ68uT6pRqPD5ZADxILcA4vmin8z/CgYA5LPLuc3mD8YDQJou5xZ3EQAEgutbAPFY8Pnk fCD67z/jQy+QlELIbQF82AsfcoKkfJHbioqqHNZjOmN38rO//8fGRrK8RbDK5dxWVFR98vFH ua1Kyu5adm+uq2CB7O//pXcvRyMvKNyXmqY+Pno411WA1CG3AOJBbgHEg9wCiKdgcxv3NxMM isUOEO4nQuPONb9pAGsleP926d3L1eH3f//bpFa99O7lyS5irRR+CZHo/yK5+bdYLblJy+95 ErPz2b5V93DOdzVkmVFuNUdDYRwcer9CrE7Ry2fsj8jGnhRif4U4tpj5VCfc2wXw54DUJN1P Zu3A0ruX8w2CZlRTXp0VO6Appilgfitx8b8hmPAX0ojpRGl+FI7/4UJNHztusXR60bE7RPM/ 0d+TKW8U8lAqn3PUdM8MemsmO3L83NhF8q1PmPIvPyebWM1FCr8H+GJ6Oyd/9hhYLpXcxh4E eqfzuIeLycPI/FYM5NVTKpKtht5eYkFNfz0gLmu+V5CdIyN/7nKls2D+nEdAXFZ+H8ign8wk 21CY3EpSDK4wNYmK+9voxiuMu7hVv9WuwsUqGOVWE7OE3bbYAnFnGRRLbStx8T/erzdgfm7c KXEXMTPdJM3O5/dA3Bt7fBmS6+4JZNTl5xVk7ftAmbhHcteye4X+/i37Hfosx+zjo4fXPbMT PXYRNTYtyernpXBjE8ASWc0tQgtgiYL9fDJAAUNuAcTzxXM0c12T1Al9U0ol9J8AskOSJO1z NAvj6BcX9j+Yh34ygBj4J3ghtwDiQW4BxIPcAogHuQUQD3ILIB7kFkA8yC2AeJBbAPEgtwDi QW4BxIPcAogHuQUQD3ILIB7kFkA8yC2AeKz83XPILEUhwSCRZSKHpHCIhCMkHCaKQhSFKFES VQglhFJCKCESkSQiEWKzE7uN2O3EbidFRaTIQYuKibOYOJ3E5SJ2e65fEqQIuc1jfj+ZmpIm p0ggQAIBEo2aXpISSgklJBolkStmSPyIzUbcbuJ209ISUlJCPB5rqg2Zh9zmmfEJaWyMjI8T vz/j24pGydQUmZqShoYuT/F4SHk5ragg5WUZ3zqkAbnNA9EoGRqSfCNkYiLHNfH7id8vDQwQ QkhZGa2uIjNmEBtuguQd5DanBgelS4PZaFpTMDEhTUyQ8xeIx0Nn1pLa2lxXCL6A3OaC3y/1 DxCfL9f1MMfvl3rOk57zpLqa1tfhMjgfILfZNToq9X5OAoFc1yMlPp/k8xG3m86dQyorc12b aQ25zZaxMen8BSLLua5H2gIBqbOLOJ306qtIRUWuazNNIbeZFwxK3T1kcjLX9bCULEsdnaS0 lM6fR1yuXNdm2kFuM0vy9hJ2e7YgTU5Kp1tJXR1tmJvrqkwvyG3GBINSZxcJBnNdj8wbGJBG R+nCRjS8WYO35jJjeFg63TotQssEg9LpVjI8nOt6TBdob60n9fWRz/tyXYsckD7rJrJMZ8/O dUUKH9pbi0le7/QM7WWf90leb64rUfiQWytJn/eRgYu5rkWuDVyUpvOZKyuQW+sMDZM+HK+E EEL6+sgQrnUzCLm1SDAodXfnuhJ5ROrunka35bIOubWG1HM+11XIO9gnmYPcWsHnS/8reA88 +FDCKVbNTa1k0iYmhPnuhGjwPpAFJIvuRT3w4EOv/+In6rBmikH5uNmLu6z5kpaQBi7S6upM rHmaQ27TNjVFpqYytG6TcdIUY+FUI82fC17/xU80cw22EjfkySWc7ZySkiQWAROQ23RJI6Pp r0STn9g4aZpEg7zFXTbusPn68NOTbZylkVGK3FoN17dps+iLPnohYf+IfhdXM/r6L34Suyp1 ipnIGZwUDLrlugrsi1D5AblNWyDddzs0seRjw4dQzYymZGx006yPtetJf/9ALOQ2bZFI4jKm aRpMNTx8es00nsmmji/PNqHX/htvNw5L9w8wuL7NMf5eEYl3M4mYyEncJjfhvWjz5WNPH5Bb yG3aHA4SCae8dMKoxMZJbfT0bkElTJfB/ecUqpqAA8eY9dBPTpvb4i+LaxpPvjW2RGrxS72l tXr/AEFuLVBamom1xm0S+VmpXGrGMHlGSGsrmdk/0xxymy5aZeUvksZNY+y7L7E3rsysllz5 3pLB20sWsnb/AINrj7SVlJCSEks+MmV8JynudayZD0LEvdel2a5xrUjKTS7bOWA1tLcWoHWz LFlPsqHlC+hlL6lPXMTSvFecLKv2DGigvbVCdTW5NGjhU7kShiT2XaLUbl8lfIMn7l1rs8rK CL5UkBlob61B512d5ho0UVTTqClm8Nau3iIJN5qwm51aW53+PgE9EiGkq6NtwcLF5zrbc10Z wQ0N4ycvVHT+fDKjJte1KCgf7Nu78uFHuzraGpuWoL21zowagp8gZWbPRmgzCrm1Ep0zm+BO TN0sOgfnr8xCbi1GGxrIdD5q58ymDQ25rkThw/1k69HZs4nTKX027a516TXzSQ26x9mA3GZG TQ0tKZkuz/UihLhceK5XNqGfnDEuF73uy6SuLtf1yLy6OnrdlxHabEJ7m1m0YS6pnVGAz61m 8NzqHEFuM8/lol9aRMbGpPMXiCznujYWcTrp1VeRiopc12OaQm6zpaKCXn8dGR2Vej8ngUCu a5MGt5vOnUMq8S2fXEJus6uyklZWEr9f6h8Q77f8q6tpfR3xeHJdD0Buc8LjoQuuIQuuIYOD 0qVB4vfnukKGPB46s5bU1ua6HvAF5DanamtpbS2JRsnQkOQbsfAbRRYoK6PVVWTGDGLDmw55 B7nNAzYbmTmTzpxJCCHjE9LYGBkfz00j7PGQ8nJaUUHKy3KwdTANuc0z5WVUzYzfT6ampMkp EgiQQIBEoxZvy2Yjbjdxu2lpCSkpwYWrQJDbPObxEI+HqheWikKCQSLLRA5J4RAJR0g4TBSF KApRoiSqEEoIpYRQQiQiSUQixGYndhux24ndToqKSJGDFhUTZzFxOonLRez2nL48SB1yKw67 Xf25JprrukBu4ZYDgHiQWwDxILcA4kFuAcSD3AKI54r7yQsWLs5VPQDAgCRJP/3xC+qo9n0g /BorQL75YN9ezRT0kwHEg9wCiAe5BRAPcgsgHuQWQDzILYB4kFsA8STObWPTEjMrYsX4/02u zeT6rcVvtLFpSU7qAJAyy75/29XRluUFLdHYtCS3FQBIQdL9ZLVp0gwYN1maNi22cY6dG7sU P1FdSq8+cTeqWZuZmgPkoWz83oXapmlSZNzQ8UtpSmqmx12VZm7cwvx0AIEk3d6yY10dTeq4 50vGRlFt/dRZKVx5qouzFaa5NoD8lNe/L5VmS6hpYNGuQsFI5X0gtXuZbCfTuLnTW6HJRjK2 I5BCHQCEkI32Vk2UJlrml0pqW3EXT21tAPlJIoR0dbQtWLj4XGc7+z/XVUodbjJBQfpg396V Dz/60x+/sPLhR1kLVDifl0JoYfoonNwitDB9FE5uAaYP5BZAPMgtgHiQWwDxaN+/jf3FRwDI N1fkVpKkXNUDAMy7Ird4KwUgb/F9YVzfAogHuQUQD3ILIB7kFkA8eI4mgADwHE0AweA5mgCF ALkFEA9yCyAe5BZAPMgtgHiQWwDxILcA4jH1HE3+UVpxC6S8efwKOUAKTP3uOf+IHWu/64dv DgKkIMV+csInXBLuKZVxH2YZ93+DkgCgMtXeqskxeIBl3GGDh1nGbsJkSQAw1d52dbSxf8ZP lI67oMnp5ksCQIrP9UKcAHIorfeBUu7Eml8Q/WSAWKlc38Z9JiXfizbo9Jp8oGZqj94EmCYS 5zZuCDWJjVvSfBkzJQFAlY3nVvMStskplASYbrKdW/MhRFwB9ODzyQDiQW4BxIPcAogHuQUQ D56jCSAePEcTQDx4jiaAGPAcTQCxIbcA4kFuAcSD3AKIB8/RBBAAnqMJIBg8RxOgECC3AOJB bgHEg9wCiAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEg9wCiAe5BRAPcgsgHuQWQDzI LYB4kFsA8SC3AOJBbgHEg9wCiAe5BRAPcgsgHjxHE0A8eI4mgHjwHE0AMeA5mgBiQ24BxIPc AogHuQUQD56jCSAAPEcTQDB4jiZAIUBuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHgS57axaYnB aB5qbFqS/5UESEehtbeNTUu6Otq6OtoQXShgqeeWNWtqPAwGDMrzo7FJi7tO443iK8QwHWg/ 5xhX3ESpCeGHDcSWNxjQq4bJjZqsEoCgTOWWz4Be/5N1TY1zpVnWzGr1VmUAoYWCZyq3luAb 1di5SBqAeVbel1Kb3JRbvNgGOYXbSzgFQMFLsb3lE2UyJ+oisWnkZ8VdUG+jcYONfjIUvMS5 1WSAT5FeYb3YGCxrPvwpTAEoMHn9/i1aToC48jq3CC1AXHmdWwCIC7kFEA9yCyAe5BZAPHiO JoB48BxNAPHgOZoAYsBzNAHEhtwCiAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEg9wC iAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEc8XvXSxYuDhX9eBJkkQpzdq28CsfIBzt 78Kd62zPST1U6o9xZKEm+BE8EBT6yQDiQW4BxIPcAogHuQUQD3ILIJ4EuW1sWtLYtIQfTbjG 2DJmljKDVcaqtQGIS/s+UN7inz2P59DDNJe4n9zV0Ra3CU3Y9MUW4Kek03iy0PKr4gc0a+Yn prAtgDyUSntrpulTp/P5Uad0dbQl23jypw/j8rFrjh0AEJqp3LLMpHbE83mLbX6TXZW6IEu+ 3hlEs2ZkFQpMVq9v+fzENsjGzJ84kl0zgHDMvg8U9yrXjMzdXiZcR8A41QgwFJhU2lszl5pq mbgDsdMTtqVJXd8abxpAdAlyyx/oesN6ixgMGE83UxnNRIM1I7FQeCy+vjXZJKa8Wh6iCNOW xbnNUJbSWS3iDYUHn08GEA9yCyAebT85f366JX9qApBvrsitJEm5qodG/tQEIA9dkVvcwgEQ Aq5vAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHiQWwDJ/2rfAAACqElEQVTxILcA4kFuAcSD3AKI B7kFEA9yCyAe5BZAPMgtgHiQWwDxILcA4kFuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHiQWwDx ILcA4kFuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHi+eI4mnhMNIIrLucVzogEEcjm3eGI1gEBw fQsgHsnr9YbDYVmWFUUJh8OhUIgQ4vf7fT7f+Pj4/fffz+ZSSo3WcmU3OxwO86ORSIQfjUaj /KhmzZpVsfqYnKvZrqIoBhviybLMj9psV5zONBVOZ1RTB+O5Fo6anJVwrrHM7Qr+T5m5vWR+ Hyac63K5+NGSkhJ+1O12q8Mej6e7u7u1tfWRRx4xSOKdd97J5ra3t4+PjztCodDExMTw8DAr GgqFKKXBYLCzs7Orq2vFihWTk5M+n08TCePr4aRyq6HZHZpVaWhyq9mQcW75ami2kk5uc5XM 7OTWeK5mh2doR+XDPoytsGbU6XTyox6Phx/lc+t0Oj/55JMDBw489NBDBkm8/fbb2dyTJ092 dXU5QqHQ8PBwV1dXIBCIRCKhUEhRFFmWW1tbvV5vJBIZGho6c+ZMIBAwX2njv19Sc9MZNX9k 5OpQyM5o5raSk7NSfjawmrl8MmNH+RjbbLajR4+eOHHCOInq3FOnTnm9XseRI0eOHj3a09MT DAZZURbR3t7eycnJqampkZERv9+vadmylsyk9qwxTStqcChoZO6vm7m5Kbe3WSts4bKZWE+a ay4qKjI5GolEwuFwJBIxTqI698iRI5OTk46TJ0+eOHFiYmKCpVxRFL/fTwgJBALhcPiBBx7o 7+9n0TX/kiwMW3YOdOMKay4KjEc10plrlcydDtLZUcYXI5rTt91u11tQw3g9mvyY32ia2zVe FbtMM06iOtfv94fD4f8PcKaec5T2mGIAAAAASUVORK5CYII= --------------010503000008060104000107-- From morwen@evilmagic.org Fri Jun 27 09:32:54 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by mail.gnome.org (Postfix) with ESMTP id 28C28183AD for ; Fri, 27 Jun 2003 09:32:54 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030627133252.SDSC21249.mta01-svc.ntlworld.com@ganymede.arrow>; Fri, 27 Jun 2003 14:32:52 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganymede.arrow (8.11.2/8.11.2) with ESMTP id h5RDWb302018; Fri, 27 Jun 2003 14:32:37 +0100 Subject: Re: Unexpected font rendering with pango From: Abigail Brady To: stephan.hegel@gmx.de Cc: gtk-i18n-list@gnome.org In-Reply-To: <3EFC3811.2090705@gmx.de> References: <3EFC3811.2090705@gmx.de> Content-Type: text/plain Organization: Message-Id: <1056720756.1971.3.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 27 Jun 2003 14:32:37 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 13:26, Stephan Hegel wrote: > Recently I have found an unusual behaviour in Chinese font rendering > with Pango.Please have a look at the attached, little screenshots. The > only difference between both is the setting of the locale before starting > the application. The first one uses LC_ALL=en_US and the second one > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing > antialiasing - fine on the second pix, but not o.k. in the first > case. It somehow uses a different size of fonts in just one string ... > > Anyone out there who has an idea or a hint how to track this and/or to > fix this ? It's doing this because of the preference order of the fonts. With en_US its picking up a japanese or korean font first, and using that to display any characters it has support for - and only then moving to the chinese font. When in the chinese locale, it knows to use chinese fonts first... So you'll need to fiddle with the config files. -- Abi From pablo@mandrakesoft.com Fri Jun 27 11:45:11 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chanae.alphanet.ch (212-100-178-141.adsl.easynet.be [212.100.178.141]) by mail.gnome.org (Postfix) with ESMTP id 0033418587 for ; Fri, 27 Jun 2003 11:45:10 -0400 (EDT) Received: (from srtxg@localhost) by chanae.alphanet.ch (8.9.0/8.9.0) id RAA19301 for gtk-i18n-list@gnome.org; Fri, 27 Jun 2003 17:52:27 +0200 Date: Fri, 27 Jun 2003 17:52:27 +0200 From: Pablo Saratxaga To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango Message-ID: <20030627155227.GA19166@chanae.alphanet.ch> Mail-Followup-To: Pablo Saratxaga , gtk-i18n-list@gnome.org References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <1056720756.1971.3.camel@ganymede.arrow> User-Agent: Mutt/1.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kaixo! On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote: > > Recently I have found an unusual behaviour in Chinese font rendering > > with Pango.Please have a look at the attached, little screenshots. The > > only difference between both is the setting of the locale before starti= ng > > the application. The first one uses LC_ALL=3Den_US and the second one > > LC_ALL=3Dzh_CN.GB2312. The font rendering is - despite the missing > > antialiasing - fine on the second pix, but not o.k. in the first > > case. It somehow uses a different size of fonts in just one string ... > >=20 > > Anyone out there who has an idea or a hint how to track this and/or to > > fix this ? >=20 > It's doing this because of the preference order of the fonts. With > en_US its picking up a japanese or korean font first, and using that to > display any characters it has support for - and only then moving to the > chinese font. When in the chinese locale, it knows to use chinese fonts > first... So you'll need to fiddle with the config files. The problem is that it is using a *non scalable* font at a *wrong size*. Imho pango (well, Xft actually I think) should first look at scalable fonts, and only if no scalable fonts are found ressort to non scalable ones, if that is already doable trough a config option, then I would be interested to know what option it is, in order to enable that by default. It is simply too bad that a single text get in mixed sizes, just because the first matching font is used, without checking it has the character=20 at the right size. Such an output is acceptable if the only other alternative would be to display an empty square, but that is not the case here. Even worst: the first character of the paragraphe is a traditional chinese one, and taken from a traditional chinese font; imho in such case=20 pango should continue with the same font as long as possible, instead of switching to the default one for the next (for every?) character (that behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it makes sense to stick when the same font as long as possible; that is, if a given character was not on the default font, nor in the first CJK font ('ja' or 'ko' covering one in this case), and was on another CJK font, then it should stick with that one, as it is likely that other characters w= ill be in the same case. Following that ordering will give a much better output in all cases of normal CJK text. But if that is too complex to do, pango must at least give priority to scalable fonts, having a word with some letters near 3 or 4 times the size of some others is horrendous. --=20 Ki =E7a vos v=E5ye b=E9n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portugue= se] --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/GhQpSX1mtm4VGYRAn2cAJ9pNE4F7/8K768x4noZ3dem7uyISQCaA8L/ DmDwmnCOlRzB/aZ2XfJNljA= =Fddk -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From otaylor@redhat.com Fri Jun 27 15:16:57 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 03D6618389 for ; Fri, 27 Jun 2003 15:16:57 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5RJGqK30609; Fri, 27 Jun 2003 15:16:52 -0400 Subject: Re: Unexpected font rendering with pango From: Owen Taylor To: Pablo Saratxaga Cc: gtk-i18n-list@gnome.org In-Reply-To: <20030627155227.GA19166@chanae.alphanet.ch> References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> <20030627155227.GA19166@chanae.alphanet.ch> Content-Type: text/plain Message-Id: <1056741412.6045.10.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 27 Jun 2003 15:16:52 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 11:52, Pablo Saratxaga wrote: > Kaixo! > > On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote: > > > > Recently I have found an unusual behaviour in Chinese font rendering > > > with Pango.Please have a look at the attached, little screenshots. The > > > only difference between both is the setting of the locale before starting > > > the application. The first one uses LC_ALL=en_US and the second one > > > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing > > > antialiasing - fine on the second pix, but not o.k. in the first > > > case. It somehow uses a different size of fonts in just one string ... > > > > > > Anyone out there who has an idea or a hint how to track this and/or to > > > fix this ? > > > > It's doing this because of the preference order of the fonts. With > > en_US its picking up a japanese or korean font first, and using that to > > display any characters it has support for - and only then moving to the > > chinese font. When in the chinese locale, it knows to use chinese fonts > > first... So you'll need to fiddle with the config files. > > The problem is that it is using a *non scalable* font at a *wrong size*. > Imho pango (well, Xft actually I think) should first look at scalable fonts, > and only if no scalable fonts are found ressort to non scalable ones, > if that is already doable trough a config option, then I would be interested > to know what option it is, in order to enable that by default. I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd have to have a very exotic configuration (basically, no scalable CJK fonts) to get those results with fontconfig/Xft. > It is simply too bad that a single text get in mixed sizes, just because > the first matching font is used, without checking it has the character > at the right size. Such an output is acceptable if the only other > alternative would be to display an empty square, but that is not the case > here. > > Even worst: the first character of the paragraphe is a traditional chinese > one, and taken from a traditional chinese font; imho in such case > pango should continue with the same font as long as possible, instead of > switching to the default one for the next (for every?) character (that > behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it > makes sense to stick when the same font as long as possible; that is, > if a given character was not on the default font, nor in the first CJK > font ('ja' or 'ko' covering one in this case), and was on another CJK font, > then it should stick with that one, as it is likely that other characters will > be in the same case. Following that ordering will give a much better > output in all cases of normal CJK text. Unfortunately, you can't autodetect traditional vs. modern Chinese, so I don't think we'll ever be able to do much better than supplied language tag for that situation... if you have a section of text that has only shared characters, it's going to get one or the other font arbitrarily. For other languages, there is possibility of improvement - see http://bugzilla.gnome.org/show_bug.cgi?id=112503. For Stephan, there is a easy solution ... since the app knows the language of the text it is displaying, it can explicitely set the language tag, and override the language tag of the locale. Regards, Owen From pablo@mandrakesoft.com Fri Jun 27 16:26:23 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chanae.alphanet.ch (212-100-178-141.adsl.easynet.be [212.100.178.141]) by mail.gnome.org (Postfix) with ESMTP id 4DE3118FA5 for ; Fri, 27 Jun 2003 16:26:22 -0400 (EDT) Received: (from srtxg@localhost) by chanae.alphanet.ch (8.9.0/8.9.0) id WAA25904 for gtk-i18n-list@gnome.org; Fri, 27 Jun 2003 22:33:40 +0200 Date: Fri, 27 Jun 2003 22:33:40 +0200 From: Pablo Saratxaga To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango Message-ID: <20030627203340.GB24947@chanae.alphanet.ch> Mail-Followup-To: Pablo Saratxaga , gtk-i18n-list@gnome.org References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> <20030627155227.GA19166@chanae.alphanet.ch> <1056741412.6045.10.camel@poincare.devel.redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline In-Reply-To: <1056741412.6045.10.camel@poincare.devel.redhat.com> User-Agent: Mutt/1.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kaixo! On Fri, Jun 27, 2003 at 03:16:31PM -0400, Owen Taylor wrote: > I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd probably. > > one, and taken from a traditional chinese font; imho in such case=20 > > pango should continue with the same font as long as possible, instead of > > switching to the default one for the next (for every?) character (that > Unfortunately, you can't autodetect traditional vs. modern Chinese, so I idn't mean that. I meant, if a char "X" is searched in first font, and not found there then found in the second font; then, when displaying the second char "Y", first look at the last used font (the second) instead of looking again at the first, then second. If the search was done like that for CJK (only for CJK, as for latin, greek, and cyrillic it won't be desirable) then a text will be properly displayed in most cases; at worst only the few chars at the begining of the text will be in a different style; not a mixed style in all the document. In the particular case shown in the examples, it would have given a correct display, that is the same display that in the chinese locale.=20 Is such behaviour doable ? It would be a big improvement imho. --=20 Ki =E7a vos v=E5ye b=E9n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portugue= se] --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/Ko5pSX1mtm4VGYRAmidAJ0bHr8/eIYufQ5aPFZtdDws0y1UMgCfai21 3/EbR70DpOnbrXuDYMi+JNo= =8BqY -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From keithp@keithp.com Fri Jun 27 17:21:51 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from localhost (unknown [63.227.221.253]) by mail.gnome.org (Postfix) with ESMTP id 11A0318FDA for ; Fri, 27 Jun 2003 17:21:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=keithp.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19W0ex-0001aT-00; Fri, 27 Jun 2003 14:21:31 -0700 X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev To: Pablo Saratxaga Cc: gtk-i18n-list@gnome.org, Keith Packard Subject: Re: Unexpected font rendering with pango From: Keith Packard In-reply-to: Your message of "Fri, 27 Jun 2003 22:33:40 +0200." <20030627203340.GB24947@chanae.alphanet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 14:21:29 -0700 Message-Id: Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Around 22 o'clock on Jun 27, Pablo Saratxaga wrote: > I meant, if a char "X" is searched in first font, and not found there > then found in the second font; then, when displaying the second char "Y", > first look at the last used font (the second) instead of looking again > at the first, then second. And if the characters are in the opposite order, you'll still get 'ransom note' typography. A particular counter example is a document which is largely in English but which happens to start with a Japanese glyph. With a 'sticky font' mechanism, the whole document will be rendered with a Japanese font. The current mechanism is also designed to be 'stable' so that the glyphs selected for any particular character don't change as the document is edited; this makes layout significantly easier. The correct solution is to inform the font system what languages are in use so that appropriate fonts can be selected. -keith From keithp@keithp.com Fri Jun 27 18:03:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from localhost (unknown [63.227.221.253]) by mail.gnome.org (Postfix) with ESMTP id 0D5F318FDB for ; Fri, 27 Jun 2003 18:03:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=keithp.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19W1Iu-0001bw-00; Fri, 27 Jun 2003 15:02:48 -0700 X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev To: Eric Mader Cc: Keith Packard , Pablo Saratxaga , gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango From: Keith Packard In-reply-to: Your message of "Fri, 27 Jun 2003 14:37:26 PDT." <3EFCB916.1050702@bigfoot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 15:02:48 -0700 Message-Id: Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Around 14 o'clock on Jun 27, Eric Mader wrote: > It might also make sense to take the language into account too; possibly > with a notion of what characters are used to write a given language in a > given script. I haven't thought about that enough to say for sure. That's precisely what fontconfig does. It calculates language coverage based on Unicode coverage of language orthography. It's a relatively straightforward technique aside from the collection of language orthographies; fontconfig is still missing orthographies for 17 of the 139 languages in ISO 639-1. > Another point: for complex text like Arabic and Hindi, you really, > really want to try and keep it all in the same font, because that's the > only way to get the correct contextual behavior. Arabic is not horribly problematic as most fonts provide coverage for most languages. One issue for Arabic is that newer fonts are less likely to include the presentation forms and are starting to expect shapers to perform compositing. That may require some additional information for font matching. I've seen significantly more trouble with languages presented in Latin or Cyrillic scripts where the lack of a language tag often results in uncommon glyphs being presented in an unexpected font. If an application wants to ensure that a complete document is presented in a single font, it can pass the set of Unicode values from the document to the font selection mechanism and request a single font covering those values. Language tags simply provide a convenient shorthand for this mechanism. -keith From stephan.hegel@gmx.de Sat Jun 28 20:24:45 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id DF74418926 for ; Sat, 28 Jun 2003 20:24:44 -0400 (EDT) Received: (qmail 18026 invoked by uid 65534); 29 Jun 2003 00:24:42 -0000 Received: from unknown (EHLO gmx.de) (61.155.124.129) by mail.gmx.net (mp027) with SMTP; 29 Jun 2003 02:24:42 +0200 Message-ID: <3EFE316D.9080609@gmx.de> Date: Sun, 29 Jun 2003 08:23:09 +0800 From: Stephan Hegel Reply-To: stephan.hegel@gmx.de Organization: Private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en, de, zh-CN MIME-Version: 1.0 To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango References: <20030628160014.14571.48469.Mailman@moniker.gnome.org> In-Reply-To: <20030628160014.14571.48469.Mailman@moniker.gnome.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi all, Thanks for the quick replies. Here just a few more notes on the issue. 1. The mentioned application lingoteach is not my work, I have just downloaded it from freshmeat since I'm looking for a vocabulary trainer what is able to display Simplified Chinese chars. However, I will have deeper look into it to figure out how it is done, but it looks like the apps uses only gtk_set_label calls. 2. A language tag as proposed by Owen is certainly a good solution to display a consistent, nice looking layout. However the mentioned application allows to add new languages and one doesn't know in advance what the user want to add. 3. I do use fontconfig/Xft. At least pango is telling me that when I configure it. checking for fontconfig >= 1.0.1... yes checking FONTCONFIG_CFLAGS... -I/usr/local/include checking FONTCONFIG_LIBS... -L/usr/local/lib -lfontconfig checking for freetype-config... /usr/bin/freetype-config checking for FT_Get_Next_Char in -lfreetype... yes checking for xft >= 2.0.0... yes checking XFT_CFLAGS... -I/usr/local/include -I/usr/include/freetype2 -I/usr/X11R6/include checking XFT_LIBS... -L/usr/local/lib -L/usr/X11R6/lib -lXft -lfreetype -lz -lXrender -lfontconfig ... configuration: backends: FreeType X Xft The shared libraries are all available, finally: libpango, libpangoft2, libpangox, and libpangoxft. 4. Beside Arial Unicode MS, there are other TTF Simplified Chinese fonts available on the system like MsSong, MsHei, SimHei, etc. xlsfonts and fc-list reports them all. I would like to find out what font is really selected by what backend in this application. Is there a simple log/trace/track mechanism available in Pango (kind of environment variable or whatever) which can be easily activated ? Thanks & regards, Stephan. From morwen@evilmagic.org Sun Jun 29 05:39:25 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by mail.gnome.org (Postfix) with ESMTP id 7119018655 for ; Sun, 29 Jun 2003 05:39:25 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030629093925.XPQR18592.mta07-svc.ntlworld.com@ganymede.arrow> for ; Sun, 29 Jun 2003 10:39:25 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganymede.arrow (8.11.2/8.11.2) with ESMTP id h5T9d4f01372 for ; Sun, 29 Jun 2003 10:39:05 +0100 Subject: Re: Unexpected font rendering with pango From: Abigail Brady To: gtk-i18n-list@gnome.org In-Reply-To: <3EFE316D.9080609@gmx.de> References: <20030628160014.14571.48469.Mailman@moniker.gnome.org> <3EFE316D.9080609@gmx.de> Content-Type: text/plain Organization: Message-Id: <1056879544.1119.2.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Jun 2003 10:39:04 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Sun, 2003-06-29 at 01:23, Stephan Hegel wrote: > 3. I do use fontconfig/Xft. At least pango is telling me that when > I configure it. > > checking for fontconfig >= 1.0.1... yes > checking FONTCONFIG_CFLAGS... -I/usr/local/include > checking FONTCONFIG_LIBS... -L/usr/local/lib -lfontconfig > checking for freetype-config... /usr/bin/freetype-config > checking for FT_Get_Next_Char in -lfreetype... yes > checking for xft >= 2.0.0... yes > checking XFT_CFLAGS... -I/usr/local/include -I/usr/include/freetype2 > -I/usr/X11R6/include > checking XFT_LIBS... -L/usr/local/lib -L/usr/X11R6/lib -lXft -lfreetype > -lz -lXrender -lfontconfig > ... > configuration: > backends: FreeType X Xft > > The shared libraries are all available, finally: > libpango, libpangoft2, libpangox, and libpangoxft. All this is telling you is that Xft was built, not that you are using it. Have you set GDK_USE_XFT? -- Abi From emader@bigfoot.com Fri Jun 27 17:37:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mail.gnome.org (Postfix) with ESMTP id AECFD1810B for ; Fri, 27 Jun 2003 17:37:29 -0400 (EDT) Received: (qmail 31091 invoked from network); 27 Jun 2003 21:37:28 -0000 Received: from unknown (HELO bigfoot.com) (emader@[66.93.135.240]) (envelope-sender ) by mail9.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Jun 2003 21:37:28 -0000 Message-ID: <3EFCB916.1050702@bigfoot.com> Date: Fri, 27 Jun 2003 14:37:26 -0700 From: Eric Mader User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Packard Cc: Pablo Saratxaga , gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: You can make the font 'sticky' only for that script. In general, it seems to be a good idea to try and display all characters in a given script in the same font. It might also make sense to take the language into account too; possibly with a notion of what characters are used to write a given language in a given script. I haven't thought about that enough to say for sure.. Another point: for complex text like Arabic and Hindi, you really, really want to try and keep it all in the same font, because that's the only way to get the correct contextual behavior. Regards, Eric Mader IBM GCoC - San José 5600 Cottle Rd. M/S 50-2/B11 San Jose, CA 95193 Keith Packard wrote: > Around 22 o'clock on Jun 27, Pablo Saratxaga wrote: > > >>I meant, if a char "X" is searched in first font, and not found there >>then found in the second font; then, when displaying the second char "Y", >>first look at the last used font (the second) instead of looking again >>at the first, then second. > > > And if the characters are in the opposite order, you'll still get 'ransom > note' typography. > > A particular counter example is a document which is largely in English but > which happens to start with a Japanese glyph. With a 'sticky font' > mechanism, the whole document will be rendered with a Japanese font. > > The current mechanism is also designed to be 'stable' so that the glyphs > selected for any particular character don't change as the document is > edited; this makes layout significantly easier. > > The correct solution is to inform the font system what languages are in use > so that appropriate fonts can be selected. > > -keith > > > _______________________________________________ > gtk-i18n-list mailing list > gtk-i18n-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-i18n-list > > From otaylor@redhat.com Sun Jun 29 11:55:41 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DFF921835F for ; Sun, 29 Jun 2003 11:55:40 -0400 (EDT) Received: from vpn50-32.rdu.redhat.com (vpn50-32.rdu.redhat.com [172.16.50.32]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5TFtaK03645; Sun, 29 Jun 2003 11:55:36 -0400 Subject: Re: Unexpected font rendering with pango From: Owen Taylor To: Eric Mader Cc: Keith Packard , Pablo Saratxaga , gtk-i18n-list@gnome.org, morwen@evilmagic.org In-Reply-To: <3EFCB916.1050702@bigfoot.com> References: <3EFCB916.1050702@bigfoot.com> Content-Type: text/plain Organization: Message-Id: <1056902111.15837.55.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 29 Jun 2003 11:55:12 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 17:37, Eric Mader wrote: > You can make the font 'sticky' only for that script. In general, it > seems to be a good idea to try and display all characters in a given > script in the same font. It might also make sense to take the language > into account too; possibly with a notion of what characters are used to > write a given language in a given script. I haven't thought about that > enough to say for sure.. This is basically what http://bugzilla.gnome.org/show_bug.cgi?id=112503 is about. Once we have script run information for shaper selection, we need to push it into the font selection algorithm in some fashion, for one thing, because shapers are only fed runs of glyphs in the same font. (The other thing that needs dealing with is dealing omitting non-rendering characters such as ZWJ from font selection to avoid having them break runs... fonts shouldn't have to claim to cover these languages) The language is already taken into consideration by fontconfig - it orders fonts returned by how well they match the language tag, and I think that will automatically carry over into any future script-run based system ... as long as we select fonts in the order that fontconfig returns them, we'll get the best font for the current language. I used to worry about font selection algorithms where subsequent characters could affect previous characters, figuring that would seem confusing while editing, but I've stopped worrying about that. For one, thing, it only matters if the font you have selected doesn't itself include all the characters in the language you are typing. It certainly doesn't make layout harder in any fundamental way since Pango never lays out less than a paragraph at a time. There *is* some question in my mind whether script-range font selection should apply to anything other than COMMON/INHERITED characters. - Pro: it's the only way that ransom-note effects will be reduced for wrong-tagged text for CJK or Roman where fonts commonly don't cover the entire script range. - Con: it can actually make things worse because it means that a single foreign name might throw an entire paragraph of text into a different font. In fact, I think the Con: here wins ... yes, script-run consideration for font selection is important, but no it shouldn't be used to fix problems like the one that started this thread. Regards, Owen [ Abi - since you asked for suggestions of things to work on, I think 91542/112503 is the most serious problem that Pango has at the moment. Assignment of ZWJ/ZWNJ to the wrong shaper has serious consequences for the correct rendering of Farsi and Indic languages. And, I think it's also likely fairly *interesting* to work on, which is definitely an added bonus ] From otaylor@redhat.com Sun Jun 29 12:24:22 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D5F71183EA; Sun, 29 Jun 2003 12:24:21 -0400 (EDT) Received: from vpn50-32.rdu.redhat.com (vpn50-32.rdu.redhat.com [172.16.50.32]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5TGOLK05478; Sun, 29 Jun 2003 12:24:21 -0400 Subject: [admin] List rules and FAQs added to www.gtk.org From: Owen Taylor Reply-To: gtk-list@gnome.org To: gtk-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-doc-list@gnome.org, gtk-i18n-list@gnome.org, gtk-devel-list@gnome.org Content-Type: text/plain Organization: Message-Id: <1056903836.15837.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 29 Jun 2003 12:23:56 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: I just added a short "List Rules and FAQs" section to http://www.gtk.org/mailinglists.html. Nothing there should be that surprising to current list members, but it wouldn't hurt to take a quick look. If you have any comments or suggestions for additional material which would be useful there, please let me know. Regards, Owen From jshin@mailaps.org Sun Jun 29 13:08:08 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from atlas.jtan.com (atlas.jtan.com [207.106.84.159]) by mail.gnome.org (Postfix) with ESMTP id 8926318A29 for ; Sun, 29 Jun 2003 13:08:07 -0400 (EDT) Received: from callisto.jtan.com (root@callisto.jtan.com [207.106.84.134]) by atlas.jtan.com (8.12.8p1/8.12.8) with ESMTP id h5TH86uN000310 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 29 Jun 2003 13:08:07 -0400 (EDT) Received: from callisto.jtan.com (jshin@localhost [127.0.0.1]) by callisto.jtan.com (8.12.1/8.12.1) with ESMTP id h5TH84OW013528 for ; Sun, 29 Jun 2003 13:08:04 -0400 (EDT) Received: from localhost (jshin@localhost) by callisto.jtan.com (8.12.1/8.12.1/Submit) with ESMTP id h5TH834w013202 for ; Sun, 29 Jun 2003 13:08:04 -0400 (EDT) X-Authentication-Warning: callisto.jtan.com: jshin owned process doing -bs Date: Sun, 29 Jun 2003 13:08:03 -0400 (EDT) From: Jungshik Shin X-X-Sender: To: Subject: Re: Unexpected font rendering with pango In-Reply-To: <1056902111.15837.55.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On 29 Jun 2003, Owen Taylor wrote: > (The other thing that needs dealing with is dealing omitting > non-rendering characters such as ZWJ from font selection to > avoid having them break runs... fonts shouldn't have to claim to > cover these languages) You meant 'claim to cover these characters', didn't you? If that's what you meant, it may not be so clear-cut for some 'invisible' characters. For characters like 'invisible times' (sorry I forgot the code point, it's somewhere in U+206x? or can be easily found in 'Default_Ignorable' list at Unicode ftp site) and 'invisible apply a function to'(?), there's no question that they should be ignored. [1] It gets a bit murky for ZWJ and ZWNJ (or CGJ).Some opentype fonts have to claim to cover characters like ZWJ and ZWNJ because ZWJ and ZWNJ take part in glyph substitutions (via GSBU look-up) and their presence and absence affect the rendering result. [1] Some aggressive fonts have visible glyphs for truly invisible characters. In presence of those fonts, not taking 'truly invisible' characters into account in font selection is essential to prevent the visible glyph of 'invisible times' from one of those fonts from popping up in the middle of a text-run rendered with another font. Jungshik From vivek@lantana.tenet.res.in Tue Jun 3 01:40:39 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 8939618A4D for ; Tue, 3 Jun 2003 01:40:34 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h535df530262 for ; Tue, 3 Jun 2003 11:09:44 +0530 Subject: utf-8 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-huysmgQWAktM7Ldxz9Kk" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jun 2003 11:10:40 +0530 Message-Id: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-huysmgQWAktM7Ldxz9Kk Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi In Pango, the strings are stroed in the UTF-8 standard. But, while i read the characters as integer, it gives some negative values. For example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the case for all the characters. How can I get the exact UTF-8 value ? I get the above values in Pango-context.c and shape.c with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-huysmgQWAktM7Ldxz9Kk Content-Type: text/html; charset=utf-8 Hi
  In Pango, the strings are stroed in the UTF-8 standard.  But, while i read the characters as integer, it gives some negative values. For example,  -32 -92 -107 is stored there for Devanagari 'ka'. This is the case for all the characters. How can I get the exact UTF-8 value ?  

I get the above values in Pango-context.c and shape.c

with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-huysmgQWAktM7Ldxz9Kk-- From nlevitt@computer.cc.columbia.edu Tue Jun 3 01:48:16 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id 90CD518135 for ; Tue, 3 Jun 2003 01:48:16 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19N4eS-0005OJ-00; Tue, 03 Jun 2003 01:48:04 -0400 Date: Tue, 3 Jun 2003 01:48:04 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: utf-8 Message-ID: <20030603054804.GI20359@columbia.edu> References: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Use g_utf8_get_char_validated or g_utf8_get_char to get the unicode character. You are looking at the byte values, which are not generally useful. If you are sure you want the UTF-8 bytes, you might want to cast to guchar if you want the unsigned values. gtk-list or gtk-app-devel-list would be better for this type of question. Noah On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while i > read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the > case for all the characters. How can I get the exact UTF-8 value ? > > I get the above values in Pango-context.c and shape.c > > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda From vivek@lantana.tenet.res.in Tue Jun 3 02:18:40 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 76639183C4 for ; Tue, 3 Jun 2003 02:18:35 -0400 (EDT) Received: from lantana.iitm.ernet.in (lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h536J4C23735 for ; Tue, 3 Jun 2003 11:49:04 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h536Hl531438 for ; Tue, 3 Jun 2003 11:47:47 +0530 Subject: Re: utf-8 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-D2E9hJukNaaTHzX9XosU" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Jun 2003 11:48:47 +0530 Message-Id: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-D2E9hJukNaaTHzX9XosU Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Naoh. I have one more doubt. If we give 8bit value in the input (gtk), whether it is converted to UTF-8, before it gets stored ? Can we store the 8-bit value as it is (instead of converting to UTF-8) in GTK applications ? with regards vivek On Tue, 2003-06-03 at 11:18, Noah Levitt wrote: Use g_utf8_get_char_validated or g_utf8_get_char to get the unicode character. You are looking at the byte values, which are not generally useful. If you are sure you want the UTF-8 bytes, you might want to cast to guchar if you want the unsigned values. gtk-list or gtk-app-devel-list would be better for this type of question. Noah On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while i > read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is the > case for all the characters. How can I get the exact UTF-8 value ? > > I get the above values in Pango-context.c and shape.c > > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-D2E9hJukNaaTHzX9XosU Content-Type: text/html; charset=utf-8 Thanks Naoh.
   I have one more doubt.  If we give 8bit value in the input (gtk), whether it is converted to UTF-8, before it gets stored ? Can we store the 8-bit value as it is (instead of converting to UTF-8) in GTK applications ?

with regards
vivek

On Tue, 2003-06-03 at 11:18, Noah Levitt wrote: 
Use g_utf8_get_char_validated or g_utf8_get_char to get the
unicode character. You are looking at the byte values, which
are not generally useful.

If you are sure you want the UTF-8 bytes, you might want to
cast to guchar if you want the unsigned values.

gtk-list or gtk-app-devel-list would be better for this type
of question.

Noah

On Tue, Jun 03, 2003 at 11:10:40 +0530, Viveka Nathan K wrote:
> Hi
>   In Pango, the strings are stroed in the UTF-8 standard.  But, while i
> read the characters as integer, it gives some negative values. For
> example,  -32 -92 -107 is stored there for Devanagari 'ka'. This is the
> case for all the characters. How can I get the exact UTF-8 value ?   
> 
> I get the above values in Pango-context.c and shape.c
> 
> with regards
> vivek
> -- 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
> Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> All condemnation of others really condemns ourselves - Swami Vivekananda
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda

--=-D2E9hJukNaaTHzX9XosU-- From nlevitt@computer.cc.columbia.edu Tue Jun 3 02:52:52 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id C4FF318110 for ; Tue, 3 Jun 2003 02:52:52 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19N5XT-0006CR-00; Tue, 03 Jun 2003 02:44:55 -0400 Date: Tue, 3 Jun 2003 02:44:55 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: utf-8 Message-ID: <20030603064455.GA23823@columbia.edu> References: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054621127.7158.0.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: I don't understand the question at all. (8bit value? input? converted? stored? What do you mean by these?) Noah On Tue, Jun 03, 2003 at 11:48:47 +0530, Viveka Nathan K wrote: > Thanks Naoh. > I have one more doubt. If we give 8bit value in the input (gtk), > whether it is converted to UTF-8, before it gets stored ? Can we store > the 8-bit value as it is (instead of converting to UTF-8) in GTK > applications ? > > with regards > vivek > From morwen@evilmagic.org Tue Jun 3 12:14:12 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail1-gui.server.ntli.net (mail1-gui.server.ntli.net [194.168.222.13]) by mail.gnome.org (Postfix) with ESMTP id 2CA1818285 for ; Tue, 3 Jun 2003 12:14:12 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mail1-gui.server.ntli.net (Post.Office MTA v3.1 release PO203a ID# 0-33929U70000L2S50) with ESMTP id AAA12970; Tue, 3 Jun 2003 17:14:00 +0100 Subject: Re: utf-8 From: Abigail Brady To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org In-Reply-To: <1054618844.955.31.camel@dodo.lli.tenet.res.in> References: <1054618844.955.31.camel@dodo.lli.tenet.res.in> Content-Type: text/plain Organization: Message-Id: <1054656653.17407.4.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 17:10:53 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Tue, 2003-06-03 at 06:40, Viveka Nathan K wrote: > Hi > In Pango, the strings are stroed in the UTF-8 standard. But, while > i read the characters as integer, it gives some negative values. For > example, -32 -92 -107 is stored there for Devanagari 'ka'. This is > the case for all the characters. How can I get the exact UTF-8 value > ? I don't see why this is a surprise at all to you - that IS the correct UTF-8 encoding for KA. (E0, A4, 95, treated as 8-bit twos complement is -32 -92 -107). Perhaps you misunderstand UTF-8 or C. What are you expecting to see? -- Abi From vantr@touchtunes.com Tue Jun 3 10:39:54 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.touchtunes.com (operator.touchtunes.com [207.96.182.163]) by mail.gnome.org (Postfix) with ESMTP id 7C8E7184F5; Tue, 3 Jun 2003 10:39:54 -0400 (EDT) Received: from touchtunes.com (vantr.touchtunes.com [192.168.0.138]) by mail.touchtunes.com (Postfix) with ESMTP id 59921159E4; Tue, 3 Jun 2003 10:11:04 -0400 (EDT) Message-ID: <3EDCA50F.7030008@touchtunes.com> Date: Tue, 03 Jun 2003 09:39:27 -0400 From: Tristan Van Berkom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "B. Souliotis" Cc: gtk-devel-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org, gtk-list-request@gnome.org Subject: Re: Making Signal For A Widget. References: <3EDC8E7E.4010901@beta-cae.gr> In-Reply-To: <3EDC8E7E.4010901@beta-cae.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: You might do well to note also that gtkwidget.c is like a HUB for all theese events. As input, you get your GdkEvents and as output, you have a bunch of basic signals that are "emmited" at the GtkWidget level and handlers are "implemented" by various subclasses. you should probably read this: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Event-Structures.html#GdkEventButton when a "clicked" signal is emitted (by the GtkButtonClass); the mouse button has already been "released". now wether you mean the "Left button", the "button down" or "button press" by "First" is an entirely different question. Hope this helps, -Tristan From vivek@lantana.tenet.res.in Thu Jun 5 01:52:53 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id AEBEE18237 for ; Thu, 5 Jun 2003 01:52:44 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h555pP531885 for ; Thu, 5 Jun 2003 11:21:30 +0530 Subject: compiling gtk program From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-rozlI9E79IeeDf+2jH1O" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Jun 2003 11:22:49 +0530 Message-Id: <1054792374.916.23.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-rozlI9E79IeeDf+2jH1O Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi.. I took the sample program given in GTK documentation (helloworld.c) and I compiled it. It gives the error as : : /usr/include/gtk-1.2/glib/gtypes.h:41: syntax error before "typedef" : : /usr/include/gtk-1.2/glib/garray.h:32: parse error before "G_BEGIN_DECLS" /usr/include/gtk-1.2/glib/garray.h:34: syntax error before "typedef" : : what is that 'G_BEGIN_DECLS' I went through that gtypes.h.. there it is like as follows. What should I do to compile the program ? : : #include G_BEGIN_DECLS /* Provide type definitions for commonly used types. typedef char gchar; typedef short gshort; : : -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-rozlI9E79IeeDf+2jH1O Content-Type: text/html; charset=utf-8 Hi..
  I took the sample program given in GTK documentation (helloworld.c) and I compiled it.
It gives the error as

:
:
/usr/include/gtk-1.2/glib/gtypes.h:41: syntax error before "typedef"
:
:
/usr/include/gtk-1.2/glib/garray.h:32: parse error before "G_BEGIN_DECLS"
/usr/include/gtk-1.2/glib/garray.h:34: syntax error before "typedef"
:
:

what is that 'G_BEGIN_DECLS'

I went through that gtypes.h.. there it is like as follows.  What should I do to compile the program ?

:
:
#include <glibconfig.h>

G_BEGIN_DECLS

/* Provide type definitions for commonly used types.
typedef char   gchar;
typedef short  gshort;
:
: 

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-rozlI9E79IeeDf+2jH1O-- From vivek@lantana.tenet.res.in Thu Jun 5 07:17:43 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 069B818130 for ; Thu, 5 Jun 2003 07:17:39 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h55BGS511062 for ; Thu, 5 Jun 2003 16:46:31 +0530 Subject: pango ? From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-KgCMtsNS3UFlBsYuXcN4" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Jun 2003 16:47:56 +0530 Message-Id: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-KgCMtsNS3UFlBsYuXcN4 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi.. I am going to create one application in GTK with pango. In the normal program, if it contains the English string in the following label, button = gtk_button_new_with_label ("Hai!"); It displayed correctly. If i replace the string with 'UTF-8' characters, it didn't display anything. What should I add to display the UTF-8 characters using pango? Thanking you with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-KgCMtsNS3UFlBsYuXcN4 Content-Type: text/html; charset=utf-8 Hi..
 
  I am going to create one application in GTK with pango. In the normal program, if it contains
the English string in the following label,
  button = gtk_button_new_with_label ("Hai!");
  It displayed correctly.

If i replace the string with 'UTF-8' characters, it didn't display anything.
What should I add to display the UTF-8 characters using pango?

Thanking you
with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-KgCMtsNS3UFlBsYuXcN4-- From nlevitt@computer.cc.columbia.edu Thu Jun 5 11:28:12 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from computer.cc.columbia.edu (computer.cc.columbia.edu [128.59.31.237]) by mail.gnome.org (Postfix) with ESMTP id 0476E18216 for ; Thu, 5 Jun 2003 11:28:12 -0400 (EDT) Received: from nlevitt by computer.cc.columbia.edu with local (Exim 3.36 #1) id 19Nwel-0006kJ-00; Thu, 05 Jun 2003 11:27:59 -0400 Date: Thu, 5 Jun 2003 11:27:59 -0400 From: Noah Levitt To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: pango ? Message-ID: <20030605152759.GA25898@columbia.edu> References: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054811878.916.45.camel@dodo.lli.tenet.res.in> Secret-NSA-Message-ID: 3b026257dfe9ed894171dbbb76f5b2ba User-Agent: Mutt/1.5.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Either it wasn't valid UTF-8 or you don't have fonts with the characters you were trying to draw. Noah On Thu, Jun 05, 2003 at 16:47:56 +0530, Viveka Nathan K wrote: > Hi.. > > I am going to create one application in GTK with pango. In the normal > program, if it contains > the English string in the following label, > button = gtk_button_new_with_label ("Hai!"); > It displayed correctly. > > If i replace the string with 'UTF-8' characters, it didn't display > anything. > What should I add to display the UTF-8 characters using pango? > > Thanking you > with regards > vivek > -- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > All condemnation of others really condemns ourselves - Swami Vivekananda From vivek@lantana.tenet.res.in Fri Jun 6 02:59:00 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 0603A18121 for ; Fri, 6 Jun 2003 02:58:58 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h566wjQ04641; Fri, 6 Jun 2003 12:28:47 +0530 Subject: gtk program compilation error. From: Viveka Nathan K To: gtk-i18n-list@gnome.org Cc: cyrille@chepelov.org, nlevitt@columbia.edu Content-Type: multipart/alternative; boundary="=-H3/KZLLR0Pn0k2xeOhCD" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jun 2003 12:28:47 +0530 Message-Id: <1054882734.913.7.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-H3/KZLLR0Pn0k2xeOhCD Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks Noah and Cyrille.. Now I installed gtk+-2.0 and compiled my program. Now it says the error as /tmp/ccNUHBNN.o: In function `main': /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:62: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:65: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:74: undefined reference to `g_type_check_instance_cast' /home/smilax2/vivekanathan/gtk/helloworld.c:81: undefined reference to `g_type_check_instance_cast' /tmp/ccNUHBNN.o:/home/smilax2/vivekanathan/gtk/helloworld.c:81: more undefined references to `g_type_check_instance_cast' follow collect2: ld returned 1 exit status Before this, it said errors on some header files as 'No such file or directory'. I copied those files in the location as it needed. Now I dont know what to do for the above problem. Can you help me ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-H3/KZLLR0Pn0k2xeOhCD Content-Type: text/html; charset=utf-8 Thanks Noah and Cyrille..

Now I installed gtk+-2.0 and compiled my program.
Now it says the error as

/tmp/ccNUHBNN.o: In function `main':
/home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:62: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:65: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:74: undefined reference to `g_type_check_instance_cast'
/home/smilax2/vivekanathan/gtk/helloworld.c:81: undefined reference to `g_type_check_instance_cast'
/tmp/ccNUHBNN.o:/home/smilax2/vivekanathan/gtk/helloworld.c:81: more undefined references to `g_type_check_instance_cast' follow
collect2: ld returned 1 exit status 
Before this, it said errors on some header files as 'No such file or directory'.
I copied those files in the location as it needed.  Now I dont know what to do
for the above problem.  Can you help me ?
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-H3/KZLLR0Pn0k2xeOhCD-- From cyrille@chepelov.org Fri Jun 6 04:26:44 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chepelov.net1.nerim.net (chepelov.net1.nerim.net [62.212.101.212]) by mail.gnome.org (Postfix) with ESMTP id 4FFEE18363 for ; Fri, 6 Jun 2003 04:26:44 -0400 (EDT) Received: from muscat-eth0.intra.chepelov.org ([2001:7a8:29d4:0:2a0:24ff:fea6:57a0] helo=muscat.intra.chepelov.org) by chepelov.net1.nerim.net with esmtp (Exim 3.35 #1 (Debian)) id 19OCaP-0005bp-00; Fri, 06 Jun 2003 10:28:33 +0200 Received: from cyrille by muscat.intra.chepelov.org with local (Exim 3.36 #1 (Debian)) id 19OCYP-0006tQ-00; Fri, 06 Jun 2003 10:26:29 +0200 Date: Fri, 6 Jun 2003 10:26:29 +0200 To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: gtk program compilation error. Message-ID: <20030606082629.GA26487@chepelov.org> Mail-Followup-To: Viveka Nathan K , gtk-i18n-list@gnome.org References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1054882734.913.7.camel@dodo.lli.tenet.res.in> X-Face: "99`N"mZV/:OLp[>#d3R;u.!ivtwAEpIQDL8rD#;L3Wm)~^)Uv=#;S!LZf1y8oRY7J#JR\Lr{*4Cn*32C89ln>0~5~tm--}j%hvhj+vtW> Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Le Fri, Jun 06, 2003, à 12:28:47PM +0530, Viveka Nathan K a écrit: > Thanks Noah and Cyrille.. > > Now I installed gtk+-2.0 and compiled my program. > Now it says the error as > > /tmp/ccNUHBNN.o: In function `main': > /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to > `g_type_check_instance_cast' What arguments did you give to ld ? did you pass `pkg-config --libs gtk+-2.0` ? > Before this, it said errors on some header files as 'No such file or directory'. > I copied those files in the location as it needed. Now I dont know what to do > for the above problem. Can you help me ? What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0` ? -- Cyrille -- From vivek@lantana.tenet.res.in Fri Jun 6 05:03:28 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 8E68D184D4 for ; Fri, 6 Jun 2003 05:03:25 -0400 (EDT) Received: from lantana.iitm.ernet.in (lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h56942C22089 for ; Fri, 6 Jun 2003 14:34:02 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h56931Q08465; Fri, 6 Jun 2003 14:33:01 +0530 Subject: Re: gtk program compilation error. From: Viveka Nathan K To: Cyrille Chepelov Cc: gtk-i18n-list@gnome.org In-Reply-To: <20030606082629.GA26487@chepelov.org> References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> <20030606082629.GA26487@chepelov.org> Content-Type: multipart/alternative; boundary="=-/KP8l3ifKKUoAc1WvTY5" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 06 Jun 2003 14:33:04 +0530 Message-Id: <1054890184.939.13.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-/KP8l3ifKKUoAc1WvTY5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Cyrille.. Its working now. I compiled the source previously as gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags`=20 `gtk-config --libs` now, as I did as you told. Its going on and working properly :) Thank you once again On Fri, 2003-06-06 at 13:56, Cyrille Chepelov wrote: Le Fri, Jun 06, 2003, =E0 12:28:47PM +0530, Viveka Nathan K a =E9crit: > Thanks Noah and Cyrille.. >=20 > Now I installed gtk+-2.0 and compiled my program. > Now it says the error as >=20 > /tmp/ccNUHBNN.o: In function `main': > /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined referenc= e to > `g_type_check_instance_cast' =20 What arguments did you give to ld ? =20 did you pass `pkg-config --libs gtk+-2.0` ? =20 =20 > Before this, it said errors on some header files as 'No such file or= directory'. > I copied those files in the location as it needed. Now I dont know = what to do > for the above problem. Can you help me ? =20 What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0`= ? =20 -- Cyrille =20 --=20 =20 --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D=20 Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D All condemnation of others really condemns ourselves - Swami Vivekananda --=-/KP8l3ifKKUoAc1WvTY5 Content-Type: text/html; charset=utf-8 Thanks Cyrille.. Its working now.

I compiled the source previously as
gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags`  `gtk-config --libs`

now, as I did as you told. Its going on and working properly :)
Thank you once again

On Fri, 2003-06-06 at 13:56, Cyrille Chepelov wrote: 
Le Fri, Jun 06, 2003, à 12:28:47PM +0530, Viveka Nathan K a écrit:
>    Thanks Noah and Cyrille..
> 
>    Now I installed gtk+-2.0 and compiled my program.
>    Now it says the error as
> 
>    /tmp/ccNUHBNN.o: In function `main':
>    /home/smilax2/vivekanathan/gtk/helloworld.c:56: undefined reference to
>    `g_type_check_instance_cast'

What arguments did you give to ld ?

did you pass `pkg-config --libs gtk+-2.0` ?


>  Before this, it said errors on some header files as 'No such file or directory'.
>  I copied those files in the location as it needed.  Now I dont know what to do
>  for the above problem.  Can you help me ?

What were your CFLAGS ? Did they include `pkg-config --cflags gtk+-2.0` ?

	-- Cyrille

-- 

-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-/KP8l3ifKKUoAc1WvTY5-- From cyrille@chepelov.org Fri Jun 6 05:48:33 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chepelov.net1.nerim.net (chepelov.net1.nerim.net [62.212.101.212]) by mail.gnome.org (Postfix) with ESMTP id BB4A3184D4 for ; Fri, 6 Jun 2003 05:48:32 -0400 (EDT) Received: from muscat-eth0.intra.chepelov.org ([2001:7a8:29d4:0:2a0:24ff:fea6:57a0] helo=muscat.intra.chepelov.org) by chepelov.net1.nerim.net with esmtp (Exim 3.35 #1 (Debian)) id 19ODre-0005qM-00; Fri, 06 Jun 2003 11:50:26 +0200 Received: from cyrille by muscat.intra.chepelov.org with local (Exim 3.36 #1 (Debian)) id 19ODpd-0006hx-00; Fri, 06 Jun 2003 11:48:21 +0200 Date: Fri, 6 Jun 2003 11:48:21 +0200 To: Viveka Nathan K Cc: gtk-i18n-list@gnome.org Subject: Re: gtk program compilation error. Message-ID: <20030606094821.GA25745@chepelov.org> Mail-Followup-To: Viveka Nathan K , gtk-i18n-list@gnome.org References: <1054882734.913.7.camel@dodo.lli.tenet.res.in> <20030606082629.GA26487@chepelov.org> <1054890184.939.13.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1054890184.939.13.camel@dodo.lli.tenet.res.in> X-Face: "99`N"mZV/:OLp[>#d3R;u.!ivtwAEpIQDL8rD#;L3Wm)~^)Uv=#;S!LZf1y8oRY7J#JR\Lr{*4Cn*32C89ln>0~5~tm--}j%hvhj+vtW> Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Le Fri, Jun 06, 2003, à 02:33:04PM +0530, Viveka Nathan K a écrit: > I compiled the source previously as > gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags` `gtk-config > --libs` Oh, I see. No wonder you had gtk 1.2 files coming in; gtk-config is for the 1.2 versions. Happy to know it's working now. -- Cyrille -- From otaylor@redhat.com Mon Jun 9 01:04:55 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 037D218169; Mon, 9 Jun 2003 01:04:54 -0400 (EDT) Received: from vpn50-35.rdu.redhat.com (vpn50-35.rdu.redhat.com [172.16.50.35]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5954sK32431; Mon, 9 Jun 2003 01:04:54 -0400 Subject: Pango-1.2.3 released From: Owen Taylor To: gnome-announce-list@gnome.org, gtk-i18n-list@gnome.org, gtk-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-devel-list@gnome.org Content-Type: text/plain Organization: Message-Id: <1055135072.1665.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 09 Jun 2003 01:04:32 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Pango-1.2.3 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.2/ As compared to Pango-1.2.1 (Pango-1.2.2 was a short-lived release and never announced), this release contains various bug fixes, a large speedup to layout with the Xft and FT2 backends (as much as 5 times faster for short strings), and new shapers to allow Indic and Thai to be used with the FT2 backend. About Pango =========== Pango is a library for layout and rendering of text, with an emphasis on internationalization. Pango can be used anywhere that text layout is needed, though most usage so far as been in the context of the GTK+ widget toolkit. Pango forms the core of text and font handling for GTK+ 2. Pango is designed to be modular; the core Pango layout can be used with four different font backends: - Core X windowing system fonts - Client-side fonts on X using the Xft2 library - Direct rendering of scalable fonts using the FreeType library - Native fonts on Microsoft platforms Dynamically loaded modules then handle text layout for particular combinations of script and font backend. Pango-1.2 ships with a wide selection of modules, including modules for Hebrew, Arabic, Hangul, Thai, and a number of Indic scripts. Virtually all of the world's major scripts are supported. As well as the low level layout rendering routines, Pango includes PangoLayout, a high level driver for laying out entire blocks of text, and routines to assist in editing internationalized text. More information about Pango is available from http://www.pango.org/. Pango depends on version 2.2.0 or newer of the GLib library; more information about GLib can be found at http://www.gtk.org/. Overview of Changes in Pango 1.2.2 ================================== * Fix operation with --disable-debug [Jeff Waugh] * Improve handling of ink rectangle extents for empty runs * Fix problem with keynav at line boundaries for RTL text [Matthias Clasen] Overview of Changes in Pango 1.2.2 ================================== * Cache fontsets for the Xft and FT2 backends, a large speedup for short strings [Owen Taylor, Soeren Sandmann] * Make built in rendering functions, especially the FT2 one, work more like the GDK implementation [Sven Neumann] * Add an indic-ft2 module [Kapil Chowskey], Add a thai-ft2 module [Theppitak Karoonboonyanan] * Optimize pango_x_render() by drawing multiple character with a single request when possible [Morten Welinder] * Change the handling of attributes that cover only partial glyphs [Owen, Taneem Ahmed, Sunil Mohan Adapa] * Fix problems with Arial Unicode and the Opentype code [Owen, Noah Levitt] * Fix common crash for fonts missing a GDEF table * Fix common portability problem with informative output at end of configure. * Build cleanups and fixes [Tim Mooney, Chris Ross, Akira Tagoh, Will Partain, James Su] * Miscellaneous bug fixes and cleanups [Simon Budig, Rick Jones, Noah, Padraig O'Briain, Benjamin Otte, Andrey Panov, Federic Zhang] * Documentation fixes [Tim, Sven] Owen Taylor 9 June 2003 From sky@icqus.dyndns.org Mon Jun 9 16:32:24 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from icqus.dyndns.org (12-215-147-200.client.mchsi.com [12.215.147.200]) by mail.gnome.org (Postfix) with ESMTP id 67E75187AD for ; Mon, 9 Jun 2003 16:32:24 -0400 (EDT) Received: from icqus.dyndns.org (sky@localhost.my.domain [IPv6:::1]) by icqus.dyndns.org (8.12.9/8.12.9) with ESMTP id h59KWNpp005422 for ; Mon, 9 Jun 2003 16:32:23 -0400 (EDT) Received: (from sky@localhost) by icqus.dyndns.org (8.12.9/8.12.9/Submit) id h59KU0bD021164 for gtk-i18n-list@gnome.org; Mon, 9 Jun 2003 16:30:00 -0400 (EDT) Date: Mon, 9 Jun 2003 16:30:00 -0400 (EDT) From: Teardrop Sky Message-Id: <200306092030.h59KU0bD021164@icqus.dyndns.org> To: gtk-i18n-list@gnome.org Subject: unicode fonts Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: i had a question about unicode fonts that i posted to gtk-list, but i just discovered this list and realized it had been more appropriate here, but in short i'm looking for examples of unicode code written for gtk+2. (specifically with greek and hebrew fonts, but anything to sift through would be welcome) links or short examples, whatever. thanks :) ~sky From vivek@lantana.tenet.res.in Tue Jun 10 08:40:48 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id F3849180EE for ; Tue, 10 Jun 2003 08:40:45 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5ACea804262 for ; Tue, 10 Jun 2003 18:10:39 +0530 Subject: compiling gtk+-2.2.1 From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-ttvrksX/Kvt+Z581nOPE" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Jun 2003 18:10:54 +0530 Message-Id: <1055248857.10655.3.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-ttvrksX/Kvt+Z581nOPE Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii I am upgrading the gtk (which is available with RH 8.0) to gtk+-2.2.1. After completing the make and make install, While starting the gnome-session, I got the following error. gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name This lib is linked with the lib which is currently created as follows lrwxrwxrwx 1 root root 25 Jun 10 17:55 /usr/lib/libgdk-x11-2.0.so.0 -> libgdk-x11-2.0.so.0.200.1 What should I do ? with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-ttvrksX/Kvt+Z581nOPE Content-Type: text/html; charset=utf-8 Hii
I am upgrading the gtk (which is available with RH 8.0) to gtk+-2.2.1. After completing the make and make install,  While starting the gnome-session, I got the following error.

gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name

This lib is linked with the lib which is currently created as follows
lrwxrwxrwx    1 root     root           25 Jun 10 17:55 /usr/lib/libgdk-x11-2.0.so.0 -> libgdk-x11-2.0.so.0.200.1

What should I do ?

with regards
vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-ttvrksX/Kvt+Z581nOPE-- From vivek@lantana.tenet.res.in Thu Jun 12 04:35:17 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id EFFD318D26 for ; Thu, 12 Jun 2003 04:35:14 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5C8Yk830183 for ; Thu, 12 Jun 2003 14:04:48 +0530 Subject: [Fwd: Use of Bonobo (fwd)] From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-v4j5dv3CjxL1ERGc2Gfa" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 12 Jun 2003 14:05:32 +0530 Message-Id: <1055406934.20734.4.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-v4j5dv3CjxL1ERGc2Gfa Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii all, Can anyone please tell me what is the role of Bonobo object in gedit? with regards vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-v4j5dv3CjxL1ERGc2Gfa Content-Type: text/html; charset=utf-8 
Hii all,
	Can anyone please tell me what is the role of Bonobo object in gedit?

with regards
vivek
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-v4j5dv3CjxL1ERGc2Gfa-- From chutz@gg3.net Sat Jun 14 04:00:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from tiger.gg3.net (142.13.111.219.st.bbexcite.jp [219.111.13.142]) by mail.gnome.org (Postfix) with SMTP id 855E618512 for ; Sat, 14 Jun 2003 04:00:29 -0400 (EDT) Received: (qmail 23398 invoked by uid 0); 14 Jun 2003 08:00:28 -0000 Received: from tiger.gg3.net (10.0.0.9) by 0 with SMTP; 14 Jun 2003 08:00:28 -0000 Received: from lion.gg3.net (10.0.0.2) by tiger.gg3.net (tmda-ofmipd) with ESMTP; Sat, 14 Jun 2003 17:00:27 +0900 Received: by lion.gg3.net (sSMTP sendmail emulation); Sat, 14 Jun 2003 17:00:27 +0900 Date: Sat, 14 Jun 2003 17:00:27 +0900 To: gtk-i18n-list@gnome.org Subject: Regarding selection of alternate fonts (with untagged text) Message-ID: <20030614080027.GA4590%chutz@gg3.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.5.4i-ja.1 From: Georgi Georgiev Mail-Followup-To: gtk-i18n-list@gnome.org X-Delivery-Agent: TMDA/0.74 (Citation) X-Primary-Address: chutz@gg3.net Reply-To: Georgi Georgiev Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello list, I have a question/problem which was partially answered at http://www.pango.org/font-selection.shtml (I hope this is the right list to post my question to). My question is related to language auto-tagging and the selection of an alternate font that Pango makes in different locales. My problem is that basically, it chooses different fonts for Cyrillic text when LC_ALL is set to bg_BG or ja_JP. There were a few interesting posts I found in the mailing list archive, but the talk being too broad, I had trouble understanding if this problem is being tackled or not. Here goes a more detailed description of what I mean. What happens is that I for example have my locale set to ja_JP. Actually it is only LC_CTYPE=ja_JP LC_COLLATE=ja_JP LC_MONETARY=ja_JP and the rest LC_*=C (LC_ALL is unset). I need the few ja_JP because I want to be able to properly display Japanese in all applications, but I prefer to read messages in English. I also need it for Japanese input. However, I sometimes also work with Cyrillic (actually pretty often). What happens when Pango is asked for a font that does not have the Cyrillic characters is that it of course does that auto-tagging and substitution (I guess) and hands me a different font that has the characters that I need. In my /etc/fonts/fonts.conf I have the following: sans-serif Bitstream Vera Sans Arial Verdana Nimbus Sans L Luxi Sans Helvetica Kochi Gothic AR PL KaitiM GB AR PL KaitiM Big5 Baekmuk Dotum SimSun When I run a program with LC_ALL=bg_BG, Cyrillic is displayed in Arial. However, when I run it with LC_ALL=ja_JP I see Cyrillic displayed in Kochi Gothic (meaning ugly, square letters). I am also attaching two small screenshots to illustrate what I mean. So my question is, how do I make Pango "prefer" Arial over Kochi when my locale is ja_JP (short of specifying Arial explicitly, which works). I don't know if it is possible, but I just wanted to state my problem. -- /^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\ / Georgi Georgiev (-< / A pencil with no point needs no \ \ chutz@chubaka.net /\ .o)\ eraser. / / +81(90)6266-1163 V_/_ |(/)/ \ \___________________________/\__________________________________/ --HlL+5n6rz5pIUxbD Content-Type: image/png Content-Disposition: attachment; filename="bg_BG.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASkAAAAcCAAAAAAYMhb0AAAC2UlEQVR4nO1YPWsVQRQ9J0LA 4CchoCLa2QQbkYCViGBra6MIVhZ2/gNbi7RK7BRBQbDTfxCD6Q3YaCEBSVKkU8ix2Llz7+zb F+Yl4CMwh7A792vm7tkzs49QaKjCzLQbODKYAZmGZB52pl8xEOmDzBMwTFUmk6WHJLFzZ+5A vQ/3Md5/uFzXFCGBwcQECwIAlCZgHo1J6zmWv/yYcKWMbjkGayiJI9m9TFaMZtxU+RAjDzSy ODn4SgiNlncqI8BUlioF4MPtBZBYI0G+mb+xaZbpNAcBEt9uzs0ufuqKRdKmtEs3aXjVki3G 3CGNX8UAoLwdos8yJcluhu5RNRhNVUiMhIpYEt3FdKkuDz/jhQToASDg8Qrum+U5KSgBuvb6 7zoueGuCINmiKU2Q+eB39JtCqkR+Ethf8uXRREzBufVb4A+BrbwyBqYsSZvdkIDflwABW9tY MMtzUrDzrD29Csqe0pZVXD9cFBtw1oyDgpIY6JM4/ts3sLEiJQOQn04jWRw+OgXg/Z8nAPDq IQDg7GnsuGWI5vLSxkqWJZ2uJJssWXT7hiL7G425vXRQyLoUu6D7SoWMaKqQZ62mgm48Mmb3 BUnsXeZ3AVd+AQI2t3HOrD0cS+kpKAE6gd1dF4FJKZCfheSNmGk6ifIph954GXZNCRzUUaEA a23fj80+n71eTfpNcU9vAVw/DwB49hF3zdrCUspMQQDAKay/9GLjOz/RyOICUHqp7nNkvVB9 mfV97i9PtUJTZVKUmksuCM6GxSvvneE9aX3FooDVzvP85K1ts45f/JnyVr0XvJs/8ygvnU/v UkOFSrLpmbLtNTxH6etuJW0Tgzhc/QHmKzqmCFlZUUynNg2pWOvJlM/KoKjkK1wHA6GpM/Uf 0V/Xvl1VtQiH0pT6/3+Y1hs6emj/S6hFY6oWjalaNKZq0ZiqRWOqFo2pWjSmatGYqkVjqhaN qVo0pmrRmKrFPw6cTkdTqI2EAAAAAElFTkSuQmCC --HlL+5n6rz5pIUxbD Content-Type: image/png Content-Disposition: attachment; filename="ja_JP.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAATgAAAAcAQAAAADdTp5TAAABd0lEQVR4nO3Rv0sCURwA8EvD lsihpSByiVwLV+9uDP+B/oRGHYQkOLuiQaLBwSXRvKHRwaGhoU4Ho5KMm4LA6IRCqdDnD+R5 3vO+PU/Loij/AL88vjz4fnjfL+/LwGjBjOqkLCQEKAOs8DxRyLCimAeADFwUZoTezSXxBL64 mxRSIFyVCe6CiBiJB68AJQd13JyHvRQ/3IOFefQ1q/IRJg7TGRsCPCvUufPX0cqnk9aNQ5QJ FV92gve2ib6rOZXefPlctFKPS/PFenwtHJvaS5Qzr7qGt9SA+Z6N9rWDC7jpXOxJ53wnLZ1D WFax/GYtBM7wZt+RhlBbUpoucOdzsUonjZItmkIZGyOjIHVI5DB1UerofKbbj1S1tC92p6VR gFURi7oF7ywS09TtZklj0l5ytv1gWfZELvyL0uptc2HqgE0hVtWT3WN1O4jVwT7Kw38zzIyh 41cM/urUEM81XeF/OiLCL8GAYe0tqW3/Z79/l8du7L7FO3330tQ/Xb18AAAAAElFTkSuQmCC --HlL+5n6rz5pIUxbD-- From vivek@lantana.tenet.res.in Tue Jun 17 05:15:02 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 0299418653 for ; Tue, 17 Jun 2003 05:14:56 -0400 (EDT) Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5H9EEC02535; Tue, 17 Jun 2003 14:44:19 +0530 Subject: gtk+-2.2.1 compilation From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-Q1Eg8cjg6cVUshCdvynd" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 17 Jun 2003 15:45:16 +0530 Message-Id: <1055844921.801.99.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-Q1Eg8cjg6cVUshCdvynd Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all I compiled the gtk+-2.2.1 using the source. After the compilation, while starting gnome, it says the error, gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name what is this 'relocation error' ? what should I do for this ? with regards Vivek -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-Q1Eg8cjg6cVUshCdvynd Content-Type: text/html; charset=utf-8 Hi all
I compiled the gtk+-2.2.1 using the source.
After the compilation, while starting gnome, it says the error,

gnome-session: relocation error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: g_get_application_name

what is this 'relocation error' ? what should I do for this ?

with regards
Vivek 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-Q1Eg8cjg6cVUshCdvynd-- From klchxbec@yahoo.com Wed Jun 18 01:02:20 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from web13901.mail.yahoo.com (web13901.mail.yahoo.com [216.136.175.27]) by mail.gnome.org (Postfix) with SMTP id C46961823F for ; Wed, 18 Jun 2003 01:02:19 -0400 (EDT) Message-ID: <20030618050219.94343.qmail@web13901.mail.yahoo.com> Received: from [203.200.195.2] by web13901.mail.yahoo.com via HTTP; Tue, 17 Jun 2003 22:02:19 PDT Date: Tue, 17 Jun 2003 22:02:19 -0700 (PDT) From: klchxbec Subject: fix to pango GSUB To: gtk-i18n-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Here is a one-liner to fix pango's GSUB code for rendering kannada text. ftp://ftp.gtk.org/incoming/ftxgsub-bad.png ftp://ftp.gtk.org/incoming/ftxgsub-good.png Index: pango/opentype/ftxgsub.c =================================================================== RCS file: /cvs/gnome/pango/pango/opentype/ftxgsub.c,v retrieving revision 1.6 diff -u -r1.6 ftxgsub.c --- pango/opentype/ftxgsub.c 16 Apr 2003 03:58:17 -0000 1.6 +++ pango/opentype/ftxgsub.c 17 Jun 2003 12:26:01 -0000 @@ -3823,7 +3823,7 @@ /* we are starting for lookahead glyphs right after the last context glyph */ - curr_pos = j; + curr_pos += j; s_in = &in->string[curr_pos]; lc = ccsf3->LookaheadCoverage; __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From zenithlau@i-cable.com Wed Jun 18 11:12:43 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from virgo.i-cable.com (virgo.i-cable.com [203.83.111.75]) by mail.gnome.org (Postfix) with SMTP id 2AA1B180E4 for ; Wed, 18 Jun 2003 11:12:42 -0400 (EDT) Received: (qmail 8987 invoked by uid 706); 18 Jun 2003 15:12:36 -0000 Received: from cm61-10-38-94.hkcable.com.hk (HELO ?192.168.0.34?) (61.10.38.94) by 0 with SMTP; 18 Jun 2003 15:12:13 -0000 Subject: Font configuration issues. From: Zarick Lau Reply-To: zenithlau@i-cable.com To: gtk-i18n-list@gnome.org Content-Type: text/plain Organization: NixStyle.Net Message-Id: <1055949103.5609.8.camel@zlap> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 18 Jun 2003 23:11:43 +0800 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi list, I am using gtk 2.2.1 with Gnome 2.2, I found that if the selection of font is effectively determined by LC_CTYPE, why?? In my understanding, LC_CTYPE should only influence how a apps process the data from external. Though I am not sure.. Another important issues is, is it possible to configuration the system (fonts.conf right?) so that, when in non en locale, the system will still use en fonts to render the latin messages, while taking another fonts for other language? If it is only a configuration issues, would you mind show me a bit examples? Regards, Zarick Lau From Tony.Graham@Sun.COM Wed Jun 18 11:22:48 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.gnome.org (Postfix) with ESMTP id B3BEB180E4 for ; Wed, 18 Jun 2003 11:22:47 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5IFMkLv026967 for ; Wed, 18 Jun 2003 08:22:46 -0700 (PDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5IFMjg6025853 for ; Wed, 18 Jun 2003 16:22:45 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5IFP1i04287; Wed, 18 Jun 2003 16:25:01 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16112.33869.254511.67633@tenso.ireland.sun.com> Date: Wed, 18 Jun 2003 16:25:01 +0100 To: gtk-i18n-list@gnome.org Subject: PangoPDF 1.2.3.0 released X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: PangoPDF is a version of Pango with additional PDF/PostScript backends and support for additional XSL-related text attributes. This release updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and Xft backends to match Pango 1.2.3. Download PangoPDF from http://sourceforge.net/projects/pangopdf/. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From vivek@lantana.tenet.res.in Thu Jun 19 00:26:38 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lantana.iitm.ernet.in (lantana.tenet.res.in [202.144.28.166]) by mail.gnome.org (Postfix) with ESMTP id 75EA4181CD for ; Thu, 19 Jun 2003 00:26:36 -0400 (EDT) Received: from swan.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5J4PkC11643; Thu, 19 Jun 2003 09:55:48 +0530 Subject: GTK+- runtime error From: Viveka Nathan K To: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-c3mWW04KSiClVd8B3bqY" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 19 Jun 2003 10:06:33 +0530 Message-Id: <1055997396.1426.4.camel@swan.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-c3mWW04KSiClVd8B3bqY Content-Type: text/plain Content-Transfer-Encoding: 7bit Hii all. I am compiling the GTK+ from the source. The version I am using is 2.0.6. Previously i went through the latest versions, but it needs the latest, xft, glib etc.. There also I got a problem of 'relocation error'. so, I thought to use the same version of GTK installed in Redhat 8.0. After that, while i start 'gedit' or 'gnome-session' anything, i got the following error. What i have to do to make the compilation successfully ? The program 'gedit' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 46 error_code 16 request_code 154 minor_code 20) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Or can anyone tell me, with 'which version of which', I can successfully compile the Pango and GTK from source? Thanking you, with regards Vivek. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-c3mWW04KSiClVd8B3bqY Content-Type: text/html; charset=utf-8 Hii all.

I am compiling the GTK+ from the source. The version I am using is 2.0.6.  Previously i went through the latest versions, but it needs the latest, xft, glib etc..  There also I got a problem of
'relocation error'. so, I thought to use the same version of GTK installed in Redhat 8.0.

After that, while i start 'gedit' or 'gnome-session' anything, i got the following error.  What i have to
do to make the compilation successfully ?

The program 'gedit' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadLength (poly request too large or internal Xlib length erro'.
  (Details: serial 46 error_code 16 request_code 154 minor_code 20)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Or can anyone tell me, with 'which version of which', I can successfully compile the Pango and GTK from source?

Thanking you,
with regards
Vivek. 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Ph:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves - Swami Vivekananda
--=-c3mWW04KSiClVd8B3bqY-- From ittay@qlusters.com Sun Jun 22 10:17:59 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from hirame.qlusters.com (adsl-139-109.barak.net.il [62.90.139.109]) by mail.gnome.org (Postfix) with ESMTP id 2FA62181E0 for ; Sun, 22 Jun 2003 10:17:58 -0400 (EDT) Received: from ittay ([10.100.0.13]) by hirame.qlusters (8.10.2/8.10.2) with ESMTP id h5MEFge26386 for ; Sun, 22 Jun 2003 17:15:42 +0300 Subject: how do i add windows-1255 encoding? From: Ittay Dror To: gtk-i18n-list@gnome.org In-Reply-To: <20030622133801.28246.23535.Mailman@moniker.gnome.org> References: <20030622133801.28246.23535.Mailman@moniker.gnome.org> Content-Type: text/plain Message-Id: <1056291353.18485.6.camel@ittay> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0-1mdk Date: 22 Jun 2003 17:15:53 +0300 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: i'm using the new evolution, and the only hebrew encoding i have is iso-8859-8. unfortunately, all the words are in reverse order. i thought adding windows-1255 encoding would solve this. how do i add it? thanx, ittay -- ======================================= Ittay Dror (ittay@qlusters.com) User Space, R&D Qlusters Inc. Tel: +972-3-6081956 Fax: +972-3-6081841 From Takao.Fujiwara@Sun.COM Fri Jun 20 10:49:28 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.gnome.org (Postfix) with ESMTP id E5DBA1843D for ; Fri, 20 Jun 2003 10:49:27 -0400 (EDT) Received: from udsylm-mail1.Japan.Sun.COM ([129.158.26.30]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5KEnQep002428 for ; Fri, 20 Jun 2003 08:49:27 -0600 (MDT) Received: from requiem (requiem [129.158.28.20]) by udsylm-mail1.Japan.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.1p1) with SMTP id h5KEnPY25373; Fri, 20 Jun 2003 23:49:26 +0900 (JST) Message-Id: <200306201449.h5KEnPY25373@udsylm-mail1.Japan.Sun.COM> Date: Fri, 20 Jun 2003 23:49:19 +0900 (JST) From: Takao Fujiwara - Tokyo S/W Center Reply-To: Takao Fujiwara - Tokyo S/W Center Subject: alias in pangox.alias To: gtk-i18n-list@gnome.org Cc: Takao.Fujiwara@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zu2WY8a+lt3tBgPe0y0esA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 sun4u sparc Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi experts, I have quality issues about Japanese fonts in Pango. When we choose small size fonts in GNOME2.0.2 (pango 1.0.5) + Solaris 9, The rendering in Japanese fonts are very ugly. I have one remedy to add some alias to pangox.alias. However I don't have an explicit answer that it is no problem for pango specification. I would like to ask you it. Do you have any ideas to add gothic and mincho as aliases to pangox.alias below? gothic normal normal normal normal \ "-ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0201.1976-0,\ -ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0212.1990-0,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-1,\ -ricoh-gothic-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-2,\ -adobe-helvetica-medium-r-normal--*-*-*-*-*-*-iso8859-1" mincho normal normal normal normal \ "-ricoh-hg mincho l-medium-r-normal--*-*-*-*-c-*-jisx0201.1976-0,\ -ricoh-hg mincho l-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0212.1990-0,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-1,\ -ricoh-mincho-medium-r-normal--*-*-*-*-*-*-jisx0213.2000-2,\ -adobe-utopia-medium-r-normal--*-*-*-*-*-*-iso8859-1" This remedy can fix problems that characters are very ugly in small Japanese fonts when gtk applications(Mozilla, etc) choose any fonts beside sans, serif, and monospace. I think that the issue occurs because 'gothic' in jisx0208 does not have small point size but 'hg gothic b' in jisx0208 has small point size. % xlsfonts -fn '-sun-minchou-bold-r-normal--*-*-*-*-c-*-jisx0208.1983-0' -sun-gothic-medium-r-normal--0-0-75-75-c-0-jisx0208.1983-0 -sun-gothic-medium-r-normal--14-120-75-75-c-120-jisx0208.1983-0 <---- -sun-gothic-medium-r-normal--16-140-75-75-c-140-jisx0208.1983-0 -sun-gothic-medium-r-normal--18-160-75-75-c-160-jisx0208.1983-0 -sun-gothic-medium-r-normal--22-200-75-75-c-200-jisx0208.1983-0 -sun-gothic-medium-r-normal--26-240-75-75-c-240-jisx0208.1983-0 % xlsfonts -fn '-ricoh-hg gothic b-medium-r-normal--*-*-*-*-c-*-jisx0208.1983-0' -ricoh-hg gothic b-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--0-0-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--10-100-72-72-c-100-jisx0208.1983-0 <---- -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-0-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--12-120-72-72-c-120-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--14-140-72-72-c-140-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--16-160-72-72-c-160-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--18-180-72-72-c-180-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--20-200-72-72-c-200-jisx0208.1983-0 -ricoh-hg gothic b-medium-r-normal--24-240-72-72-c-240-jisx0208.1983-0 Sans, serif, and monospace have similar problems. If sans has only sun-gothic as jisx0208 font, pango renders ugly glyph. But If sans has ricoh-hg gothic b as jisx0208 font, pago renders fine glyph. So when pango refers 'gothic', I would like to point 'hg gothic b' in jisx0208/0201 against 'gothic', and when pango refers 'mincho', I would like to point 'hg mincho l' in jisx0208/0201 against 'mincho'. pangox.alias in Solaris has distinct directory(/etc/pango/$locale/pangox.alias) by locale, so pangox.alias can be set in each locale. I think this remedy has a pretty pit, i.e. If set 'gothic bold normal normal normal' in pangox.alias, user can see duplicated 'Bold' fonts in gnome-font-properties. It is no problem in 'gothic normal normal normal normal' because gothic fonts originally have 'medium' style but not 'normal' style. I do not join this mail alias, so please mail to me directly. Thanks in advance, Sun Microsystems Software Engineer Tokyo Software Center Takao Fujiwara E-Mail: Takao.Fujiwara@Sun.COM Tel: +81-45-227-9287(direct)/Fax: +81-45-225-5295 From otaylor@redhat.com Mon Jun 23 06:20:33 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1CFD018848 for ; Mon, 23 Jun 2003 06:20:33 -0400 (EDT) Received: from vpn50-2.rdu.redhat.com (vpn50-2.rdu.redhat.com [172.16.50.2]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5NAJxK02035; Mon, 23 Jun 2003 06:19:59 -0400 Subject: Re: PangoPDF 1.2.3.0 released From: Owen Taylor To: Tony Graham Cc: gtk-i18n-list@gnome.org In-Reply-To: <16112.33869.254511.67633@tenso.ireland.sun.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> Content-Type: text/plain Organization: Message-Id: <1056363575.13947.45.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 23 Jun 2003 06:19:36 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > PangoPDF is a version of Pango with additional PDF/PostScript backends > and support for additional XSL-related text attributes. This release > updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and > Xft backends to match Pango 1.2.3. > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. I'm being incredibly lazy here, and really should go look at the code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps the real question is, what do you mean by "backend" here?) I can't really see how you'd replace the Pango backend libraries and/or the shapers and keep keep things working reasonably. Regards, Owen From maclas@gmx.de Mon Jun 23 07:24:44 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mx0.gmx.net (mx0.gmx.de [213.165.64.100]) by mail.gnome.org (Postfix) with SMTP id 5398F183F0 for ; Mon, 23 Jun 2003 07:24:44 -0400 (EDT) Received: (qmail 27486 invoked by uid 0); 23 Jun 2003 11:24:42 -0000 Date: Mon, 23 Jun 2003 13:24:42 +0200 (MEST) From: Matthias Clasen To: Owen Taylor Cc: gtk-i18n-list@gnome.org MIME-Version: 1.0 References: <1056363575.13947.45.camel@localhost.localdomain> Subject: Re: PangoPDF 1.2.3.0 released X-Priority: 3 (Normal) X-Authenticated-Sender: #0014083743@gmx.net X-Authenticated-IP: [195.243.100.246] Message-ID: <15429.1056367482@www60.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > > PangoPDF is a version of Pango with additional PDF/PostScript backends > > and support for additional XSL-related text attributes. This release > > updates PangoPDF and its GNOME Print (pangogp), PDFlib, FT2, X, and > > Xft backends to match Pango 1.2.3. > > > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > I'm being incredibly lazy here, and really should go look at the > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > the real question is, what do you mean by "backend" here?) > > I can't really see how you'd replace the Pango backend libraries > and/or the shapers and keep keep things working reasonably. > From the PangoPDF homepage: PangoPDF implements a version of the Pango (http://www.pango.org/) library with a PDF backend for creating PDF output. This library also implements several of the inline properties defined by XSL (http://www.w3.org/TR/xsl/) that are not currently implemented by Pango. PangoPDF is designed to be API-compatible with the corresponding Pango version. The version number of the PangoPDF library, therefore, reflects the version number of the Pango version upon which library is based. The current PangoPDF version is 1.2.0.1, since it is based upon Pango 1.2.0. The goal of this project is to make itself redundant by implementing PDF support and XSL support so well that the additions are incorporated into Pango itself. The PangoPDF library tracks the official Pango library so the PangoPDF library can incorporate non PDF-related improvements and API changes as they are incorporated into Pango. -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! From vivek@lantana.tenet.res.in Tue Jun 24 07:00:39 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from volcano.tenet.res.in (unknown [202.144.28.163]) by mail.gnome.org (Postfix) with ESMTP id 238F4181D4; Tue, 24 Jun 2003 07:00:36 -0400 (EDT) Received: from lantana.iitm.ernet.in (IDENT:DcG7BlZfrrIv1KNv03I8HUSr4W9KMQwn@lantana.iitm.ernet.in [144.16.241.207]) by volcano.tenet.res.in (8.11.6/8.11.6) with ESMTP id h5OB0wC16387; Tue, 24 Jun 2003 16:30:58 +0530 Received: from dodo.lli.tenet.res.in (aster [144.16.241.214]) by lantana.iitm.ernet.in (8.11.6/8.11.6) with ESMTP id h5OAwsC00995; Tue, 24 Jun 2003 16:28:55 +0530 Subject: Encoding other than UTF-8 ? From: Viveka Nathan K To: gtk-list@gnome.org Cc: gtk-i18n-list@gnome.org Content-Type: multipart/alternative; boundary="=-e35IJaWRw9jjkFMGgWt7" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 24 Jun 2003 16:30:58 +0530 Message-Id: <1056452459.6174.30.camel@dodo.lli.tenet.res.in> Mime-Version: 1.0 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --=-e35IJaWRw9jjkFMGgWt7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all.. How can I use the encoding other than UTF-8, in GNOME ? If I set the LOCALE to en_US.ISO-8859-1, it saves the file in UTF-8 format only. How can I change it ? Applications like 'gtk2edit' are having the options to store in different encodings, but in 'gedit', I couldnt do that. Is there any way to do that ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Viveka Nathan K, DON Lab, IITM, Chennai-36, India. Phone - Mobile: 0-9444167493 Off:044-22578904/8353 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All condemnation of others really condemns ourselves - Swami Vivekananda --=-e35IJaWRw9jjkFMGgWt7 Content-Type: text/html; charset=utf-8 Hi all..
How can I use the encoding other than UTF-8, in GNOME ?
If I set the LOCALE to en_US.ISO-8859-1, it saves the file in UTF-8 format only.
How can I change it ?  Applications like 'gtk2edit' are having the options to store
in different encodings, but in  'gedit', I couldnt do that.

Is there any way to do that ? 
-- 


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Viveka Nathan K, DON Lab, IITM, Chennai-36, India. 
Phone - Mobile: 0-9444167493 Off:044-22578904/8353        
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
All condemnation of others really condemns ourselves 
- Swami Vivekananda
--=-e35IJaWRw9jjkFMGgWt7-- From Tony.Graham@Sun.COM Wed Jun 25 06:36:05 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.gnome.org (Postfix) with ESMTP id A477318237 for ; Wed, 25 Jun 2003 06:36:04 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PAa3vc007545 for ; Wed, 25 Jun 2003 04:36:03 -0600 (MDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PAa2g6012556 for ; Wed, 25 Jun 2003 11:36:02 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5PAcGo09573; Wed, 25 Jun 2003 11:38:16 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16121.31640.237024.593290@tenso.ireland.sun.com> Date: Wed, 25 Jun 2003 11:38:16 +0100 To: gtk-i18n-list@gnome.org Subject: Re: PangoPDF 1.2.3.0 released In-Reply-To: <1056363575.13947.45.camel@localhost.localdomain> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400: > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: ... > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > I'm being incredibly lazy here, and really should go look at the > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > the real question is, what do you mean by "backend" here?) PangoPDF includes all of the backends so PangoPDF can be used as a drop-in replacement for Pango. To use PangoPDF instead of Pango in an application, just edit the application's configure.in (or configure.ac) to prefix Pango's pkg-config package names with 'pangopdf-', then rerun autoconf and configure. That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF. The FT2/X/Xft backends in PangoPDF are really just vanilla Pango. I expect that PangoPDF will add support for the 'XSL' attributes (which are also CSS3 attributes) to the FT2 and Xft backends (as one person has done for FT2 in his version of PangoPDF), but I expect to first implement the 'XSL' attributes as (conditionally) part of the PangAttrType enumeration instead of registering them with pango_attr_type_register() because it's so much easier to work with attribute types as constants rather than variables. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From otaylor@redhat.com Wed Jun 25 11:22:11 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DD55918C6E for ; Wed, 25 Jun 2003 11:22:10 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5PFM5K27129; Wed, 25 Jun 2003 11:22:05 -0400 Subject: Re: PangoPDF 1.2.3.0 released From: Owen Taylor To: Tony Graham Cc: gtk-i18n-list@gnome.org In-Reply-To: <16121.31640.237024.593290@tenso.ireland.sun.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> <16121.31640.237024.593290@tenso.ireland.sun.com> Content-Type: text/plain Message-Id: <1056554525.14257.195.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 25 Jun 2003 11:22:05 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Wed, 2003-06-25 at 06:38, Tony Graham wrote: > Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400: > > On Wed, 2003-06-18 at 11:25, Tony Graham wrote: > ... > > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/. > > > > I'm being incredibly lazy here, and really should go look at the > > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps > > the real question is, what do you mean by "backend" here?) > > PangoPDF includes all of the backends so PangoPDF can be used as a > drop-in replacement for Pango. > > To use PangoPDF instead of Pango in an application, just edit the > application's configure.in (or configure.ac) to prefix Pango's > pkg-config package names with 'pangopdf-', then rerun autoconf and > configure. > > That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF. > > The FT2/X/Xft backends in PangoPDF are really just vanilla Pango. I > expect that PangoPDF will add support for the 'XSL' attributes (which > are also CSS3 attributes) to the FT2 and Xft backends (as one person > has done for FT2 in his version of PangoPDF), but I expect to first > implement the 'XSL' attributes as (conditionally) part of the > PangAttrType enumeration instead of registering them with > pango_attr_type_register() because it's so much easier to work with > attribute types as constants rather than variables. While it's fine to experiment with a fork of Pango, I'd really strongly encourage you to try to get API additions into the main Pango. Pango really isn't a big enough of a project to need two competing versions, and there are some definately potential problems with what you are doing. For example, if you modify libgnomeprint-2.2.1.2 as you describe then you'll link against *both* Pango and PangoPDF when you have an app that uses GTK+ and uses libgnomeprint. And the effects of that will be unpredicatable and probably bad. But why is pango_attr_type_register() so hard to use? I don't really understand the problem. Sure, it's a few more lines of code, but that doesn't quite seem worth maintaining a fork. Regards, Owen From Tony.Graham@Sun.COM Wed Jun 25 18:38:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.gnome.org (Postfix) with ESMTP id 3984118C60 for ; Wed, 25 Jun 2003 18:38:30 -0400 (EDT) Received: from sunire.Ireland.Sun.COM ([129.156.220.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PMcRvc013790 for ; Wed, 25 Jun 2003 16:38:28 -0600 (MDT) Received: from tenso.ireland.sun.com (tenso [129.156.220.74]) by sunire.Ireland.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PMcRg6025351 for ; Wed, 25 Jun 2003 23:38:27 +0100 (BST) Received: (from tg127171@localhost) by tenso.ireland.sun.com (8.10.2+Sun/8.10.2) id h5PMefA10115; Wed, 25 Jun 2003 23:40:41 +0100 (BST) X-Authentication-Warning: tenso.ireland.sun.com: tg127171 set sender to Tony.Graham@Sun.COM using -f From: Tony Graham MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16122.9449.263238.517090@tenso.ireland.sun.com> Date: Wed, 25 Jun 2003 23:40:41 +0100 To: gtk-i18n-list@gnome.org Subject: Re: PangoPDF 1.2.3.0 released In-Reply-To: <1056554525.14257.195.camel@poincare.devel.redhat.com> References: <16112.33869.254511.67633@tenso.ireland.sun.com> <1056363575.13947.45.camel@localhost.localdomain> <16121.31640.237024.593290@tenso.ireland.sun.com> <1056554525.14257.195.camel@poincare.devel.redhat.com> X-Mailer: VM 7.07 under Emacs 20.7.2 Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Owen Taylor wrote at 25 Jun 2003 11:22:05 -0400: ... > While it's fine to experiment with a fork of Pango, I'd really > strongly encourage you to try to get API additions into the > main Pango. Pango really isn't a big enough of a project > to need two competing versions, and there are some definately > potential problems with what you are doing. I don't want to fork Pango, and, as Matthis Clasen posted, the goal of PangoPDF is to make itself obsolete. > For example, if you modify libgnomeprint-2.2.1.2 as you > describe then you'll link against *both* Pango and PangoPDF > when you have an app that uses GTK+ and uses libgnomeprint. > And the effects of that will be unpredicatable and probably > bad. I know that. I still don't have a good solution to the fact that PangoPDF's GNOME Print backend depends on GNOME Print which depends on Pango. The effect of that will be unpredictable and probably bad too. As such, I don't think that part's ready to come into the fold. > But why is pango_attr_type_register() so hard to use? I don't > really understand the problem. Sure, it's a few more lines of > code, but that doesn't quite seem worth maintaining a fork. That's not why I'm maintaining a fork. I talked about pango_attr_type_register() when explaining what I would do if I were to add extra attributes to the FT2 and Xft backends. I am interested in seeing the fruits of what you wrote about in the "Merging code between Xft and FT2 shapers" thread on April 14 since that would make it easier to add FreeType-using backends to Pango. I will submit some enhancement requests. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 From stephan.hegel@gmx.de Fri Jun 27 08:28:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id 02E8B18100 for ; Fri, 27 Jun 2003 08:28:30 -0400 (EDT) Received: (qmail 12482 invoked by uid 65534); 27 Jun 2003 12:28:18 -0000 Received: from unknown (EHLO gmx.de) (61.155.125.80) by mail.gmx.net (mp023) with SMTP; 27 Jun 2003 14:28:18 +0200 Message-ID: <3EFC3811.2090705@gmx.de> Date: Fri, 27 Jun 2003 20:26:57 +0800 From: Stephan Hegel Reply-To: stephan.hegel@gmx.de Organization: Private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en, de, zh-CN MIME-Version: 1.0 To: gtk-i18n-list@gnome.org Subject: Unexpected font rendering with pango Content-Type: multipart/mixed; boundary="------------010503000008060104000107" Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------010503000008060104000107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Recently I have found an unusual behaviour in Chinese font rendering with Pango.Please have a look at the attached, little screenshots. The only difference between both is the setting of the locale before starting the application. The first one uses LC_ALL=en_US and the second one LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing antialiasing - fine on the second pix, but not o.k. in the first case. It somehow uses a different size of fonts in just one string ... Anyone out there who has an idea or a hint how to track this and/or to fix this ? The application used in this case is called "lingoteach" and available on freshmeat. However, I have noticed that stardict behaves in the same strange way ... Kind regards, Stephan. --------------010503000008060104000107 Content-Type: image/png; name="en_US.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="en_US.png" iVBORw0KGgoAAAANSUhEUgAAAT4AAAFSCAIAAADkbCRGAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wYbCS03x2AlcAAAIABJREFUeJzt3XtwHNWB LvDTM6PRzEiyZMmyJfAzloRjrXB4+0IuZHfByZoK2ZuLy+xWkVRgNxvX3RTEhhgbYuOX/MQG wiPs5W6y2Vs32aQCLBCyobzEBrN+CD9Hkq2HkY2MJVsaPSxpZrrnce4fx+kc9XS3uud95O9X Lld3z+nTZ1r9zTnd82jJ7/c3NDT4/X5CSENDAyGETQPkv4aGhk/8nbluRW5ILKhlZWWRSESW 5VgsRgiRJElRlGg0Go/HKaXqbCwWGx4evnLlyr333mur/MMPP8zKU0r12yFJ6nQkElGno9Go Oh2Px9Vpvh5+XUVRJlzO18/an1gnT5ZlddrhcOi2x+40vy2j5alM8+wuN5Ku52W0zzMxzTNa 7vF41OmioiJ12uv1sgmfz9fV1dXc3LxixYqMxsRWeRdrnKIoIyMjgUCAHdaU0kgkEovFWBXq rCzLn332WWdn5913322r/PLly0dHRwcGBvjY8NHiWYmu0Z+EX5fHR5ev0+gw4rfF12k3upmO aCaia7Sc31f59nyt7AejNhcWFqrTPp9PnVajW1hYePz48QMHDjz66KMZjQlffvr06YQQRVF6 enp0y/8puoFAoLOzU5bleDzefaG77UxbYOCyx+OZdf2cquuqfN6iaDQqy3JHR0d3dzcrv2bN mp6eHlZDaWmpOuF0Otk2qqurJUnq7u6ORCKDg4Nnz57lezCj3c0fInYPFz5mfBm+HqNe18oh yLN7aObqULbykmf30M/n52s3umpENdNqjAsKCk6fPt3R0cEO+6VLl8qy7HQ6KyoqKioqIpFI RUWF0+l0OBxut3vBggXl5eXNzc1qTJqONo0MjUqSVFZWSiTCetF4PC7LyuBQwOGQXAUFn3Z2 qeVZDO+7775oNOp0Ol977bXh4WHW8cZiMTWGV6Mbi8VYTz06OvrOu+8cPnTI4ZLmVJTQmNL7 Wdvs2bNr6m71FhfJshwKhcLhMCs/MDBwzz33lPrcL77yqiNyZf/7vxvo6w30X77Uc7H19OnW lpZFX/va4cOHw+Ewe8FQFIXv/YyiZbSLjcpYWW40bWVAnrnpjRs3rlu3Tl2+adOmZ555Jrn2 bN++nXCefPJJ6+vu3r37Bz/4QRaeb+rTmfgbuVwu3Wn+JZ4duuywp5QODQ21tLQcO3ZsqP/S 5YufXbr4mRIaGx4aiF5R9r918Jnn/rmpqUmNSUdn+69/8xuf2zNv7ry/+tpSSmgsFguH5Zde erGsKD7nuuo7/vIBPlayLIfD4YGBgXfeeWdwcPCb3/zmz372s1gsFo/H2f/hcDgUCv2poWy/ vPPuO0cOH76+0rdgdpXHUxgbHRwKha50+S8Sufamr7LQq0/J5XItWlj7/RV/F4vK+997699/ 86ueC+cDl3uj0YgkkVKv86677vr4448jkYgkSZIkUUqt9JxW/lRWltsd0KaLrUNn06ZNTz/9 NJt+5plntmzZsnbt2iQ2unr16h07drAzIrbkiSeesL76888///jjjyexXYsy0YtmDTtu1cNm 3rx5L7/8cmdn5+EDf+jv6fa5JU+BVOiSCpySUyIlbumhhx56/fXX1ZiEQ/Lo8BWnd+RKv+/g wf+65ZZbZFl+/vk9bge9/XrPrLmVX5g713+yRS3PtjUwMHDu3LkDBw6Mjo4+8MADb775pppe FsOr0WW56r7QffjQ4esrvX+95M8X33FTV2trz4VPhwZ6QmNy+HLbyKU6R+kMWZZZFCmllZWV gUsXfvC/vtvT/Wnfxc9cUtzjkrxO4ixwSBKhlHi9XrU8O6RSeWVNV1xTGUBm9PDavHkzpXTL li1PP/30li1bCCFqjLdu3UoIWbNmzdatW5966ilCyLZt29hDq1evZhNqT/vkk09SSnfu3Kku 3LVrF3to1apVbOK5554jhKxcuVLd+p49ewghfPdr8fnmW+SMrqHwy/m28dcvjKbZxSF22FdX V3d1dX39619fvnx5eXl5SUmJz+erqKjwer3qKnxMKsqmTZ1SNt0dnuHsjfQV/Ncbh3v7h+tK pNq5hTV1Nz/4j9uO+k/x5dkrRUFBQTweD4VCBw8elCTpgQceePvtt4PBYDweZ2Nml7olRVGO HT3qkMi8WdWL77h5+T+sPfKrnR/s/dwT8YVJOBQNR/r8s76wkI3UWfk777xz5qxZC2/57+wq 17lz58rLy+fPnz9z5szh4eGpU6eyzcTjcTZaZuN1dXekcqnDbkStXNXMB42NjVu2bGHpbWxs pJSuXbu2sbFxzZo127ZtY63dvn07pfSpp55ig2RKqZpe1c6dO5944onnnnuOUrpq1apVq1bt 3r2bFV65cuXu3btXrly5Z88eSinLKqX08ccff+GFFyiljz32WNLtN4qNURmj/Z+u5Tyjl2yn 06lO8wNmNYeSJLF12WF/8ODBffv2/fSnPzU51+VjMnvOrP+57MEPPtg71TM4t+RSYTklM0vk CJGqFv79M699fOTIsaNH+fKsX2WnmR6PR5Kk06dP+3y+b3zjG2+99dbIyMi4XldRFFmWP/vs vMcllXrd51pbDv9q18UzR0udMimKBynxxDwkPlxXN/+3/xGnlLLyZWVlgUDg8uXLwWDw2LFj haNdM6aVU/r1lpaWsbGxWCzGXiTUE13WPt1dmelpsbCDm/WuW7dubWxs3LZt2+rVq5966im1 s92+ffsPf/hDdsju2LGD9bTsITaxa9cu1tnu3r171apV6qN79uzZvXv3nj17Vq5cuWrVquef f37Pnj1siyzGL774ou7gOdMxs7LcSkTtlikoKFCn+ejykZYkyeFwsMOeUtp+qukLCxqio93K YO/+37199ow/pgSHB/ocJD7QerL+H156//331ZhEIpHrr5v5lbv/ovfwOzNKFK9HIoSEw2TB 0mWHP2k6cvggGyHz5dlsQUGBz+fzer1ut7u3t/fQoUOFhYVDQ0Os/NWGsi640FM4xU1jo0MX u8/+Ye/FMmdYksOlrnChh9AYkSm9obaWxY+VZy8PQ0ND+/fvn10U/Pb9t1ZVlL55YG+8+jb1 9ICVZ+ff/AmDyZ8kn89jjaS9J3/66ac19fDjN8bpdKplNNNkfOe2a9cu9WSYX52MH2arD/FH sCpXkUtlf1pZd8LoskEs+WNM5s2bd+TgRz9/bXfg4rkLn55xE6W40FHkdngKJLdLKnaThx56 aOfOnZqYTJ069UQgULRwyorH/4oQ8urz70kxx6lmPx8TvjwhxOv1TpkyxefzVVdXV1ZW9vf3 V1VV9fT0sJIuvnG33HxrkxwYDAWnDvZ6ol5STEudskSk0jKPPEYX3/NAb19fLBZTFIWVj8Vi AwMDBw4cqCunL617fPo939u7fdl0uXO0n4xU3Er+eIbAriqzMIseV6MBYWKuGCuHL//qblKh 0+nctGmTZokmrox6/K1du5aNvQkhO3bs0FwAc7lcjY2N6kK+Bt0mZaLHsyLTlxL56OruBBak WCzGDvvq6up9Ta1Lly7z+XxG57qamMhy+JWXX1pURoMh+uoL7xV6yoIh0nam7YYFX/KfahkL BjTl4/H42NhYUVHRtGnTZs2aNXXq1JKSkrNnzzY3N0+bNo3Fatxlqqqqqjmz5w53+cNjcpiE Q5QWehxlZYUPf+fu373Rctu3NzVuf1lRFPV8OhAI/P73v79hmmPVdx6svOsr5954xn+8yUFj 5aEOX8gz5cb/cerUKVbe4XAkXqbKxFv5RlI5B0ulV5lwuTqxceNGvgB/DG3YsIEVe/bZZ599 9lk2oa64fv16Mj7GDodDfc9p3bp1jY2NDoeDzf7oRz+ilLL/2SwbkBPjU74Jn4uRTPeW6arH aJCs5lC9rssOeyvnunxMFCXy8qsvTy+Q517nVWYsXvClRcP9fUq8teDMr+UC+hdfWfL2u+/y 5dXLVKWlpfX19dddd90NN9zw+uuvt7S01NTUsJYoiuIihDQ0NHzwwQfRaNTj8dbU3XKRyOHL baFo2BPzkBgNj9Hfvd3y1e82njjV0dbepg76o9Hom2++Oas48nfLHrxj+bL2t/7fsUMfReSg u8BVUuKpdne7w8cWPfydjz76yOFwsNcJkwFzKjG2e0XRSkSzcylly5Yt/Bu57FhhXatmeuPG jSyiLLr8EkLIhg0bWP1sgh1/GzZsUHPOzzqdzs2bNzudTlZ4/fr1bDk7gvlpk+eSimyeyFhh 9L4uP2B2uVwul4sd9pTSS22HKmtujV3+5PKZk6MDPcHBXmd0rOvTs2G5PxbdK9VveOONN9SY 9AV6Z011LJjiu/mev/7HLf/07jvv9SsXpt99m3z0V/GO38758pf/9m+WHzp8SC2vhrOkpKS0 tHTRokXr168/f/58XV2dGiJJkv50rsvW8RYX1960ZORSrdzXLCu94aijat6iJWteONna//r/ +Rnb6ZRSVt7pdFZNiV+8+PnP168PDV26eK69uNDhcDqKiz3LH1r8b788ULH0Cb68yRVmnpXe NV1xtRtjK+20si0Vu4yszrL3hNj//JK1a9euW7dOnWVH1ebNmxMrZAtZnZoBtjrLJvhH+WlN /59RVvZzJvDbMjpT4KPrcDhYDxSNRufNmxccG9v3by/+/H//2OuIlBRQVzxY6nUUul3Tp5f+ zd/+N3LnQ5s2bVIP+4qpU++546bpJZ4V619577e//8P+ffF4/PrrZi759mba+e4Xv3znqdbL hIsJyyebdbvdjzzySH9//+LFi9X3ddlO+1N0w+Gwem3aXT6zqnZh3fz5DV/8s76Bwa3P/d+z Zz9lV8BYAVb+xhtvnDl37tiMWZ6KiqKCgi8tKYpEImVlZZTSD6PeG1es9nq96sVu1iz+01T8 n83KJ6JSGTCnMvBOpWdOBV/npk2bWHQJIRs3bkz64rndFe1Gy+5Lod2TFP4SgJX6rVyD4I8x 3bapV4DZYV9dXb3llV8sXbr0odWvGp3r8jEpnzpj7l8u93l9//qLXxw9epSNh9s72kpKim+7 5aunWi9HlDhfnsXwwoULoVDokUceqa6uvuuuu0KhkBppFkMXIcTv9x87dqyjo+PcuXPss8cs YP/5n/vVvltt0JUrVyKRSF9fX0dHRzweb2tra21tVQsYld+/f397e/uFCxfC4bC6a+x+aNGI 3RjzMtHzG7EyUjBx7733sokPP/zQ1nZ5dl+e7I50jKLF/x2NPvZg1B7+b8QPaFOpn8evq9vr xuPx7u7uWCzGDvvi4uLu7u5XXnllwsOeldfESi3f3Nz8Lz83LO9yuT7++GO32z1jxoy2trbE +q/uiJMnT544cWJkZIR9zlE9Y2afpuBn2ftOdsv/8pe/7OnpGRwcDAaDursvlR7VqJ50Lbfb e9iNaCYGirl6vkbfrDKKh1G0jNblrwZnon6jddlbm5mOCV++q6srEolMmTKlu7tbt7ykfsm+ s71F90kCQB4a9x7A/NqFuWoHAFgkSVJne4v27buzHa05aQ0AWPHhvr1sYuKTeADIQ4gugJAQ XQAhIboAQkJ0AYRkNbo1dfXqP1urJNuwLEnieakrplg46U0n3YwcboWvIbna8v9YyrKr3xyy UlT9zEZNXf2En9+wUibnNI3Mfptt7VIAXvIDZvYqqL4W8r1Hig9pXqGtz6aID5J5w2w9C01h o02b1KaZ1n3WVtqszprsxuTab469MGlq0G1D4hPnt46Ol6fzjWoj6o5L7Cs0E+zvpPuQrQlb s+nZH+NrS8sT5Atb37rRKroFrLSZ/PEPN+FuTKX9Fhm1weiJZ6INorv6zSErY2bdHapOm7wi ah4yWcvob8P/XfmFbDYLf1HzTVh8FhYlPsfEg9tKPdabkd72J1auvnBoXkQgFTZ6XXMmf4zk HrJSPhO9bhLSu/UJa0v7k8303sNANxPS/OaQ9b7X4kO6BTJ05pNihamfDerWZjRWtLvTrLTB VnmLdbIht/oPZ63pkp5e12TsmtxDugXMZ1NptjqrWTjhOJk/HK0UTlyo2ZDdfZL4RKxXZatY eoc2Rn9K3SUZaoPoxn1fd37tQnxzaHLAUT5Zfbhv7yPffawz8Ut/unSHN6IfGUZjNtGfV17B Ts4cS9GdlDt6Uj4pVZ48uzxpxqSEzzADCAnRBRCSdsCs/nwGAOSzcdHN5s/PA0Aqxn1zCBcV AESBc10AIaXtM8z5QPTfkcbnYcA6G98cynOT4KNg+AgUWKftdUtLp+akHcCu7Wd//w8PD2Z5 i5AW46JbWjr1+Ccf56opKbpv6YO5bkIaZH//L7l/Gbp6EeEy1TXtk6bDuW4CJAnRBRASogsg JEQXQEiTPLq6v7RgUixxgnC/M6r7qPVNA6SRpY9kLLl/mTr9/m9/bWsDS+5fZneV9EritxSJ 8Y+bW3/rNS2Xbfk9TxJ2Ptu36h7O+a6GbJo4upoDYnIcH0a/ZqwuMYpo4i/RJr4uJP6acWIx 68GecG9Pgj8HJCHJATPrDZbcv4zvFjSzmvLqQ4kTmmKaAta3oov/FcIJf2CNWA6V5jfl+J8+ 1Ay2dYulMpxO3CGa/4nxnkx6o5BvbNxzSEMzTjMZtlkc0fGPJq6Sb4PDpH9B2m5oNWcr/B7g ixntnPzZY5BeyX/9IPE4MHpR1z1iLB5J1rdiIq9ue2G3GUZ7iWU19XpAUOn85lB2Do78ueiV yor581ICgnIQQthPMaeL7hksP2u3u7C4FVtYP2z+RpGmJPtn/svmiWXU5fwvg6cltzhxvcZN 3Otqkjbh+C2xgO5DJsWS24ou/lYARhPWH9VdoruKleUWaXY+vwd0XyX5MiTXgxTInHF3P8ja N4cyccnkvqUPCv19Xfar9llO2idNh9c+uwtDdxHl4NNUuNQJkLocRBe5BUjdJP8MM8BkhegC CEl7k85ctyd5Ql+jUgn9J4DskCRJ5yadkyMA4sL+B4swYAYQiXpXMEQXQEgOkuw3hwAgh9Dr AggJ0QUQUvq/OQQAWYBeF0BIiC6AkBBdACEhugBCQnQBhIToAggJ0QUQEqILICREF0BIiC6A kBBdACEhugBCQnQBhJTO24VBNigKCQZJWJbCYaIoRFFIJEqiERKNkXic0DihlFBKJIlIEpEc xOEgLidxFZACF3G7idtNPR7iKSQ+H3G7c/1kIHmIbt4LBqXhYXJlhIyOkrExq2uxAJM4iRES IYSE1EckvlhRESkuJlNKaGkp8fnS12jIOEQ3LwVDUiBABgbI8HBmNzQ2RsbGyKVLV/NcWkrK y2lFBfF5M7tdSBmim09GRqXeXnK5j8SiuWnA8DAZHpa6uojTRaZX0qoqUlKcm5bARBDdPBCL SRc+J59/TqI5SmyiWJT09Eg9PcTlItdfT2deT5zOXLcJxkF0c2psTDp3ngQCuW6HsWiUnD8v nT9PKiro3DmkqCjXDYKrEN0cGRuTOs9m/FQ2jQIBKRAgpaW0Zj4CnA8Q3ayLx6W2dtLXl+t2 JGV4WDp6jFRW0hvqiAMfCsglRDe7enqljo5cNyJlfX1SXx+trSXVVbluyrUL0c0eqaU1r09r bZI6OsjAAK3HrQlzA2OerAiHpUNHJlNurwoEpENHSDic63ZcixDdzBsdlY40EUXOdTsyQ5Gl I01kdDTX7bjmILoZFgxJx47nuhEZJx07ToKhictB+iC6mUSpdM3cFEby+wmluW7FNQTRzSDp TBuRkxknf2/F9ydckro01ynL0pm2dFYIpnCFOWP6A6m8efu9Fd//yas/Vqc1S5Kr0HwradDX RyorybSKtFUIxtDrZop0/nx6K7SbMT6rfER/8uqP+el0NY9J+7MGI+h1M2NoyMZ3a8djkdN0 uXzGrHeVmvTabQPPasjHxsjQECkrs74tSA6imxFSf0pv4SbmRJMl6+n9yas/VsNvMb26lVvf otQfoIhu5mHAnBlXriS3nnpay8+yzGR0oJtOyT53sAXRzYxQGj5gxDo6zciZJOQ2xQvFRpev kq8xHc8dJoQBc2Yk9TMXLKuaiGpGqib9LZ83i8V0r12nMlomJMnnDnYhupnhdCVxBBvFgx8/ a65X8ROJ/fOEm0i8Bqa7dXvjcycOqmzAgDkzvJ60VKMJoeZSk3oOTMbn1ihpSZwhJ/PGb5qe O5hDdDNjypQ0Vpbek9s0VqIvrc8djLgIIQ0NDbluxmRDp1VIFy+mWInuaJZ1vEbv36gTiYPn 5D5cmURHTfFpqqzAaUlmlJWRoqKkP5VBJhqp8u8SqSUTL2vpXujSbCXpFuorKsLnMbIDA+ZM oXPmpLK6ldyqdBOYkzeBU3zWYJ2LEOL3+zFmTr9pFaSyMvWfjzPvGDXvJ1nvRY3eJU4sYyP5 +O5BFqHXzSC64AZSWJjEipp3WTXXkBNL6n61wMom0tkhFxbSBTekrTaYiOT3+wkhDQ0Nne0t 82sXnu1ozXWTJpdgSPrkk1w3IhvorbfiTkVZ8OG+vY9897HO9hb0uhnm89Kbb8p1IzKO3nwT cptliG7mFRfT228j7mRGzgJwF9LbbyPFuKtYtiG6WeHx0MW3k4pJdwmnooIuvp148PGpHEB0 s4fWL6S1tbluRdrQ2lr8fnoO4SMZ2VVdRWdMF/ieQwzuOZQHEN2sczjoFxeQ2bMEu9Mfgzv9 5Q1EN0eKiuiiGwW4v64K99fNM4huThUV0fqF+XhXexXuap+v8M2hPOB00jmzyZzZZGRU6u0l l/ty/0MTTheZXkmrqkgJ3vXJU+h180lJMS2pIbU1JBiSAgEyMJDtk+HSUlJeTisq8PmK/Ifo 5iWfl/pmklkzCSEkGJSGh8mVETI6msq3CPUVFZHiYjKlhJaWEp8vzZVDJuGbQ3nP56M+H6mu vjqrKCQYJGFZCoeJohBFIZEoiUZINEbicULjhFJCKZEkIklEchCHg7icxFVAClzE7SZuN/V4 iKeQ+HzE7c7pE4OUoNcVjdvNIoeb6l3j8K46gJAQXQAhIboAQkJ0AYSE6AIICdEFEBKiCyAk RBdASIgugJAcBN8cAhAQel0AISG6AEJyEELYDRAAQCDodQGEhOgCCAnRBRASogsgJJ1fyZhf i7tRAOQjSZL++Z9eYNP6P3CDu+wC5JsP9+3lZzFgBhASogsgJEQXQEiILoCQ8M0hACFZ7XVr 6uqtF+P/t1ibxfrTi99oTV19TtoAkJw03/2gs70lyyumRU1dfW4bAGBXkt8cUjsozYR5x6Xp 2RK76MRHE9fiF6prGbVHd6Oa2qy0HCDfZO+eQ2rPpgmSeXfHr6UpqVmuW5XmUd3C/HIAUSR5 hZkd7uqsrUOfL5mYRrUPVB9K4ixUXZ1VmGJtAHlIgDv9pdgfarpZ9K4wOST/vq46zrQ72jTv 9IwqtNhVJg4HkmgDQP7LXq+rhkqTLutr2dqW7urJ1QaQh6xGV/dYTxyC8ksSV+ETpbui7rZM Nq07Yd5y3Q0hySCcyfZBSFwrhmvEZIsucgvXiMkWXYBrBKILICQX0fvmkOanNAAg3+hcYZYk KfvtAABbdKKLKz0AeUsdEeOeQwBCwmUqACEhugBCQnQBhIQblwAIAzcuARAPblwCMBkgugBC QnQBhIToAggJ0QUQktV7Dqk/WZ6JH2rDj7wB2GXjZ+X4nzJO71cU8IUHALtSGjBPeEsRwt0W RPfuIbr/m5QEAMZFCPH7/RbHzGzC5I4hutMmdw9J3ITFkgDXOBu9bmd7C/tnfiMv3RUtLrde EuAal9JPqCNRALmShjeHkh7NWl8RA2YADRu9ruZcV/cmIPxw2mT0a/EOJsnd6wTgWpCGG5do ppO4UYjJfUwwJgfQlZubdE7YMydREuCakpvoJncfbQBQ4TPMAEJCdAGEpD9gxo1LAPKczj2H cOMSgPyHG5cAiGTcjUsAQDi45xCAkNDrAggJ0QUQEm5cAiAM3LgEQDy4cQnAZIDoAggJ0QUQ EqILICREF0BIiC6AkKzecwgA8gp6XQAhIboAQsI3hwCEhF4XQEiILoCQEF0AISG6AEJCdAGE hOgCCAnRBRASogsgJNy4BEBIOtHFjUsA8h9uXAIgEty4BEBsiC6AkBBdACEhugBCwo1LAISB G5cAiAc3LgGYDBBdACEhugBCQnQBhIToAgjJanRr6upNZvNQTV19/jcSIGmTs9etqavvbG/p bG9BemGySjW6rHNTE2IyYVKen00Mm26d5hvFl59g0tP/SIYu3VCpIeGnTSSWN5kwaobFjVps EoCIbESXj4HRQJSNUc2jpVnXSrVGVZlAbmFysxHdtOC71sRHETYAi9J/mUrteJPu9xK75SSu NuFVACa3lHpdPlQWo6KukhhI/iHdFY02qpttDJhhcrMaXU0M+CAZFTZKjsm61vOfxBKAyUSA 93XRfwIkEiC6yC1AIgGiCwCJEF0AIeHGJQBCwo1LAISEG5cAiGTcjUsaGhpy2hgAsA2XqQCE hOgCCMlBCPH7/bluBgDYg14XQEiILoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiI LoCQ8M0hACGh1wUQEqILICR8cwhASOh1AYSE6AIICdEFEBKiCyAkRBdASIgugJAQXQAh6dz9 YH7twuy3I5EkSZTSrG0L93wAsejfLuxsR2uW26Gh3p0hCy3BvdFARBgwAwgJ3xwCEBJ6XQAh IboAQsI3hwCEZKnXramrr6mr52etrDLhkuSwxqSrNgBB6b85lLdq6urVN2D5aYBrjdVz3c72 Ft2OdMIOMLEAvySVLpTllq+Kn9DUzC9MYlsA+Sb5XtdKB6gu5yOkLulsb7HbhfKvIOblE2tO nAAQl43ostgkd9DzkUvshO1Wpa7Iwm/0IqKpGXGFySQH57p8hBK7ZXPWXzvs1gwgFnvv6+qe 8VqRuQvOhBsOmAcbGYbJJPle18ppp1pGdyJx+YQ9qq1zXfNNAwjNUnT5Y91o2mgVkwnz5VYa o1loUjNCC5NMRs51LXaMSVfLQxrh2uQiGfjmUIYME65jAAADGUlEQVTilEq1SDhMMvj6AYCQ EF0AIbkIIX6/XzNmzp/ffMmflgDkFZ3LVJIkZb8duvKnJQD5Rie6uKIDkP9wrgsgJEQXQEiI LoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiILoCQEF0AISG6AEJCdAGEhOgCCAnR BRASogsgJEQXQEiILoCQEF0AISG6AEJCdAGEhOgCCAnRBRASogsgJEQXQEiILoCQEF0AISG6 AEJCdAGEpL1JJ25FDSCEcdHFragBRDEuurgpNoAocK4LIKSrvW53d3ckEpFlORaLRSIRRVEI IcFgcGBg4MqVKw8//DB7lFJqUpdmvB2JRPjZaDTKz8bjcX5WU7OmKtYei49qthuLxUw2xJNl mZ91OMa9rmkanMqspg3mj6Zx1uJDEz5qLnO7gv9TZm4vWd+HEz7q8Xj42aKiIn7W6/Wq0z6f r6urq7m5ecWKFSZJvPfee9mjra2tV6OrKMrIyEggEGClFUWhlIbD4Y6Ojs7OzuXLl4+Ojg4M DGhSYX5ubCu6Gpo9oqlKQxNdzYbMo8s3Q7OVVKKbq3BmJ7rmj2p2eIZ2VD7sw8QGa2YLCwv5 WZ/Px8/y0S0sLDx+/PiBAwceffRRkyTefffd7NGTJ0+6CCENDQ2nT58OBAKdnZ2hUCgajSqK EovFZFlubm7u7u6ORqP9/f1nzpwJhULW223+J7T1aCqz1g+OXB0N2ZnN3FZy8sKUn92s5lE+ nImzfJIdDkdTU9OJEycURTFJovroqVOnrva6R44caWpqOnfuXDgcZqVZSi9cuDA6Ojo2NjY4 OBgMBjX9W9bCaWvnmtP0pSZHg0bm/sCZezTpXjdrhdO4bibqSbHmgoICi7PRaDQSiUSjUfMk qo8eOXLkanRPnjx54sSJkZERlvVYLBYMBgkhoVAoEol861vf6unpYem1/qzSmLfsHOvmDdac HZjPaqTyaLpk7hUhlR1lflaieQV3Op1GK2qY16OJkPWNprhd86rY+Zp5EtVHg8Gg5Pf7CSEN DQ2EEHWaTQDkuYaGhsx1sHnu/wPur6N3B7/qtwAAAABJRU5ErkJggg== --------------010503000008060104000107 Content-Type: image/png; name="zh_CN.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="zh_CN.png" iVBORw0KGgoAAAANSUhEUgAAAT0AAAFPCAIAAACwE44AAAAABmJLR0QA/wD/AP+gvaeTAAAA CXBIWXMAAAsSAAALEgHS3X78AAAAB3RJTUUH0wYbCSwoU3MZxAAAIABJREFUeJzt3Xt0HNWB JvBb3S31Q2/JsiXbAhvLwrEDJIEsLGQhOwNOxpyQ2Sw+ZuYc4MTMMMPZ2QOxIcaG2NiyZRsb G1geh4zzYjabTHICLBCy4XgSG8z4hY0fkrAlGcluIcmW1Hp3d3V39d0/rqe4ru6qru6uftzW 9zs+PvW4VXW7VF/dW9WPks6dOzcxMTE8PBwOhwkhlNJwOKwoiqIo/KgsyxcuXOjq6mpubk6q /J49eyYnJ30+HyvPSJJE4uHLRCIRdTgajcYtTymNuywvFArFXSercOx6+G3x67TZbHHL6A3r rZOfnolhnlXT+X2Vb6/XzH7Qq7PT6VSHPR6POux2u9UCn3zyyYEDB375y19mNCZ8+ZkzZxJC QqFQf3+/XnlHKBQaHh7u6uqSZTkajXp7vWfPnB32XXK5XA1zrq6bXedxl0QiEVmWOzs7vV4v K7927dr+/n722ioqKtQBu93ONlBfXy9JktfrDYfDIyMj586dk2U54b7mj49kjxU+Y3wZfj18 Gb316x1/vGSPy1wdx2bOd8ke9/n8epPNrZpPzbCa4aKiok8//bSzs5Md9suWLZNl2W6319TU 1NTUhMPhmpoau91us9mKi4sXLVpUXV3d2tqqxuTosaMTo5OSJFVWVhCJRCKRaDQajUZlOTQy OmyzSY6ios+6utXyLIZ33XVXJBKx2+2vvfba2NhYNBqllCqKwsfQoShKOByWZXlycvKdd985 fOiQzSFdXVNGldDAhbNXXXVVY9NN7tISWZYDgUAwGGTlfT7fHXfcUeEpfvGVV23h8f3v/8E3 ODA8dOlif1/7p5+2t7Xd8O1vHz58OBgMslNFKBTi2z29XOntX70yZqbrDeu159k5tjZt2rR+ /Xp1enNz89NPP51afbZv3044TzzxhPlld+3a9YMf/CALrzf94Uz8jRwOR9xh/vzODl122FNK R0dH29rajh8/Pjp08VLfhYt9F0KBqbFRX2Q8tP+tg08/99OjR4+qMens6vjt737nKXbNnzf/ r769jBKqKEowKL/00ouVJdGrZ9ff/Jf38LGSZTkYDPp8vnfeeWdkZOR73/vez3/+c0VRotEo +z8YDLLyDnWnvPPuO0cOH55T61l0VZ3L5VQmR0YDgfHu031EXvjVb7G4q6/H4XDcsHjh/3zk 75SIvP+9t/7v737T33t++NJAJBKWJFLhtt92220fffRROByWJEmSJEqpmTbTzN/JzPRk+7FW Seq4aW5ufuqpp9jw008/vWXLlnXr1qWw0TVr1jz77LOUUvXq4/HHHze/+PPPP//YY4+lsF2T MtF+Zg07btXDZv78+S+//HJXV9fhA38e6vd6iiVXkeR0SEV2yS6RsmLpvvvu27NnjxqTYECe HBu3uyfGhzwHD/77jTfeKMvy88/vLrbR/zTH1TCv9pp5806fbFPLs235fL6enp4DBw5MTk7e c889b775phpdNYYOFipvr/fwocNzat1/vfS/3nLzV7vb2/t7Pxv19Qem5OClsxMXm2wVs2RZ ZjmklNbW1g5f7P3B/3i43/vZYN8FhxR1OSS3ndiLbJJEKCVut1stz46ndM6pVmU1nX5jRo+t zZs3U0q3bNny1FNPbdmyhRCiZnjr1q2EkLVr127duvXJJ58khGzbto3NWrNmDRtQ29gnnniC Urpjxw514s6dO9ms1atXs4HnnnuOELJq1Sp167t37yaE8A2vydebb3nTu2/CT+frxt+z0BuO RCKKorDDvr6+vru7+zvf+c6KFSuqq6vLyso8Hk9NTY3b7VYX4WNSUzmjqrxyZnFwln0gPFj0 728cHhgaayqTFs5zNjZ97d5/2nbs9Cm+PDtNFBUVRaPRQCBw8OBBSZLuueeet99+2+/3R6NR 1lUOh8MOWZZDodDxY8dsEpnfUH/LzV9b8Q/rjvxmx5/2fu4Ke4IkGIgEw4OnG65ZzHrnrPyt t946t6Fh8Y3/JRQKTUxM9PT0VFdXL1iwYO7cuWNjY1VVVWwb0WiUdZJZH13dF+nc20g2n3r3 n3J+LtdoaWnZsmULi25LSwuldN26dS0tLWvXrt22bRur7fbt2ymlTz75JOsbU0rV6Kp27Njx +OOPP/fcc5TS1atXr169eteuXazwqlWrdu3atWrVqt27d1NKWVAppY899tgLL7xAKX300UdT rr9eZvTK6O1/q6bz9M7XdrtdHeb7yWoIJUliy7LD/uDBg/v27fvZz35mcH3Lx+Sqqxv++/J7 //SnvVWukXllF53VlMwtk8NEqlv890+/9tGRI8ePHePLsxaVXV26XC5Jkj799FOPx/Pd7373 rbfempiYYO1tNBp1hEIhWZYvXDjvckgV7uKe9rbDv9nZd+ZYhV0mJVE/JS7FRaJjTU0Lfv// opRSVr6ysnJ4ePjSpUt+v//48ePOye5ZM6op/U5bW9vU1JSiKOz0oF7cso3F3Y+ZHhYLO7JZ u7p169aWlpZt27atWbPmySefVJvZ7du3//CHP2TH67PPPsvaWDaLDezcuZM1s7t27Vq9erU6 d/fu3bt27dq9e/eqVatWr179/PPP7969m22RZfjFF1+M22fOdMbMTDeTz2TLFBUVqcN8bvk8 S5Jks9nYYU8p7Th19JpF10UmvaGRgf1/ePvcmdNKyD/mG7SRqK/95JJ/eOn9999XYxIOh+fM nvvN2/9i4PA7s8pCbpdECAkGyaJlyw9/fPTI4YOsY8yXZ6NFRUUej8ftdhcXFw8MDBw6dMjp dI6OjqrlHazldbqc5cVUmRzt8577896+SntQkoMVjqDTRahCZEqvXbiQZY+VZyeG0dHR/fv3 X1Xif/Dum+pqKt48sDda/3X1koCVZxfc/EWCwd8jn69d9Vjehj/11FOa9fDdNsZut6tlNMPk ymZt586d6gUwvzi5snetzuIPX1Wu8pbO/jSzbMLcsr4rIYQd9vPnzz9y8MPXX9s13NfT+9mZ YhIqddpKim2uIqnYIZUWk/vuu2/Hjh2amFRVVZ0YHi5ZXP7IY39FCHn1+fckxXaq9TQfE748 IcTtdpeXl3s8nvr6+tra2qGhobq6uv7+frW8g9Xsxq/ddFQeHgn4q0YGXBE3KaUVdlkiUkWl S56it9xxz8DgoKIooVCIlVcUxefzHThwoKmavrT+sZl3/OPe7ctnyl2TQ2Si5ibyH1cF7B4y S7LoWdXrB8aGijFz7PLndYMV2u325uZmzRRNVhn14Fu3bh3rchNCnn32Wc0dL4fD0dLSok7k 1xC3Splo68zI9L1DPrdxdwJLkaIo7LCvr6/fd7R92bLlHo9H7/pWExNZDr7y8ks3VFJ/gL76 wntOV6U/QM6eOXvtoq+cPtU25R/WlI9Go1NTUyUlJTNmzGhoaKiqqiorKzt37lxra+uMGTPU WF2+L1VXV3f1VfPGuk8Hp+QgCQYodbpslZXO+79/+x/eaPv6g80t218OhULqBfTw8PAf//jH a2fYVn//3trbvtnzxtOnPzlqo0p1oNMTcJVf/99OnTrFyttsttj7Upl4v15POtdd6bQnCaer A5s2beIL8AfQxo0bWbFnnnnmmWeeYQPqghs2bCBXZthms6lvL61fv76lpcVms7HRH/3oR5RS 9j8bZf1won+Zl/C16Ml0O2nVevT6xmoI1bu47LA3c33LxyQUCr/86sszi+R5s92hWbcs+soN Y0ODoWh70ZnfykX0L7659O133+XLq/elKioqlixZMnv27GuvvXbPnj1tbW2NjY2sJqy8g118 ulzuxqYb+4gcvHQ2EAm6FBdRaHCK/uHttm893HLiVOfZjrNqRz8Sibz55psNpeG/W37vzSuW d7z1f44f+jAs+4uLHGVlrvpib3Hw+A33f//DDz+02WzsDGHQT04nw8nePzSTz+zcO9myZQv/ hi07UFijqhnetGkTyyfLLT+FELJx40a2fjbADr6NGzeqIedH7Xb75s2b7XY7K7xhwwY2nR2+ /LDBa0lHNq9fzNB7/5bvJzscDofjckwopRfPHqptvEm59PGlMycnff3+kQF7ZKr7s3NBeUiJ 7JWWbHzjjTfUmAwODzRU2RaVe752x1//05Yfv/vOe0Oh3pm3f10+9pto5++v/sY3/vZvVhw6 fEgtryazrKysoqLihhtu2LBhw/nz55uamtQQsRg6IpEIW8BdWrrwq0snLi6UB1vl0EAwYqub f8PStS+cbB/a85Ofsz1OKWXl7XZ7XXm0r+/z1zdsCIxe7OvpKHXabHZbaalrxX23/OuvD9Qs e5wvb3A/mWemXbUqq8lm2Ew9zWxLxW4aq6Ps7R/2Pz9l3bp169evV0fZIbV58+bYFbKJbJ2a frU6ygb4ufywpuXPKDP7ORP4beldIPC5tdlsrPmJRCLz58/3T03t+9cXX//n/+W2hcuKqCPq r3DbnMWOmTMr/uZv/zO59b7m5mb1sK+pqrrj5q/OLHM9suGV937/xz/v3xeNRufMnrv0wc20 690vfePWU+2XCBcTFk42WlxcvHLlyqGhoVtuuUV9/1aNoSMSiQSDQfU2dHH13LqFi5sWLLju S18e9I1sfe5/nzv3GaVU/dQIK3/99dfPnTdvalaDq6ampKjoK0tLwuFwZWUlpfSDiPv6R9a4 3W71vjarE/95Kf5vZuYzT+n0k9Ppb6fTJqeDX2dzczPLLSFk06ZNKd8qT3bBZHOV7Hkw2WsT /rLfzPrN3Hfgj7G4dVPv37LDvr6+fssrv1q2bNl9a17Vu77lY1JdNWveX67wuD3/8qtfHTt2 jHWDOzrPlpWVfv3Gb51qvxQORfnyLIa9vb2BQGDlypX19fW33XZbIBBQ86zG0DE4ONjZ2dnT 08M+V8zS9W//tl9tstXajI+Ph8NhVj4ajZ49e7a9vV0toFd+//79HR0dvb29wWBQ3S96+dQb 1pNshnmZaPP1mOkjGLjzzjvZwAcffJDUdnnJnpuS7ePo5Yr/O+p9tkGvPvzfiO/HprN+Hr9s 3PY2Go16vV5FUdhhX1pa6vV6X3nllYSHfdxYqeVbW1t/8bpueYfD8dFHHxUXF8+aNevs2bNx 1+84efLkiRMnJiYm2Oen1Etk9pEJfpS9v5Rs+V//+tf9/f0jIyN+vz/h3ymdHGbiWjTZdiPZ fGaif5ir16v3fSm9bOjlSm9Z/t5vJtavtyx7FzPTMeHLd3d3h8Ph8vJyr9erV14ihHR1tMV9 hQCQhxqbllzueyxYuDi3VQGAhCRJYq3sF9cM5zrbc1cfAEjgg3171eHE1+4AkG+QWwDxILcA 4kFuAcSD3AKIJ3FuG5uWqP9MrjSpwrmSwutSF0yzcMqbTrkaOdwKv4bU1pb/x1L2xfnSViz1 gxmNTUsSfkjDTJmc01Qy+3VOapcCaKTST2bnP/UsyLcbac7SnJvNj6aJT5FxxZJ6FZrCeps2 WJtmOO6rNlNnddRgN6ZWf2PsrKRZQ9w6xL5wfutocjVMtbfqXottJTQD7I8Ud1ZSA0mNWrUv +LVZ8gL5wua3rrdI3AJm6kz+4w+XcDemU3+T9Oqg98IzUYcCkFw/Oe4Ug3OhZpbBUnp/GP6P yk9ko1n4cxpvwuSrMCn2NcYe2WbWY74a1tY/duXqWUNzBoE0mcqtMYO/RGqzzJTPRHubAmu3 nnBtlr/YTO899G8zxLL3gcy3uiZnxS2QoaudNFeY/hVg3LXpdRGT3Wlm6pBUeZPrZD1t9R+u VC2Ubntr0GVNbVbcAsaj6VRbHdVMTNg95o9FM4VjJ2o2lOw+iX0h5leVVDFrOzV6f8q4UzJU hwJw+fu3CxYuxveBCgMO8UL1wb69Kx9+lJ3XErS3cXs1oh8Wel010V9XXsFOzqgEuS3IvVyQ L0qVJ68uT6pRqPD5ZADxILcA4vmin8z/CgYA5LPLuc3mD8YDQJou5xZ3EQAEgutbAPFY8Pnk fCD67z/jQy+QlELIbQF82AsfcoKkfJHbioqqHNZjOmN38rO//8fGRrK8RbDK5dxWVFR98vFH ua1Kyu5adm+uq2CB7O//pXcvRyMvKNyXmqY+Pno411WA1CG3AOJBbgHEg9wCiKdgcxv3NxMM isUOEO4nQuPONb9pAGsleP926d3L1eH3f//bpFa99O7lyS5irRR+CZHo/yK5+bdYLblJy+95 ErPz2b5V93DOdzVkmVFuNUdDYRwcer9CrE7Ry2fsj8jGnhRif4U4tpj5VCfc2wXw54DUJN1P Zu3A0ruX8w2CZlRTXp0VO6Appilgfitx8b8hmPAX0ojpRGl+FI7/4UJNHztusXR60bE7RPM/ 0d+TKW8U8lAqn3PUdM8MemsmO3L83NhF8q1PmPIvPyebWM1FCr8H+GJ6Oyd/9hhYLpXcxh4E eqfzuIeLycPI/FYM5NVTKpKtht5eYkFNfz0gLmu+V5CdIyN/7nKls2D+nEdAXFZ+H8ign8wk 21CY3EpSDK4wNYmK+9voxiuMu7hVv9WuwsUqGOVWE7OE3bbYAnFnGRRLbStx8T/erzdgfm7c KXEXMTPdJM3O5/dA3Bt7fBmS6+4JZNTl5xVk7ftAmbhHcteye4X+/i37Hfosx+zjo4fXPbMT PXYRNTYtyernpXBjE8ASWc0tQgtgiYL9fDJAAUNuAcTzxXM0c12T1Al9U0ol9J8AskOSJO1z NAvj6BcX9j+Yh34ygBj4J3ghtwDiQW4BxIPcAogHuQUQD3ILIB7kFkA8yC2AeJBbAPEgtwDi QW4BxIPcAogHuQUQD3ILIB7kFkA8yC2AeKz83XPILEUhwSCRZSKHpHCIhCMkHCaKQhSFKFES VQglhFJCKCESkSQiEWKzE7uN2O3EbidFRaTIQYuKibOYOJ3E5SJ2e65fEqQIuc1jfj+ZmpIm p0ggQAIBEo2aXpISSgklJBolkStmSPyIzUbcbuJ209ISUlJCPB5rqg2Zh9zmmfEJaWyMjI8T vz/j24pGydQUmZqShoYuT/F4SHk5ragg5WUZ3zqkAbnNA9EoGRqSfCNkYiLHNfH7id8vDQwQ QkhZGa2uIjNmEBtuguQd5DanBgelS4PZaFpTMDEhTUyQ8xeIx0Nn1pLa2lxXCL6A3OaC3y/1 DxCfL9f1MMfvl3rOk57zpLqa1tfhMjgfILfZNToq9X5OAoFc1yMlPp/k8xG3m86dQyorc12b aQ25zZaxMen8BSLLua5H2gIBqbOLOJ306qtIRUWuazNNIbeZFwxK3T1kcjLX9bCULEsdnaS0 lM6fR1yuXNdm2kFuM0vy9hJ2e7YgTU5Kp1tJXR1tmJvrqkwvyG3GBINSZxcJBnNdj8wbGJBG R+nCRjS8WYO35jJjeFg63TotQssEg9LpVjI8nOt6TBdob60n9fWRz/tyXYsckD7rJrJMZ8/O dUUKH9pbi0le7/QM7WWf90leb64rUfiQWytJn/eRgYu5rkWuDVyUpvOZKyuQW+sMDZM+HK+E EEL6+sgQrnUzCLm1SDAodXfnuhJ5ROrunka35bIOubWG1HM+11XIO9gnmYPcWsHnS/8reA88 +FDCKVbNTa1k0iYmhPnuhGjwPpAFJIvuRT3w4EOv/+In6rBmikH5uNmLu6z5kpaQBi7S6upM rHmaQ27TNjVFpqYytG6TcdIUY+FUI82fC17/xU80cw22EjfkySWc7ZySkiQWAROQ23RJI6Pp r0STn9g4aZpEg7zFXTbusPn68NOTbZylkVGK3FoN17dps+iLPnohYf+IfhdXM/r6L34Suyp1 ipnIGZwUDLrlugrsi1D5AblNWyDddzs0seRjw4dQzYymZGx006yPtetJf/9ALOQ2bZFI4jKm aRpMNTx8es00nsmmji/PNqHX/htvNw5L9w8wuL7NMf5eEYl3M4mYyEncJjfhvWjz5WNPH5Bb yG3aHA4SCae8dMKoxMZJbfT0bkElTJfB/ecUqpqAA8eY9dBPTpvb4i+LaxpPvjW2RGrxS72l tXr/AEFuLVBamom1xm0S+VmpXGrGMHlGSGsrmdk/0xxymy5aZeUvksZNY+y7L7E3rsysllz5 3pLB20sWsnb/AINrj7SVlJCSEks+MmV8JynudayZD0LEvdel2a5xrUjKTS7bOWA1tLcWoHWz LFlPsqHlC+hlL6lPXMTSvFecLKv2DGigvbVCdTW5NGjhU7kShiT2XaLUbl8lfIMn7l1rs8rK CL5UkBlob61B512d5ho0UVTTqClm8Nau3iIJN5qwm51aW53+PgE9EiGkq6NtwcLF5zrbc10Z wQ0N4ycvVHT+fDKjJte1KCgf7Nu78uFHuzraGpuWoL21zowagp8gZWbPRmgzCrm1Ep0zm+BO TN0sOgfnr8xCbi1GGxrIdD5q58ymDQ25rkThw/1k69HZs4nTKX027a516TXzSQ26x9mA3GZG TQ0tKZkuz/UihLhceK5XNqGfnDEuF73uy6SuLtf1yLy6OnrdlxHabEJ7m1m0YS6pnVGAz61m 8NzqHEFuM8/lol9aRMbGpPMXiCznujYWcTrp1VeRiopc12OaQm6zpaKCXn8dGR2Vej8ngUCu a5MGt5vOnUMq8S2fXEJus6uyklZWEr9f6h8Q77f8q6tpfR3xeHJdD0Buc8LjoQuuIQuuIYOD 0qVB4vfnukKGPB46s5bU1ua6HvAF5DanamtpbS2JRsnQkOQbsfAbRRYoK6PVVWTGDGLDmw55 B7nNAzYbmTmTzpxJCCHjE9LYGBkfz00j7PGQ8nJaUUHKy3KwdTANuc0z5WVUzYzfT6ampMkp EgiQQIBEoxZvy2Yjbjdxu2lpCSkpwYWrQJDbPObxEI+HqheWikKCQSLLRA5J4RAJR0g4TBSF KApRoiSqEEoIpYRQQiQiSUQixGYndhux24ndToqKSJGDFhUTZzFxOonLRez2nL48SB1yKw67 Xf25JprrukBu4ZYDgHiQWwDxILcA4kFuAcSD3AKI54r7yQsWLs5VPQDAgCRJP/3xC+qo9n0g /BorQL75YN9ezRT0kwHEg9wCiAe5BRAPcgsgHuQWQDzILYB4kFsA8STObWPTEjMrYsX4/02u zeT6rcVvtLFpSU7qAJAyy75/29XRluUFLdHYtCS3FQBIQdL9ZLVp0gwYN1maNi22cY6dG7sU P1FdSq8+cTeqWZuZmgPkoWz83oXapmlSZNzQ8UtpSmqmx12VZm7cwvx0AIEk3d6yY10dTeq4 50vGRlFt/dRZKVx5qouzFaa5NoD8lNe/L5VmS6hpYNGuQsFI5X0gtXuZbCfTuLnTW6HJRjK2 I5BCHQCEkI32Vk2UJlrml0pqW3EXT21tAPlJIoR0dbQtWLj4XGc7+z/XVUodbjJBQfpg396V Dz/60x+/sPLhR1kLVDifl0JoYfoonNwitDB9FE5uAaYP5BZAPMgtgHiQWwDxaN+/jf3FRwDI N1fkVpKkXNUDAMy7Ird4KwUgb/F9YVzfAogHuQUQD3ILIB7kFkA8eI4mgADwHE0AweA5mgCF ALkFEA9yCyAe5BZAPMgtgHiQWwDxILcA4jH1HE3+UVpxC6S8efwKOUAKTP3uOf+IHWu/64dv DgKkIMV+csInXBLuKZVxH2YZ93+DkgCgMtXeqskxeIBl3GGDh1nGbsJkSQAw1d52dbSxf8ZP lI67oMnp5ksCQIrP9UKcAHIorfeBUu7Eml8Q/WSAWKlc38Z9JiXfizbo9Jp8oGZqj94EmCYS 5zZuCDWJjVvSfBkzJQFAlY3nVvMStskplASYbrKdW/MhRFwB9ODzyQDiQW4BxIPcAogHuQUQ D56jCSAePEcTQDx4jiaAGPAcTQCxIbcA4kFuAcSD3AKIB8/RBBAAnqMJIBg8RxOgECC3AOJB bgHEg9wCiAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEg9wCiAe5BRAPcgsgHuQWQDzI LYB4kFsA8SC3AOJBbgHEg9wCiAe5BRAPcgsgHjxHE0A8eI4mgHjwHE0AMeA5mgBiQ24BxIPc AogHuQUQD56jCSAAPEcTQDB4jiZAIUBuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHgS57axaYnB aB5qbFqS/5UESEehtbeNTUu6Otq6OtoQXShgqeeWNWtqPAwGDMrzo7FJi7tO443iK8QwHWg/ 5xhX3ESpCeGHDcSWNxjQq4bJjZqsEoCgTOWWz4Be/5N1TY1zpVnWzGr1VmUAoYWCZyq3luAb 1di5SBqAeVbel1Kb3JRbvNgGOYXbSzgFQMFLsb3lE2UyJ+oisWnkZ8VdUG+jcYONfjIUvMS5 1WSAT5FeYb3YGCxrPvwpTAEoMHn9/i1aToC48jq3CC1AXHmdWwCIC7kFEA9yCyAe5BZAPHiO JoB48BxNAPHgOZoAYsBzNAHEhtwCiAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEg9wC iAe5BRAPcgsgHuQWQDzILYB4kFsA8SC3AOJBbgHEc8XvXSxYuDhX9eBJkkQpzdq28CsfIBzt 78Kd62zPST1U6o9xZKEm+BE8EBT6yQDiQW4BxIPcAogHuQUQD3ILIJ4EuW1sWtLYtIQfTbjG 2DJmljKDVcaqtQGIS/s+UN7inz2P59DDNJe4n9zV0Ra3CU3Y9MUW4Kek03iy0PKr4gc0a+Yn prAtgDyUSntrpulTp/P5Uad0dbQl23jypw/j8rFrjh0AEJqp3LLMpHbE83mLbX6TXZW6IEu+ 3hlEs2ZkFQpMVq9v+fzENsjGzJ84kl0zgHDMvg8U9yrXjMzdXiZcR8A41QgwFJhU2lszl5pq mbgDsdMTtqVJXd8abxpAdAlyyx/oesN6ixgMGE83UxnNRIM1I7FQeCy+vjXZJKa8Wh6iCNOW xbnNUJbSWS3iDYUHn08GEA9yCyAebT85f366JX9qApBvrsitJEm5qodG/tQEIA9dkVvcwgEQ Aq5vAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHiQWwDJ/2rfAAACqElEQVTxILcA4kFuAcSD3AKI B7kFEA9yCyAe5BZAPMgtgHiQWwDxILcA4kFuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHiQWwDx ILcA4kFuAcSD3AKIB7kFEA9yCyAe5BZAPMgtgHi+eI4mnhMNIIrLucVzogEEcjm3eGI1gEBw fQsgHsnr9YbDYVmWFUUJh8OhUIgQ4vf7fT7f+Pj4/fffz+ZSSo3WcmU3OxwO86ORSIQfjUaj /KhmzZpVsfqYnKvZrqIoBhviybLMj9psV5zONBVOZ1RTB+O5Fo6anJVwrrHM7Qr+T5m5vWR+ Hyac63K5+NGSkhJ+1O12q8Mej6e7u7u1tfWRRx4xSOKdd97J5ra3t4+PjztCodDExMTw8DAr GgqFKKXBYLCzs7Orq2vFihWTk5M+n08TCePr4aRyq6HZHZpVaWhyq9mQcW75ami2kk5uc5XM 7OTWeK5mh2doR+XDPoytsGbU6XTyox6Phx/lc+t0Oj/55JMDBw489NBDBkm8/fbb2dyTJ092 dXU5QqHQ8PBwV1dXIBCIRCKhUEhRFFmWW1tbvV5vJBIZGho6c+ZMIBAwX2njv19Sc9MZNX9k 5OpQyM5o5raSk7NSfjawmrl8MmNH+RjbbLajR4+eOHHCOInq3FOnTnm9XseRI0eOHj3a09MT DAZZURbR3t7eycnJqampkZERv9+vadmylsyk9qwxTStqcChoZO6vm7m5Kbe3WSts4bKZWE+a ay4qKjI5GolEwuFwJBIxTqI698iRI5OTk46TJ0+eOHFiYmKCpVxRFL/fTwgJBALhcPiBBx7o 7+9n0TX/kiwMW3YOdOMKay4KjEc10plrlcydDtLZUcYXI5rTt91u11tQw3g9mvyY32ia2zVe FbtMM06iOtfv94fD4f8PcKaec5T2mGIAAAAASUVORK5CYII= --------------010503000008060104000107-- From morwen@evilmagic.org Fri Jun 27 09:32:54 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by mail.gnome.org (Postfix) with ESMTP id 28C28183AD for ; Fri, 27 Jun 2003 09:32:54 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030627133252.SDSC21249.mta01-svc.ntlworld.com@ganymede.arrow>; Fri, 27 Jun 2003 14:32:52 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganymede.arrow (8.11.2/8.11.2) with ESMTP id h5RDWb302018; Fri, 27 Jun 2003 14:32:37 +0100 Subject: Re: Unexpected font rendering with pango From: Abigail Brady To: stephan.hegel@gmx.de Cc: gtk-i18n-list@gnome.org In-Reply-To: <3EFC3811.2090705@gmx.de> References: <3EFC3811.2090705@gmx.de> Content-Type: text/plain Organization: Message-Id: <1056720756.1971.3.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 27 Jun 2003 14:32:37 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 13:26, Stephan Hegel wrote: > Recently I have found an unusual behaviour in Chinese font rendering > with Pango.Please have a look at the attached, little screenshots. The > only difference between both is the setting of the locale before starting > the application. The first one uses LC_ALL=en_US and the second one > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing > antialiasing - fine on the second pix, but not o.k. in the first > case. It somehow uses a different size of fonts in just one string ... > > Anyone out there who has an idea or a hint how to track this and/or to > fix this ? It's doing this because of the preference order of the fonts. With en_US its picking up a japanese or korean font first, and using that to display any characters it has support for - and only then moving to the chinese font. When in the chinese locale, it knows to use chinese fonts first... So you'll need to fiddle with the config files. -- Abi From pablo@mandrakesoft.com Fri Jun 27 11:45:11 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chanae.alphanet.ch (212-100-178-141.adsl.easynet.be [212.100.178.141]) by mail.gnome.org (Postfix) with ESMTP id 0033418587 for ; Fri, 27 Jun 2003 11:45:10 -0400 (EDT) Received: (from srtxg@localhost) by chanae.alphanet.ch (8.9.0/8.9.0) id RAA19301 for gtk-i18n-list@gnome.org; Fri, 27 Jun 2003 17:52:27 +0200 Date: Fri, 27 Jun 2003 17:52:27 +0200 From: Pablo Saratxaga To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango Message-ID: <20030627155227.GA19166@chanae.alphanet.ch> Mail-Followup-To: Pablo Saratxaga , gtk-i18n-list@gnome.org References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <1056720756.1971.3.camel@ganymede.arrow> User-Agent: Mutt/1.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kaixo! On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote: > > Recently I have found an unusual behaviour in Chinese font rendering > > with Pango.Please have a look at the attached, little screenshots. The > > only difference between both is the setting of the locale before starti= ng > > the application. The first one uses LC_ALL=3Den_US and the second one > > LC_ALL=3Dzh_CN.GB2312. The font rendering is - despite the missing > > antialiasing - fine on the second pix, but not o.k. in the first > > case. It somehow uses a different size of fonts in just one string ... > >=20 > > Anyone out there who has an idea or a hint how to track this and/or to > > fix this ? >=20 > It's doing this because of the preference order of the fonts. With > en_US its picking up a japanese or korean font first, and using that to > display any characters it has support for - and only then moving to the > chinese font. When in the chinese locale, it knows to use chinese fonts > first... So you'll need to fiddle with the config files. The problem is that it is using a *non scalable* font at a *wrong size*. Imho pango (well, Xft actually I think) should first look at scalable fonts, and only if no scalable fonts are found ressort to non scalable ones, if that is already doable trough a config option, then I would be interested to know what option it is, in order to enable that by default. It is simply too bad that a single text get in mixed sizes, just because the first matching font is used, without checking it has the character=20 at the right size. Such an output is acceptable if the only other alternative would be to display an empty square, but that is not the case here. Even worst: the first character of the paragraphe is a traditional chinese one, and taken from a traditional chinese font; imho in such case=20 pango should continue with the same font as long as possible, instead of switching to the default one for the next (for every?) character (that behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it makes sense to stick when the same font as long as possible; that is, if a given character was not on the default font, nor in the first CJK font ('ja' or 'ko' covering one in this case), and was on another CJK font, then it should stick with that one, as it is likely that other characters w= ill be in the same case. Following that ordering will give a much better output in all cases of normal CJK text. But if that is too complex to do, pango must at least give priority to scalable fonts, having a word with some letters near 3 or 4 times the size of some others is horrendous. --=20 Ki =E7a vos v=E5ye b=E9n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portugue= se] --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/GhQpSX1mtm4VGYRAn2cAJ9pNE4F7/8K768x4noZ3dem7uyISQCaA8L/ DmDwmnCOlRzB/aZ2XfJNljA= =Fddk -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From otaylor@redhat.com Fri Jun 27 15:16:57 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 03D6618389 for ; Fri, 27 Jun 2003 15:16:57 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5RJGqK30609; Fri, 27 Jun 2003 15:16:52 -0400 Subject: Re: Unexpected font rendering with pango From: Owen Taylor To: Pablo Saratxaga Cc: gtk-i18n-list@gnome.org In-Reply-To: <20030627155227.GA19166@chanae.alphanet.ch> References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> <20030627155227.GA19166@chanae.alphanet.ch> Content-Type: text/plain Message-Id: <1056741412.6045.10.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 27 Jun 2003 15:16:52 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 11:52, Pablo Saratxaga wrote: > Kaixo! > > On Fri, Jun 27, 2003 at 02:32:16PM +0100, Abigail Brady wrote: > > > > Recently I have found an unusual behaviour in Chinese font rendering > > > with Pango.Please have a look at the attached, little screenshots. The > > > only difference between both is the setting of the locale before starting > > > the application. The first one uses LC_ALL=en_US and the second one > > > LC_ALL=zh_CN.GB2312. The font rendering is - despite the missing > > > antialiasing - fine on the second pix, but not o.k. in the first > > > case. It somehow uses a different size of fonts in just one string ... > > > > > > Anyone out there who has an idea or a hint how to track this and/or to > > > fix this ? > > > > It's doing this because of the preference order of the fonts. With > > en_US its picking up a japanese or korean font first, and using that to > > display any characters it has support for - and only then moving to the > > chinese font. When in the chinese locale, it knows to use chinese fonts > > first... So you'll need to fiddle with the config files. > > The problem is that it is using a *non scalable* font at a *wrong size*. > Imho pango (well, Xft actually I think) should first look at scalable fonts, > and only if no scalable fonts are found ressort to non scalable ones, > if that is already doable trough a config option, then I would be interested > to know what option it is, in order to enable that by default. I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd have to have a very exotic configuration (basically, no scalable CJK fonts) to get those results with fontconfig/Xft. > It is simply too bad that a single text get in mixed sizes, just because > the first matching font is used, without checking it has the character > at the right size. Such an output is acceptable if the only other > alternative would be to display an empty square, but that is not the case > here. > > Even worst: the first character of the paragraphe is a traditional chinese > one, and taken from a traditional chinese font; imho in such case > pango should continue with the same font as long as possible, instead of > switching to the default one for the next (for every?) character (that > behaviour may not be wanted for latin/greek/cyrillic etc; but for CJK it > makes sense to stick when the same font as long as possible; that is, > if a given character was not on the default font, nor in the first CJK > font ('ja' or 'ko' covering one in this case), and was on another CJK font, > then it should stick with that one, as it is likely that other characters will > be in the same case. Following that ordering will give a much better > output in all cases of normal CJK text. Unfortunately, you can't autodetect traditional vs. modern Chinese, so I don't think we'll ever be able to do much better than supplied language tag for that situation... if you have a section of text that has only shared characters, it's going to get one or the other font arbitrarily. For other languages, there is possibility of improvement - see http://bugzilla.gnome.org/show_bug.cgi?id=112503. For Stephan, there is a easy solution ... since the app knows the language of the text it is displaying, it can explicitely set the language tag, and override the language tag of the locale. Regards, Owen From pablo@mandrakesoft.com Fri Jun 27 16:26:23 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from chanae.alphanet.ch (212-100-178-141.adsl.easynet.be [212.100.178.141]) by mail.gnome.org (Postfix) with ESMTP id 4DE3118FA5 for ; Fri, 27 Jun 2003 16:26:22 -0400 (EDT) Received: (from srtxg@localhost) by chanae.alphanet.ch (8.9.0/8.9.0) id WAA25904 for gtk-i18n-list@gnome.org; Fri, 27 Jun 2003 22:33:40 +0200 Date: Fri, 27 Jun 2003 22:33:40 +0200 From: Pablo Saratxaga To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango Message-ID: <20030627203340.GB24947@chanae.alphanet.ch> Mail-Followup-To: Pablo Saratxaga , gtk-i18n-list@gnome.org References: <3EFC3811.2090705@gmx.de> <1056720756.1971.3.camel@ganymede.arrow> <20030627155227.GA19166@chanae.alphanet.ch> <1056741412.6045.10.camel@poincare.devel.redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline In-Reply-To: <1056741412.6045.10.camel@poincare.devel.redhat.com> User-Agent: Mutt/1.4i Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kaixo! On Fri, Jun 27, 2003 at 03:16:31PM -0400, Owen Taylor wrote: > I'm pretty sure that the Stephan is not using fontconfig/Xft. You'd probably. > > one, and taken from a traditional chinese font; imho in such case=20 > > pango should continue with the same font as long as possible, instead of > > switching to the default one for the next (for every?) character (that > Unfortunately, you can't autodetect traditional vs. modern Chinese, so I idn't mean that. I meant, if a char "X" is searched in first font, and not found there then found in the second font; then, when displaying the second char "Y", first look at the last used font (the second) instead of looking again at the first, then second. If the search was done like that for CJK (only for CJK, as for latin, greek, and cyrillic it won't be desirable) then a text will be properly displayed in most cases; at worst only the few chars at the begining of the text will be in a different style; not a mixed style in all the document. In the particular case shown in the examples, it would have given a correct display, that is the same display that in the chinese locale.=20 Is such behaviour doable ? It would be a big improvement imho. --=20 Ki =E7a vos v=E5ye b=E9n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portugue= se] --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+/Ko5pSX1mtm4VGYRAmidAJ0bHr8/eIYufQ5aPFZtdDws0y1UMgCfai21 3/EbR70DpOnbrXuDYMi+JNo= =8BqY -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- From keithp@keithp.com Fri Jun 27 17:21:51 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from localhost (unknown [63.227.221.253]) by mail.gnome.org (Postfix) with ESMTP id 11A0318FDA for ; Fri, 27 Jun 2003 17:21:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=keithp.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19W0ex-0001aT-00; Fri, 27 Jun 2003 14:21:31 -0700 X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev To: Pablo Saratxaga Cc: gtk-i18n-list@gnome.org, Keith Packard Subject: Re: Unexpected font rendering with pango From: Keith Packard In-reply-to: Your message of "Fri, 27 Jun 2003 22:33:40 +0200." <20030627203340.GB24947@chanae.alphanet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 14:21:29 -0700 Message-Id: Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Around 22 o'clock on Jun 27, Pablo Saratxaga wrote: > I meant, if a char "X" is searched in first font, and not found there > then found in the second font; then, when displaying the second char "Y", > first look at the last used font (the second) instead of looking again > at the first, then second. And if the characters are in the opposite order, you'll still get 'ransom note' typography. A particular counter example is a document which is largely in English but which happens to start with a Japanese glyph. With a 'sticky font' mechanism, the whole document will be rendered with a Japanese font. The current mechanism is also designed to be 'stable' so that the glyphs selected for any particular character don't change as the document is edited; this makes layout significantly easier. The correct solution is to inform the font system what languages are in use so that appropriate fonts can be selected. -keith From keithp@keithp.com Fri Jun 27 18:03:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from localhost (unknown [63.227.221.253]) by mail.gnome.org (Postfix) with ESMTP id 0D5F318FDB for ; Fri, 27 Jun 2003 18:03:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=keithp.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19W1Iu-0001bw-00; Fri, 27 Jun 2003 15:02:48 -0700 X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev To: Eric Mader Cc: Keith Packard , Pablo Saratxaga , gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango From: Keith Packard In-reply-to: Your message of "Fri, 27 Jun 2003 14:37:26 PDT." <3EFCB916.1050702@bigfoot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 15:02:48 -0700 Message-Id: Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Around 14 o'clock on Jun 27, Eric Mader wrote: > It might also make sense to take the language into account too; possibly > with a notion of what characters are used to write a given language in a > given script. I haven't thought about that enough to say for sure. That's precisely what fontconfig does. It calculates language coverage based on Unicode coverage of language orthography. It's a relatively straightforward technique aside from the collection of language orthographies; fontconfig is still missing orthographies for 17 of the 139 languages in ISO 639-1. > Another point: for complex text like Arabic and Hindi, you really, > really want to try and keep it all in the same font, because that's the > only way to get the correct contextual behavior. Arabic is not horribly problematic as most fonts provide coverage for most languages. One issue for Arabic is that newer fonts are less likely to include the presentation forms and are starting to expect shapers to perform compositing. That may require some additional information for font matching. I've seen significantly more trouble with languages presented in Latin or Cyrillic scripts where the lack of a language tag often results in uncommon glyphs being presented in an unexpected font. If an application wants to ensure that a complete document is presented in a single font, it can pass the set of Unicode values from the document to the font selection mechanism and request a single font covering those values. Language tags simply provide a convenient shorthand for this mechanism. -keith From stephan.hegel@gmx.de Sat Jun 28 20:24:45 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mail.gnome.org (Postfix) with SMTP id DF74418926 for ; Sat, 28 Jun 2003 20:24:44 -0400 (EDT) Received: (qmail 18026 invoked by uid 65534); 29 Jun 2003 00:24:42 -0000 Received: from unknown (EHLO gmx.de) (61.155.124.129) by mail.gmx.net (mp027) with SMTP; 29 Jun 2003 02:24:42 +0200 Message-ID: <3EFE316D.9080609@gmx.de> Date: Sun, 29 Jun 2003 08:23:09 +0800 From: Stephan Hegel Reply-To: stephan.hegel@gmx.de Organization: Private User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en, de, zh-CN MIME-Version: 1.0 To: gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango References: <20030628160014.14571.48469.Mailman@moniker.gnome.org> In-Reply-To: <20030628160014.14571.48469.Mailman@moniker.gnome.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: Hi all, Thanks for the quick replies. Here just a few more notes on the issue. 1. The mentioned application lingoteach is not my work, I have just downloaded it from freshmeat since I'm looking for a vocabulary trainer what is able to display Simplified Chinese chars. However, I will have deeper look into it to figure out how it is done, but it looks like the apps uses only gtk_set_label calls. 2. A language tag as proposed by Owen is certainly a good solution to display a consistent, nice looking layout. However the mentioned application allows to add new languages and one doesn't know in advance what the user want to add. 3. I do use fontconfig/Xft. At least pango is telling me that when I configure it. checking for fontconfig >= 1.0.1... yes checking FONTCONFIG_CFLAGS... -I/usr/local/include checking FONTCONFIG_LIBS... -L/usr/local/lib -lfontconfig checking for freetype-config... /usr/bin/freetype-config checking for FT_Get_Next_Char in -lfreetype... yes checking for xft >= 2.0.0... yes checking XFT_CFLAGS... -I/usr/local/include -I/usr/include/freetype2 -I/usr/X11R6/include checking XFT_LIBS... -L/usr/local/lib -L/usr/X11R6/lib -lXft -lfreetype -lz -lXrender -lfontconfig ... configuration: backends: FreeType X Xft The shared libraries are all available, finally: libpango, libpangoft2, libpangox, and libpangoxft. 4. Beside Arial Unicode MS, there are other TTF Simplified Chinese fonts available on the system like MsSong, MsHei, SimHei, etc. xlsfonts and fc-list reports them all. I would like to find out what font is really selected by what backend in this application. Is there a simple log/trace/track mechanism available in Pango (kind of environment variable or whatever) which can be easily activated ? Thanks & regards, Stephan. From morwen@evilmagic.org Sun Jun 29 05:39:25 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by mail.gnome.org (Postfix) with ESMTP id 7119018655 for ; Sun, 29 Jun 2003 05:39:25 -0400 (EDT) Received: from ganymede.arrow ([213.104.65.3]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030629093925.XPQR18592.mta07-svc.ntlworld.com@ganymede.arrow> for ; Sun, 29 Jun 2003 10:39:25 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganymede.arrow (8.11.2/8.11.2) with ESMTP id h5T9d4f01372 for ; Sun, 29 Jun 2003 10:39:05 +0100 Subject: Re: Unexpected font rendering with pango From: Abigail Brady To: gtk-i18n-list@gnome.org In-Reply-To: <3EFE316D.9080609@gmx.de> References: <20030628160014.14571.48469.Mailman@moniker.gnome.org> <3EFE316D.9080609@gmx.de> Content-Type: text/plain Organization: Message-Id: <1056879544.1119.2.camel@ganymede.arrow> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 29 Jun 2003 10:39:04 +0100 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Sun, 2003-06-29 at 01:23, Stephan Hegel wrote: > 3. I do use fontconfig/Xft. At least pango is telling me that when > I configure it. > > checking for fontconfig >= 1.0.1... yes > checking FONTCONFIG_CFLAGS... -I/usr/local/include > checking FONTCONFIG_LIBS... -L/usr/local/lib -lfontconfig > checking for freetype-config... /usr/bin/freetype-config > checking for FT_Get_Next_Char in -lfreetype... yes > checking for xft >= 2.0.0... yes > checking XFT_CFLAGS... -I/usr/local/include -I/usr/include/freetype2 > -I/usr/X11R6/include > checking XFT_LIBS... -L/usr/local/lib -L/usr/X11R6/lib -lXft -lfreetype > -lz -lXrender -lfontconfig > ... > configuration: > backends: FreeType X Xft > > The shared libraries are all available, finally: > libpango, libpangoft2, libpangox, and libpangoxft. All this is telling you is that Xft was built, not that you are using it. Have you set GDK_USE_XFT? -- Abi From emader@bigfoot.com Fri Jun 27 17:37:30 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mail.gnome.org (Postfix) with ESMTP id AECFD1810B for ; Fri, 27 Jun 2003 17:37:29 -0400 (EDT) Received: (qmail 31091 invoked from network); 27 Jun 2003 21:37:28 -0000 Received: from unknown (HELO bigfoot.com) (emader@[66.93.135.240]) (envelope-sender ) by mail9.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Jun 2003 21:37:28 -0000 Message-ID: <3EFCB916.1050702@bigfoot.com> Date: Fri, 27 Jun 2003 14:37:26 -0700 From: Eric Mader User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Packard Cc: Pablo Saratxaga , gtk-i18n-list@gnome.org Subject: Re: Unexpected font rendering with pango References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: You can make the font 'sticky' only for that script. In general, it seems to be a good idea to try and display all characters in a given script in the same font. It might also make sense to take the language into account too; possibly with a notion of what characters are used to write a given language in a given script. I haven't thought about that enough to say for sure.. Another point: for complex text like Arabic and Hindi, you really, really want to try and keep it all in the same font, because that's the only way to get the correct contextual behavior. Regards, Eric Mader IBM GCoC - San José 5600 Cottle Rd. M/S 50-2/B11 San Jose, CA 95193 Keith Packard wrote: > Around 22 o'clock on Jun 27, Pablo Saratxaga wrote: > > >>I meant, if a char "X" is searched in first font, and not found there >>then found in the second font; then, when displaying the second char "Y", >>first look at the last used font (the second) instead of looking again >>at the first, then second. > > > And if the characters are in the opposite order, you'll still get 'ransom > note' typography. > > A particular counter example is a document which is largely in English but > which happens to start with a Japanese glyph. With a 'sticky font' > mechanism, the whole document will be rendered with a Japanese font. > > The current mechanism is also designed to be 'stable' so that the glyphs > selected for any particular character don't change as the document is > edited; this makes layout significantly easier. > > The correct solution is to inform the font system what languages are in use > so that appropriate fonts can be selected. > > -keith > > > _______________________________________________ > gtk-i18n-list mailing list > gtk-i18n-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-i18n-list > > From otaylor@redhat.com Sun Jun 29 11:55:41 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id DFF921835F for ; Sun, 29 Jun 2003 11:55:40 -0400 (EDT) Received: from vpn50-32.rdu.redhat.com (vpn50-32.rdu.redhat.com [172.16.50.32]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5TFtaK03645; Sun, 29 Jun 2003 11:55:36 -0400 Subject: Re: Unexpected font rendering with pango From: Owen Taylor To: Eric Mader Cc: Keith Packard , Pablo Saratxaga , gtk-i18n-list@gnome.org, morwen@evilmagic.org In-Reply-To: <3EFCB916.1050702@bigfoot.com> References: <3EFCB916.1050702@bigfoot.com> Content-Type: text/plain Organization: Message-Id: <1056902111.15837.55.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 29 Jun 2003 11:55:12 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On Fri, 2003-06-27 at 17:37, Eric Mader wrote: > You can make the font 'sticky' only for that script. In general, it > seems to be a good idea to try and display all characters in a given > script in the same font. It might also make sense to take the language > into account too; possibly with a notion of what characters are used to > write a given language in a given script. I haven't thought about that > enough to say for sure.. This is basically what http://bugzilla.gnome.org/show_bug.cgi?id=112503 is about. Once we have script run information for shaper selection, we need to push it into the font selection algorithm in some fashion, for one thing, because shapers are only fed runs of glyphs in the same font. (The other thing that needs dealing with is dealing omitting non-rendering characters such as ZWJ from font selection to avoid having them break runs... fonts shouldn't have to claim to cover these languages) The language is already taken into consideration by fontconfig - it orders fonts returned by how well they match the language tag, and I think that will automatically carry over into any future script-run based system ... as long as we select fonts in the order that fontconfig returns them, we'll get the best font for the current language. I used to worry about font selection algorithms where subsequent characters could affect previous characters, figuring that would seem confusing while editing, but I've stopped worrying about that. For one, thing, it only matters if the font you have selected doesn't itself include all the characters in the language you are typing. It certainly doesn't make layout harder in any fundamental way since Pango never lays out less than a paragraph at a time. There *is* some question in my mind whether script-range font selection should apply to anything other than COMMON/INHERITED characters. - Pro: it's the only way that ransom-note effects will be reduced for wrong-tagged text for CJK or Roman where fonts commonly don't cover the entire script range. - Con: it can actually make things worse because it means that a single foreign name might throw an entire paragraph of text into a different font. In fact, I think the Con: here wins ... yes, script-run consideration for font selection is important, but no it shouldn't be used to fix problems like the one that started this thread. Regards, Owen [ Abi - since you asked for suggestions of things to work on, I think 91542/112503 is the most serious problem that Pango has at the moment. Assignment of ZWJ/ZWNJ to the wrong shaper has serious consequences for the correct rendering of Farsi and Indic languages. And, I think it's also likely fairly *interesting* to work on, which is definitely an added bonus ] From otaylor@redhat.com Sun Jun 29 12:24:22 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from lacrosse.corp.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id D5F71183EA; Sun, 29 Jun 2003 12:24:21 -0400 (EDT) Received: from vpn50-32.rdu.redhat.com (vpn50-32.rdu.redhat.com [172.16.50.32]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h5TGOLK05478; Sun, 29 Jun 2003 12:24:21 -0400 Subject: [admin] List rules and FAQs added to www.gtk.org From: Owen Taylor Reply-To: gtk-list@gnome.org To: gtk-list@gnome.org, gtk-app-devel-list@gnome.org, gtk-doc-list@gnome.org, gtk-i18n-list@gnome.org, gtk-devel-list@gnome.org Content-Type: text/plain Organization: Message-Id: <1056903836.15837.71.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Date: 29 Jun 2003 12:23:56 -0400 Content-Transfer-Encoding: 7bit Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: I just added a short "List Rules and FAQs" section to http://www.gtk.org/mailinglists.html. Nothing there should be that surprising to current list members, but it wouldn't hurt to take a quick look. If you have any comments or suggestions for additional material which would be useful there, please let me know. Regards, Owen From jshin@mailaps.org Sun Jun 29 13:08:08 2003 Return-Path: Delivered-To: gtk-i18n-list@gnome.org Received: from atlas.jtan.com (atlas.jtan.com [207.106.84.159]) by mail.gnome.org (Postfix) with ESMTP id 8926318A29 for ; Sun, 29 Jun 2003 13:08:07 -0400 (EDT) Received: from callisto.jtan.com (root@callisto.jtan.com [207.106.84.134]) by atlas.jtan.com (8.12.8p1/8.12.8) with ESMTP id h5TH86uN000310 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 29 Jun 2003 13:08:07 -0400 (EDT) Received: from callisto.jtan.com (jshin@localhost [127.0.0.1]) by callisto.jtan.com (8.12.1/8.12.1) with ESMTP id h5TH84OW013528 for ; Sun, 29 Jun 2003 13:08:04 -0400 (EDT) Received: from localhost (jshin@localhost) by callisto.jtan.com (8.12.1/8.12.1/Submit) with ESMTP id h5TH834w013202 for ; Sun, 29 Jun 2003 13:08:04 -0400 (EDT) X-Authentication-Warning: callisto.jtan.com: jshin owned process doing -bs Date: Sun, 29 Jun 2003 13:08:03 -0400 (EDT) From: Jungshik Shin X-X-Sender: To: Subject: Re: Unexpected font rendering with pango In-Reply-To: <1056902111.15837.55.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: gtk-i18n-list-admin@gnome.org Errors-To: gtk-i18n-list-admin@gnome.org X-BeenThere: gtk-i18n-list@gnome.org X-Loop: gtk-i18n-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Internationalization and GTK+ List-Unsubscribe: , List-Archive: On 29 Jun 2003, Owen Taylor wrote: > (The other thing that needs dealing with is dealing omitting > non-rendering characters such as ZWJ from font selection to > avoid having them break runs... fonts shouldn't have to claim to > cover these languages) You meant 'claim to cover these characters', didn't you? If that's what you meant, it may not be so clear-cut for some 'invisible' characters. For characters like 'invisible times' (sorry I forgot the code point, it's somewhere in U+206x? or can be easily found in 'Default_Ignorable' list at Unicode ftp site) and 'invisible apply a function to'(?), there's no question that they should be ignored. [1] It gets a bit murky for ZWJ and ZWNJ (or CGJ).Some opentype fonts have to claim to cover characters like ZWJ and ZWNJ because ZWJ and ZWNJ take part in glyph substitutions (via GSBU look-up) and their presence and absence affect the rendering result. [1] Some aggressive fonts have visible glyphs for truly invisible characters. In presence of those fonts, not taking 'truly invisible' characters into account in font selection is essential to prevent the visible glyph of 'invisible times' from one of those fonts from popping up in the middle of a text-run rendered with another font. Jungshik