GNOME Bugzilla – Bug 440603
Minor ABI change
Last modified: 2007-05-23 22:15:13 UTC
Have a look at bug 440514. It appears that pango_shape in recent times has changed to require that the analysis has a language set up too. We have been getting away with a NULL value in Gnumeric for many years.
Humm. We do interesting stuff with language these days, yes. Technically this has been a bug in Gnumeric, but I'm fine fixing it in Pango. I believe you are hitting a g_return_val_if_fail() in pango_ot_tag_from_language(), right? I can change that to legitimately allow NULL and make sure other places taking a language handle NULL too.
> I believe you are > hitting a g_return_val_if_fail() in pango_ot_tag_from_language(), right? Precisely. I have put a fix into Gnumeric, but there will be some short-term grief if a distribution picks up a new Pango, but not a new Gnumeric. Therefore, a Pango-side fix would be nice.
Feel free to revert your gnumeric change. This only went in pango-1.17.0 that is a devel release. 2007-05-22 Behdad Esfahbod <behdad@gnome.org> Bug 440603 – Minor ABI change * pango/pango-language.c (pango_language_includes_script): * pango/pango-ot-tag.c (pango_ot_tag_from_language): Accept language == NULL as legitimate input.
Without digging the change out of subversion, I'm not sure exactly what you did. Historically, NULL had a specific meaning as a language tag: Use a "mixed language" string as a sample string for computing what fonts were needed for metrics. (There was some comment by that string in the sources like "total garbage") This was pretty much a bad idea - it meant that if a program forgot to set a language tag, they got a) slow performance and b) bad metrics. If you went through the GTK+ API for creating a PangoContext you always got a language tag based on the locale but it was a trap for people creating one by hand. Either warning in that case or using something locale-based would have been better. Switching to a warning isn't a compatible change, so probably the right thing to do is to come up with a default language tag from the environment. which I believe you've already written code for elsewhere in Pango?
What I did was changing g_return_val_if_fail() to regular if(). The effect is, for NULL language, pango_ot_tag_from_language() returns 'dflt' which results in the default language-system to be used, and pango_language_includes_script() returns TRUE (much like the case for a COMMON script for example). As for the real problem with NULL language, I made this change: 2007-05-23 Behdad Esfahbod <behdad@gnome.org> Part of Bug 440603 – Minor ABI change * pango/pango-context.c (pango_context_init), (pango_context_set_language), (pango_context_get_language): Make itemization use pango_language_get_default() if context has no language set on it. Ditto for pango_context_get_metrics() if both input language and context language are NULL. So, to summarize, during itemization, an item's language is assigned in the following order: - If a language attribute is present, use it, otherwise - If a context language is present, use it, otherwise - Use pango_language_get_default() - Then, if the chosen language is not compatible with the script of the item, use the first language in $PANGO_LANGUAGE or $LANGUAGE that is compatible with the script. If none matches, use pango_language_from_string("xx").