Problem with unicode characters in buttons on Win7

[Max Landaeus]

I have a problem displaying Unicode-arrows on buttons when I run on Win7-x64, but they display correctly on my XP and Vista installations. The attached pics shows the difference. The Unicode arrows I'm using characters are represented as: u'\u2190', u'\u2192' u'\u21C4'.

I built the whole application on Win7-64 with py2exe and InnoSetup and distributed it to the XP and Vista machines, so it is the same executable running on all machines.

Anybody knows what causes this?

Max

[Steve Barnes]

Max

Max,

Probably the default system font set on the machine does not have those characters available.  Try setting the font to one you know supports those characters on all three systems.

 

Gadget/Steve

--
To unsubscribe, send email to wxPython-user...@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

[Vlastimil Brom]

2010/10/15 Max Landaeus <m...@landaeus.com>:

I guess, there might be some differences in the default system fonts
between XP and 7,
You may try to experiment with SetFont(...) on the respective widgets.
However, I can display these characters instantly without messing with
fonts - Win7 -64, Home Premium (Czech), py2.7, 2.8.11.0 (unicode).
Maybe the fonts also differ between language versions?

vbr

[Max Landaeus]

I want to ensure that the characters on the buttons show correctly on all my users computers (any of XP, Vista and Win7). Is there any system font that I can set that guarantees that? Or am I better off skipping Unicode altogether and instead use the old '=>', '<=' and '<=>' combinations? Alternatively I could use bitmap buttons...
Opinions?

Max

[Steve Barnes]

Personally I would say that until unicode becomes as prevalent as ANSI you would be better off avoiding using it, the ASNI -> or => both work well and have exactly the same memory footprint as the unicode, 2 bytes each, bitmap buttons can look nicer - I would say it depends on how much time you have available.

[Max Landaeus]

Thanks Steve,
For now I'll just revert to the safer ANSI solution for the arrows as you suggested. Feels like a step backwards though. Greek Gamma and Omega seems to work on all my systems - is that just pure luck? Should I avoid them as well?

Max

[Boštjan Mejak]

Max Landaeus, are you sure that you are using the Unicode version of wxPython?

--

[Max Landaeus]

On 15/10/2010 9:53 PM, Boštjan Mejak wrote:

Max Landaeus, are you sure that you are using the Unicode version of wxPython?

Yes, I'm running 2.8.11.0 (msw-unicode). The characters displays correctly on my systems  with XP and Vista, it's only the one with Win7-x64 that doesn't work.
Max

[Cody Precord]

Hi,

On Fri, Oct 15, 2010 at 9:16 AM, Max Landaeus <m...@landaeus.com> wrote:
>
>
> On 15/10/2010 9:53 PM, Boštjan Mejak wrote:
>
> Max Landaeus, are you sure that you are using the Unicode version of
> wxPython?
>
> Yes, I'm running 2.8.11.0 (msw-unicode). The characters displays correctly
> on my systems  with XP and Vista, it's only the one with Win7-x64 that
> doesn't work.
> Max
>

Could you please make a small runnable sample application that
reproduces the issue?

I remember running into this when I upgraded to windows 7 but for the
life of me can't remember what the fix was at the moment.

Cody

[Tim Roberts]

Steve wrote:
>
> Personally I would say that until unicode becomes as prevalent as ANSI you would be better off avoiding using it,

That's terrible advice. Exactly how long would you expect to wait?
Windows has had Unicode as its default character set since 1992.
That's a hell of a long time in computer terms. Unicode is
everywhere. By ignoring,it, you are merely ensuring that all your
software works only in America.

The original poster's problem is simply in assuming that the default
font always contains the characters he needs. MS Sans Serif (the
default dialog font) has never contained those characters, but he
should easily be able to choose one that does. Arial would do it, and
is universally available.

I, too, would like to see a small runnable sample.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Robin Dunn]

I've run into similar issues before on XP. If I remember correctly on
XP it has something to do with what language support or international
locales are installed, or something like that. Perhaps that triggered
the installation of a different set of fonts that have a more complete
set of glyphs. Win7 might be similar.

