GNOME Bugzilla – Bug 137334
unihan issue should be resolved with current language tag
Last modified: 2004-12-22 21:47:04 UTC
Since 1.3.0 version, script information is used to improve language tags. the UI consistency among locales is finally archieved. But the UniHan issue still exists. For example, the Family names of japanese, traditional chinese and simplified chinese font are included in the generic aliases in fonts.conf and the japanese font will be used to display CJK Unified Ideographs in CJK locale if it is put before another two fonts in generic alias. Ideally we should have simplified chinese font to display Han characters in zh_CN locale and traditional chinese font in zh_TW locale.
Created attachment 25686 [details] [review] one patch based on 1.3.6 version
Can you give a specific example where this is needed? The code in question should only matter when there is a text/lang-tag mismatch - that is, if you say, have Arabic script with a 'ja' lang tag.
I attached the two screenshots of one gtk+ label application, which run in zh_CN locale with different pango libraries. The first one, screenshot.png, uses original pango library. We can tell from its first character that it uses ja font. The second one, screenshot-with-patch.png, uses modified pango library by applying the patch above, this time it uses the appropriate font, zh font, according to current locale.
Created attachment 25717 [details] screen shot of gtk+ label that is dynamically linked to original pango library
Created attachment 25718 [details] screen shot of gtk+ label that is dynamically linked to the modified pango library
Any comment on the patch?
The screenshots don't really tell me what's going on. What is the text / language-tag mismatch?
The code below can be used to demonstrate the text / language-tag mismatch. The itemize_state_init() initializes the state->changed with EMBEDDING_CHANGED | SCRIPT_CHANGED | LANG_CHANGED | FONT_CHANGED, which causes compute_derived_language() to be invoked in the following itemize_state_update_for_new_run() and set the state->derived_lang to be 'xx'. I also think the local variable, old_lang, should be initialized to be 'NULL' in update_attr_iterator(), otherwise, LANG_CHANGED would be wrongly set if state->lang is NULL. #include <gtk/gtk.h> #include <locale.h> int main(int argc, char **argv) { GtkWidget *window, *label; gchar *locale, *text, pattern[256]; gint len; PangoFontDescription *desc; gboolean success; locale = setlocale(LC_ALL, ""); if ( locale ) { printf("current locale is %s\n", locale); setlocale(LC_ALL, locale); } sprintf(pattern, "Sans-serif %s", argv[2]); desc = pango_font_description_from_string(pattern); gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_signal_connect ( GTK_OBJECT(window), "destroy", GTK_SIGNAL_FUNC(gtk_main_quit), NULL); if ((success = g_file_get_contents(argv[1], &text, &len, NULL)) == FALSE) exit(1); label = gtk_label_new (text); gtk_container_add(window, label); gtk_widget_modify_font(label, desc); gtk_widget_show_all(window); gtk_main(); return(0); }
Created attachment 26049 [details] the testcase, please use it as input file
Yeah, that's pretty much the right diagnosis. In fact we weren't taking context->language into account at all! I added: if (!state->lang) state->lang = state->context->language; after the call to pango_attr_iterator_get_font() and your test case now seems to work fine.