Apologies if this has been addressed already.
I have found a bug in the Windows build of the new release of wxPython. Sample code attached reproducing the bug is included. With this build the TextCtrl in the sample will use a generic rasterized font (MS System, I believe) and always at the same size (about 10 I think) regardless of what font attributes are passed in the first call to SetFont(). The only workaround I have found so far is to do an initial call to SetFont() but with a different font size than what is desired, say fontsize=20. After that first call, subsequent calls to SetFont() then sets the font as expected. This workaround isn’t necessary on wxPython2.8 on Windows.
This bug manifests itself in several other controls throughout wxPython in versions 2.9 and 3.0 on Windows. Because the unexpected and incorrect font and size appears on these controls this often unintentionally obscures part of the text strings assigned to these controls. The text simply doesn’t fit on them. Furthermore, a rasterized font is not particularly easy on the eye.
If anyone knows about a solution or a patch to fix this bug that would be greatly appreciated.
Many thanks,
Rob
fontbug.py (896 Bytes)
Hi,
it seems, repeated calls of SetFont with the same parameters cause this problem;
if I remove the call either from __init__ or from WriteText, the font
is rendered as expected;
on the other hand, if two identical calls of SetFont are made in
WriteText, the problem reappears.
What is the intent of "changing" the font before each write to a
widget like this?
Others might comment, whether this is considered a regression and
should be reported as a bug.
hth,
vbr
···
2014-03-28 14:44 GMT+01:00 Robert Oeffner <rdo20@cam.ac.uk>:
Apologies if this has been addressed already.
I have found a bug in the Windows build of the new release of wxPython.
Sample code attached reproducing the bug is included. With this build the
TextCtrl in the sample will use a generic rasterized font (MS System, I
believe) and always at the same size (about 10 I think) regardless of what
font attributes are passed in the first call to SetFont(). The only
workaround I have found so far is to do an initial call to SetFont() but
with a different font size than what is desired, say fontsize=20. After that
first call, subsequent calls to SetFont() then sets the font as expected.
This workaround isn't necessary on wxPython2.8 on Windows.
This bug manifests itself in several other controls throughout wxPython in
versions 2.9 and 3.0 on Windows. Because the unexpected and incorrect font
and size appears on these controls this often unintentionally obscures part
of the text strings assigned to these controls. The text simply doesn't fit
on them. Furthermore, a rasterized font is not particularly easy on the eye.
If anyone knows about a solution or a patch to fix this bug that would be
greatly appreciated.
Many thanks,
Rob
--
You received this message because you are subscribed to the Google Groups
"wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
With the release of wxPython3.0.1 this bug appears now to have been fixed.
Thank you,
Rob
···
On Friday, 28 March 2014 13:44:35 UTC, Robert Oeffner wrote:
Apologies if this has been addressed already.
I have found a bug in the Windows build of the new release of wxPython. Sample code attached reproducing the bug is included. With this build the TextCtrl in the sample will use a generic rasterized font (MS System, I believe) and always at the same size (about 10 I think) regardless of what font attributes are passed in the first call to SetFont(). The only workaround I have found so far is to do an initial call to SetFont() but with a different font size than what is desired, say fontsize=20. After that first call, subsequent calls to SetFont() then sets the font as expected. This workaround isn’t necessary on wxPython2.8 on Windows.
This bug manifests itself in several other controls throughout wxPython in versions 2.9 and 3.0 on Windows. Because the unexpected and incorrect font and size appears on these controls this often unintentionally obscures part of the text strings assigned to these controls. The text simply doesn’t fit on them. Furthermore, a rasterized font is not particularly easy on the eye.
If anyone knows about a solution or a patch to fix this bug that would be greatly appreciated.
Many thanks,
Rob