--
Robin Dunn
Software Craftsman
http://wxPython.org

[Christopher Barker]

On 10/15/10 10:57 AM, Tim Roberts wrote:
> Windows has had Unicode as its default character set since 1992.
> That's a hell of a long time in computer terms.

And yet, apparently a default GUI font that isn't complete.

> Unicode is
> everywhere. By ignoring,it, you are merely ensuring that all your
> software works only in America.

I don't think anyone was suggesting ignoring Unicode altogether, but in
this particular instance -- it's a good idea to use the default system
font for labeling buttons, etc, and apparently MS is delivering systems
with default fonts that aren't complete (I don't know how rare is it to
use the arrow symbols) -- so sticking with ANSI is a fail safe.

Personally, I'd probably use bitmap buttons in that case, anyway.

> MS Sans Serif (the
> default dialog font) has never contained those characters,

Exactly my point -- despite being Unicode since 1992 -- they still don't
ship a complete version of the font used for dialogs. Sigh.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris....@noaa.gov

[Max Landaeus]

The characters displayed correctly when I started up my Win7 system this morning! There has been a reboot in between - could it be that some other application has changed the system font earlier? I guess I have to watch out.

Anyway, attached is a runnable sample. To keep the code short I removed all functionality, but I left the widget intact with all the controls. The buttons with the Unicode characters starts around line 64.

But since this sample (as well as my full application) now displays correctly on my Win7 system I can not guarantee that this actually reproduces the error. Anyway, it would be interesting to see if anybody else has problems displaying the Unicode-arrows.

Max

[werner]

On 16/10/2010 07:31, Max Landaeus wrote:

....

The characters displayed correctly when I started up my Win7 system this morning! There has been a reboot in between - could it be that some other application has changed the system font earlier? I guess I have to watch out.

Anyway, attached is a runnable sample. To keep the code short I removed all functionality, but I left the widget intact with all the controls. The buttons with the Unicode characters starts around line 64.

But since this sample (as well as my full application) now displays correctly on my Win7 system I can not guarantee that this actually reproduces the error. Anyway, it would be interesting to see if anybody else has problems displaying the Unicode-arrows.

Works fine for me on Win 7 64bit French Edition with Python 2.6, wxPython 2.8.11.0 Unicode.

Werner

[werner]

On 16/10/2010 07:31, Max Landaeus wrote:

...

The characters displayed correctly when I started up my Win7 system this morning! There has been a reboot in between - could it be that some other application has changed the system font earlier? I guess I have to watch out.

Anyway, attached is a runnable sample. To keep the code short I removed all functionality, but I left the widget intact with all the controls. The buttons with the Unicode characters starts around line 64.

But since this sample (as well as my full application) now displays correctly on my Win7 system I can not guarantee that this actually reproduces the error. Anyway, it would be interesting to see if anybody else has problems displaying the Unicode-arrows.

Just noted the second line in your code is:

#coding:utf-8

but should be:

# -*- coding: utf-8 -*-#

Werner

[Steve Barnes]

--------------------------------------------------
From: "Tim Roberts" <ti...@probo.com>
Sent: Friday, October 15, 2010 6:57 PM
To: "wxPython-users" <wxpytho...@googlegroups.com>
Subject: [wxPython-users] Re: Problem with unicode characters in buttons on
Win7

> Steve wrote:

>>
>> Personally I would say that until unicode becomes as prevalent as ANSI
>> you would be better off avoiding using it,
>
> That's terrible advice. Exactly how long would you expect to wait?
> Windows has had Unicode as its default character set since 1992.
> That's a hell of a long time in computer terms. Unicode is
> everywhere. By ignoring,it, you are merely ensuring that all your
> software works only in America.
>

Personally I would say that unless you are willing to specify fonts, (and
possibly ship them), that include the unicode characters that you need then
I would avoid unicode unless I need it - i.e. if I am aiming for an
international application then I would take the extra steps but not just for
a dialog button when there are several alternatives available. I will start
using unicode for everything when either all available fonts are complete,
not likely to happen any time soon, or my target platforms all have a font
manager that has one complete font available that I can either specify or
that will automatically be substituted for any missing characters, this is
the thing that has really been missing IMHO.

