Use gramps.gen.constfunc.conv_to_unicode() instead, but only where necessary. Values you get from the database should already be unicodes, and since you’ve correctly set unicode_literals, all of your literals will be, too. One place that you *do* need it is when retrieving destfile from the UI, where you should replace
On Apr 15, 2014, at 9:09 AM, Nick Hall <email@example.com> wrote:
> On 15/04/14 12:04, Matt Keenan wrote:
>> I've added new entry as suggested to :
>> I'd appreciate if someone of higher privilege could add entries for
>> 4.0 and 3.4
>> Description page and screen shots also added :
>> I've not managed to test this under 4.0/4.1 specifically, but I have
>> done extensive testing under 3.4 so I'm pretty confident it will work
>> neatly for 4.0 and 4.1, if someone can give them a very quick sanity
>> check I'd appreciate it.
>> Hope folk think these might be useful.
> The ancestral charts look good. I'm sure people will find them useful.
> I couldn't get the descendant chart to work. It only generated a heading.
> The imports need changing to get it working with 4.0, but I'll send you
> an updated version.
> For python3, you will need to get rid of the unicode function. I see
> you are importing unicode_literals, so I'm not sure why you need it.
self.destfile = menu.get_option_by_name('destfile').get_value()
self.destfile = conv_to_unicode(menu.get_option_by_name('destfile').get_value(), ‘utf8’)
The first version will work in Python2 under Linux or OSX but will fail on Windows if the destfile path has non-ascii characters.
Don’t call str(), either. In Py2 that will convert the object to ascii and raise UnicodeErrors on non-ascii values.
Open your file with utf-8 encoding:
fp = io.open(self.destfile, ‘w’, encoding=‘utf8’)
to ensure that Python doesn’t do dumb things when writing out non-ascii characters.
The dataset in examples/gramps in the Gramps sources has entries with a variety of non-ascii characters to test with.