Closed GoogleCodeExporter closed 8 years ago
Original comment by useboxnet
on 19 Feb 2014 at 9:06
I am not sure that reea2bb3a18b0 is the source of problem. I see that offending
line is introduced in rc698662310e6. Juan, where did you get it?
Original comment by techtonik@gmail.com
on 20 Feb 2014 at 7:37
techtonik: oh, that merge had some issues. After
8d8d4656883005b1c60b6e9fc5729c07b4d756e3 it should be fine though.
Can you confirm that the issue can be reproduced in tip? ccanepacc report seems
using that version.
Original comment by useboxnet
on 20 Feb 2014 at 6:03
Yes, look at:
https://code.google.com/p/pyglet/source/detail?r=8d8d4656883005b1c60b6e9fc5729c0
7b4d756e3
The /pyglet/font/win32.py diff shows that vector_only=True and hav_font in
/pyglet/font/win32query.py doesn't have that parameter; I'm sorry I can't help
further on this.
Original comment by useboxnet
on 20 Feb 2014 at 6:08
If I understand correctly, the changesets related to this issue have the
purpose of integrate https://bitbucket.org/techtonik/fontquery
Looking at that source, the extra kw-param vector_only=True in the call to
have_font is spurious (the code for have_font both in pyglet and fontquery
don't uses that param)
The other function provided by fontquery, font_query, does in fact use that
kw-param.
Searching the pyglet repo tip for 'font_query', the only hit outside
win32query.py is in a commented out line in examples/font_comparison.py :
#FONTS = list(set(pyglet.font.win32query.font_list(vector_only=True,
monospace_only=True)))
May I suggest:
- delete vector_only=True in the call to have_font (fixes this issue)
- uncomment the call to font_list in examples, so that it gets exercised (it runs in py26 win32 xp)
?
Original comment by ccanepacc@gmail.com
on 21 Feb 2014 at 4:59
Also, maybe rename
font_comparison.py -> font_comparison_windows.py
Original comment by ccanepacc@gmail.com
on 21 Feb 2014 at 5:02
I am not sure where r8d8d46568830 merge comes from.
UPD: https://code.google.com/r/techtonik-fontquery/source/list
I confirm that it is my fault. There is a bug with loading monospace fonts with
pyglet on Windows, so I to have to add the parameter, but failed to push into
fontquery. To get back the previous behavior just remove vector_only=True
And if somebody can test the bug with monospace font and list it here - this
would be awesome too.
Original comment by techtonik@gmail.com
on 23 Feb 2014 at 6:56
Original comment by useboxnet
on 6 Mar 2014 at 9:44
Juan, do you think you can
delete vector_only=True in the call to have_font (fixes the traceback)
apply the patch in #704 ?
I think they are not controversial, and I plan to release cocos 0.6.0 in a few
days; it would be good to suggest a 'known good' pyglet revision to use with
cocos.
Original comment by ccanepacc@gmail.com
on 19 Mar 2014 at 6:57
ccanepacc: sure! This part was contributed by techtonik, that's why I tried to
involve him; but meanwhile I can commit the workaround.
Original comment by useboxnet
on 19 Mar 2014 at 8:17
Done in https://code.google.com/p/pyglet/source/detail?r=82693a20ece0
Original comment by useboxnet
on 19 Mar 2014 at 8:22
thanks !
Original comment by ccanepacc@gmail.com
on 20 Mar 2014 at 1:48
A bit of investigation as asked by Anatoly in comment 7.
I see three different issues here
tabs looking bad (issue #727)
-----------------------------
This is an 'expectations not matching the actual pyglet spec' issue
In windows, some fonts expected to be monospace render as proportional under
pyglet
--------------------------------------------------------------------------------
---
This is a fontquery bug. The autoritative info to decide monospace / not
monospace is FIXED_PITCH, not FF_MODERN
I would had filled an issue in fontquery with details and code but his issue
tracker is not public.
Should I post details as a new issue in pyglet tracker ?
Expectations about supported font formats #731
----------------------------------------------
related to bad rendering of some fonts in examples/font_comparison.py
Original comment by ccanepacc@gmail.com
on 7 Apr 2014 at 2:25
opened issue #744 for the last bit remaining of this issue.
I think this issue can be closed now.
Original comment by ccanepacc@gmail.com
on 21 May 2014 at 3:04
Thanks Claudio!
Original comment by useboxnet
on 21 May 2014 at 3:08
Original issue reported on code.google.com by
ccanepacc@gmail.com
on 18 Feb 2014 at 8:16