> The original poster's problem is simply in assuming that the default
> font always contains the characters he needs. MS Sans Serif (the
> default dialog font) has never contained those characters, but he
> should easily be able to choose one that does. Arial would do it, and
> is universally available.
>
> I, too, would like to see a small runnable sample.
> --
> Tim Roberts, ti...@probo.com
> Providenza & Boekelheide, Inc.
>

[Tim Roberts]

On Oct 16, 12:11 am, Steve Barnes <GadgetSt...@live.co.uk> wrote:
>
> I will start
> using unicode for everything when either all available fonts are complete,
> not likely to happen any time soon,

Or ever. Unicode is simply too large. The most complete font I know
of, Arial Unicode, contains 39,000 glyphs. That covers about 3/4 of
plane 0, although not all, and it doesn't even touch planes 1 and 2.
And yet, it is 23 megabytes.

In my view, the key problem is that without Unicode, you can't even
represent the strings your customers might want. At least you can
STORE Arabic names when you use Unicode, even if you can't yet DISPLAY
them in every circumstance.
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.

[Boštjan Mejak]

The solution is to have the below line as your second line in your script where the labels of the buttons reside:

# coding=utf-8

or

# -*- coding: utf-8 -*-

Either one will enable Unicode in your app. Now, prepend the letter 'u' to the string literal that has the arrow character in it. But don't have the raw Unicode code in the string -- have the arrow character and prepend a 'u' to that string literal. So like this:

#! /usr/bin/env python

# coding=utf-8

import wx

...

...

...

        myButton1 = wx.Button(..., label=u'←')

...

...

...

Try it like this and see if that solves your issue.

Providenza & Boekelheide, Inc.

[Robin Dunn]

On 10/18/10 11:49 AM, Boštjan Mejak wrote:
> The solution is to have the below line as your second line in your
> script where the labels of the buttons reside:
> # coding=utf-8
> or
> # -*- coding: utf-8 -*-
>
> Either one will enable Unicode in your app.

No, not quite. All that declaration does is tell the interpreter (and
some code editors) to treat string literals in the code as if they are
encoded with the named codec. Then it will know how to convert the
literal to unicode if needed at runtime. In other words, it lets you
have non-ascii string or unicode literals in your source code. For
example you can accomplish the same thing without the codec declaration
by using something like this, because you are telling the interpreter
exactly how to make the literal without needing to embed non-ascii
characters in your source file.:

label=u'\u2190'

Whether you can actually display those unicode values at runtime in the
UI is a totally separate matter.

[Boštjan Mejak]

 label=u'\u2190'

 

Whether you can actually display those unicode values at runtime in the UI is a totally separate matter.

This is my point. Maybe his interpreter is having hard time encoding those raw unicode codes into actual arrows. He should have put the arrow characters in the string literal for the characters to be correctly displayed on the button widget. Like this:   label=u'←'   label=u'⇄'   and   label=u'→'

--

[Max Landaeus]

On 20/10/2010 2:08 AM, Boštjan Mejak wrote:

 label=u'\u2190'

 

Whether you can actually display those unicode values at runtime in the UI is a totally separate matter.

This is my point. Maybe his interpreter is having hard time encoding those raw unicode codes into actual arrows. He should have put the arrow characters in the string literal for the characters to be correctly displayed on the button widget. Like this:   label=u'←'   label=u'⇄'   and   label=u'→'

However, it does work with the same executable on my XP and Vista systems - at least I have never seen it fail there. It did not work on my Win 7x64 when I started this thread. After a reboot it worked, then later it stopped working - another reboot and it worked again. It seems like something changes on my system; perhaps by some other application. Ideas anybody?

I also tried to change the font of the buttons to Arial, but it did not help.

For now I have fallen back on the old solution with '->', '<-' and '<->'. The reason I don't use bitmap buttons is that I am also using the arrows in the menu. Surprisingly the left and right arrows worked in the menu but not the 'left over right arrow'. I was also using the angle sign (u'u\2220) in a context menu and that also fails to display  whenever the buttons fail.

Max