After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 328031 - Call setdefaultencoding in pango instead of gtk
Call setdefaultencoding in pango instead of gtk
Status: RESOLVED FIXED
Product: pygtk
Classification: Bindings
Component: general
2.8.x
Other All
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2006-01-21 17:58 UTC by Rauli Ruohonen
Modified: 2007-04-07 14:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Rauli Ruohonen 2006-01-21 17:58:52 UTC
Please describe the problem:
A bug exists.

Steps to reproduce:
Run the following script:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import pangocairo
import cairo
very_ugly_kludge = False
def bugtest():
  surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, 20, 20)
  context = pangocairo.CairoContext(cairo.Context(surface))
  layout = context.create_layout()
  txt = u'Ä'
  if very_ugly_kludge: txt = txt.encode('utf-8')
  layout.set_text(txt)
try: bugtest()
except UnicodeEncodeError:
  print 'Error: layout.set_text() does not accept unicode input'
else: print 'OK without gtk imported'
try: import gtk
except RuntimeError, reason:
  print "Can't import gtk, not testing further (gtk: %s)"%reason
else:
  try: bugtest()
  except UnicodeEncodeError:
    print ('Error: layout.set_text() does not accept unicode input '
           'even with gtk imported')
  else: print 'OK with gtk imported'

Actual results:
This output is printed:

Error: layout.set_text() does not accept unicode input
OK with gtk imported


Expected results:
This output should be printed:

OK without gtk imported
OK with gtk imported


Does this happen every time?
Yes, if the default encoding set in site.py is not utf-8.
It is not in the standard python distribution.

Other information:
Can be worked around by setting very_ugly_kludge to True.

This bug is related to bug 132040, which is about "import gtk"
changing default encoding to "utf-8", which it should not do.
Thus even in the case where "import gtk" has been done, the bug
still exists -- it is merely silent, and will appear when bug
132040 is eventually fixed.

Even if 132040 were decided not to be a bug, this should still be
fixed: requiring "import gtk" is not a solution, because the gtk
module requires a display, while pango and cairo themselves do not.
Comment 1 Johan (not receiving bugmail) Dahlin 2006-01-22 16:18:59 UTC
Right.

Since most of the encoding related code in gtk+ is done by pango setdefaultencoding should be moved into pango to avoid this kind of
unexpected behavior.

I guess you are the first one to ever use pango without gtk.
Comment 2 John Ehresman 2006-01-22 17:24:35 UTC
Does _gtk import the pango module?  If not, it needs to be done in both places or in gobject.  Maybe it would be better to do it in gobject because I suspect there are binding in it the depend on utf8 strings.
Comment 3 Johan (not receiving bugmail) Dahlin 2006-04-01 17:23:36 UTC
gtk._gtk provides gtk.gdk which imports pango.

You can't import gtk._gtk without importing gtk anyway, so it's fine.

I'm moved it to pango, since we don't wrap any utf-8 functions in glib.
Maybe we should move it to gobject, but I'd like to avoid that, because you might want to use gobject in an application where utf-8 is not assumed as the default locale. Pango is safer in that respect, since the only real user is gtk+.

Checking in ChangeLog;
/cvs/gnome/gnome-python/pygtk/ChangeLog,v  <--  ChangeLog
new revision: 1.1364; previous revision: 1.1363
done
Checking in pangomodule.c;
/cvs/gnome/gnome-python/pygtk/pangomodule.c,v  <--  pangomodule.c
new revision: 1.9; previous revision: 1.8
done
Checking in gtk/gtkmodule.c;
/cvs/gnome/gnome-python/pygtk/gtk/gtkmodule.c,v  <--  gtkmodule.c
new revision: 1.60; previous revision: 1.59
done
Comment 4 Paul Pogonyshev 2007-04-07 14:06:39 UTC
I propose to move this into PyGObject, since it too contains functions that accept strings.  See e.g. bug #426185.