Install and use freetype-py in Win 7 64 bit about freetype-py HOT 61 OPEN

The fix is in
#66

@adesun : Thanks for your offer, but your binaries are also missing those two symbols and therefore don't work with the latest freetype-py without my fix either. Hopefully the fix should go in soon. Meanwhile https://github.com/HinTak/Font-Validator/tree/master/bin/Win64 should work, allthough it has some extra stuff for Fontvalidator and is expected to be slower /etc for normal usage.

from freetype-py.

For a quick fix, @pm-docuvive , you could also simply delete the two lines containing FT_Get_BDF_* in freetype/raw.py or protect it with a try/pass block (see
HinTak@fac3111 )

from freetype-py.

Thanks for re-opening the issue from googlecode.

Can you test the current git version and put your the freetype6.dll in the examples directory and rename it to freetype.dll ? @mdsitton provided a patch to support looking for the dll in the current directory if not found elsewhere (ctypes is not so good at finding dlls actually).

For the 126 error, does this help ? http://stackoverflow.com/questions/1940578/windowserror-error-126-the-specified-module-could-not-be-found

Where is the freetype 1.0 you're referring to ?
What is the result of "import ctypes" in the python console ?

For the FT_Advance, I think it is defined: http://www.freetype.org/freetype2/docs/reference/ft2-quick_advance.html#FT_Get_Advance

from freetype-py.

Hi,
On 11/5/2014 3:06 PM, Nicolas P. Rougier wrote:

Can you test the current git version and put your the freetype6.dll in
the examples directory and rename it to freetype.dll ? @mdsitton
https://github.com/mdsitton provided a patch to support looking for
the dll in the current directory if not found elsewhere. ctype library
is not so good at finding dll actually.

For the current git version,
first, "filename = ctypes.util.find_library('freetype')" gives filename
= None, if there is no freetype.dll into Windows/SysWOW64 (if there is
the freetype.dll, filename = "C:\windows\system32\freetype.dll".
Second, if I specify where freetype.dll is (say, set filename =
"C:\Program Files (x86)\GnuWin32\bin\freetype.dll", the code returns
the following error:

RuntimeError('Freetype library not found')

I think it is the same error as the previous version, because this error
is due to

try:
dll = ctypes.CDLL(filename)

and the system cannot use CDLL(filename), just like the previous version!

For the 126 error, does this help ?
http://stackoverflow.com/questions/1940578/windowserror-error-126-the-specified-module-could-not-be-found

Where is the freetype 1.0 you're referring to ?
What is the result of "import ctypes" in the python console ?

It is the freetype-py provided by pip, one can use pip install
freetype-py to install that version of freetype-py.

import ctypes works! it seems that it imports:
ft_enums.ft_outline_flags, ft_enums.ft_lcd_filters,
ft_enums.ft_stroker_borders, ft_structs, ft_types, ft_enums.ft_fstypes,
ft_enums.tt_mac_ids, ft_enums.ft_glyph_bbox_modes, ft_enums,
ft_enums.tt_platforms, ft_enums.ft_encodings, ft_enums.ft_kerning_modes,
ft_enums.tt_mac_langids, ft_enums.tt_apple_ids,
ft_enums.ft_render_modes, ft_enums.ft_stroker_linecaps,
ft_enums.ft_face_flags, ft_enums.ft_glyph_formats,
ft_enums.tt_ms_langids, ft_enums.tt_ms_ids, ft_enums.ft_open_modes,
ft_enums.ft_stroker_linejoins, ft_enums.ft_load_targets,
ft_enums.ft_load_flags, ft_errors, ft_enums.ft_pixel_modes,
ft_enums.tt_adobe_ids, ft_enums.tt_name_ids, ft_enums.ft_style_flags

(I am not sure about it, simply typing "import ctypes" does not show any
error.

For the FT_Advance, I think it is defined:
http://www.freetype.org/freetype2/docs/reference/ft2-quick_advance.html#FT_Get_Advance

As for FT_Advance, I think I am using freetype-2.3.5 API, it is
FT_Get_PER_Advance. May I ask where to get freetype 2.5.2's windows
installation files? Since I can only get 2.3.5's windows setup file
from: http://gnuwin32.sourceforge.net/packages/freetype.htm.

Thanks,
Tao

—
Reply to this email directly or view it on GitHub
#17 (comment).

from freetype-py.

Unfortunately, I'm not familiar with windows.

from freetype-py.

Hi, Rougier,

I really wish the freetype-py can be used in Windows, since there are
many people using WinPython and Windows system. Now, it seems that the
code works in 32 bit Win 7, but not 64 bit (or, it used to work on a 64
bit Win 7 a year ago when we first developed our code based on the
freetype-py in pip), I hope someone can help on resolving this issue.

Regards,
Tao

On 11/5/2014 4:31 PM, Nicolas P. Rougier wrote:

Unfortunately, I'm not familiar with windows.

—
Reply to this email directly or view it on GitHub
#17 (comment).

from freetype-py.

Re-reading the whole thread, it seems your problem is linked to 32/64 bits DLL.
Do you know if your python installation is 32 or 64 bits (you can have a look at information displayed when you start a console session or have a look at http://stackoverflow.com/questions/1405913/how-do-i-determine-if-my-python-shell-is-executing-in-32bit-or-64bit-mode-on-os)

from freetype-py.

I'll do some tests tomorrow to see if I have any issues using 64 bit python.-
Had no issues in 64-bit windows with 32-bit python.

from freetype-py.

On 2014/11/6 1:43, Nicolas P. Rougier wrote:

Re-reading the whole thread, it seems your problem is linked to 32/64
bits DLL.
Do you know if your python installation is 32 or 64 bits (you can have
a look at information displayed when you start a console session or
have a look at
http://stackoverflow.com/questions/1405913/how-do-i-determine-if-my-python-shell-is-executing-in-32bit-or-64bit-mode-on-os)

—
Reply to this email directly or view it on GitHub
#17 (comment).

My installation of python (Winpython) is 32 bit, because when i used 64
bit winpython, the code will throw another error saying that %l is not a
valid Win32 application, i suspect this refers to
GnuWin32/bin/freetype.dll. My freetype version is 2.3.5, windows
installation.

from freetype-py.

What happens if you type:

>>> import ctypes
>>> ctypes.CDLL("C:\Windows\System32\freetype.dll")

or

>>> import ctypes
>>> ctypes.CDLL("C:\Windows\System32\freetype6.dll")

from freetype-py.

On 11/6/2014 8:38 AM, Nicolas P. Rougier wrote:

What happens if you type:

|>>> import ctypes

ctypes.CDLL("C:\Windows\System32\freetype.dll")|
|Traceback (most recent call last):
File "", line 1, in
File
"C:\WinPython-32bit-2.7.6.4\python-2.7.6\lib\ctypes__init__.py", line
365, in init
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 126] The specified module could not be found|
|
|

or

|>>> import ctypes

ctypes.CDLL("C:\Windows\System32\freetype6.dll")|

|
|

—
Reply to this email directly or view it on GitHub
#17 (comment).

from freetype-py.

But C:\Windows\System32\freetype.dll does exist ?

from freetype-py.

Yes, I put the freetype copy in windows/system32 and windows/sysWOW64.

This also concerns an early point, if I only put the freetype.dll in
windows/sysWOW64, the return filename is windows/system32/freetype.dll.
If I only put the dll in windows/system32, under 64 bit win 7, the
system cannot find it and return None for filename.

On 11/6/2014 10:19 AM, Nicolas P. Rougier wrote:

But |C:\Windows\System32\freetype.dll| does exist ?

—
Reply to this email directly or view it on GitHub
#17 (comment).

from freetype-py.

See i think most of the issue comes from the fact that the ctypes dll searching logic on windows is utterly broken. It basically only searches for places that are in your path. If its in a place thats not in the path it wont find it.

from freetype-py.

That's weird.

In the meantime, you can replace the searching part with absolute path on your system because I have no control over ctypes find_library. I also found its behaviour quite unpredictable sometime. I remember reading they have quite good reasons for such behaviour but I forgot them.

You also try to report this to the ctypes issue tracker.

from freetype-py.

Hi, Rougier,

The same error occurs even if I gave the specified path of the
freetype.dll, such as: C:\Program Files (x86)\GnuWin32\bin\freetype.dll.
The whole thing works in a 32bit Win 7, but not in 64bit Win 7. I wonder
how to also make it work in 64bit Win 7.

Tao

On 11/6/2014 11:52 AM, Nicolas P. Rougier wrote:

That's weird.

In the meantime, you can replace the searching part with absolute path
on your system because I have no control over ctypes find_library. I
also found its behaviour quite unpredictable sometime. I remember
reading they have quite good reasons for such behaviour but I forgot them.

—
Reply to this email directly or view it on GitHub
#17 (comment).

from freetype-py.

Is it possible due to the level of administrative control on that dll file?
On 11/6/2014 11:52 AM, Nicolas P. Rougier wrote:

That's weird.

In the meantime, you can replace the searching part with absolute path
on your system because I have no control over ctypes find_library. I
also found its behaviour quite unpredictable sometime. I remember
reading they have quite good reasons for such behaviour but I forgot them.

—
Reply to this email directly or view it on GitHub
#17 (comment).

from freetype-py.

Some more explanation at: http://stackoverflow.com/questions/10411709/windowserror-error-126-when-loading-a-dll-with-ctypes

I cannot run the DependcWalker but you might get some interesitng information from your freetype.dll

from freetype-py.

Thanks, I saw that link before. I tried reinstall c++ runtime and it does
not work. May I ask how to rebuild the dll with /mt mode in windows? In
addition, what are the possible other dlls needed by free type, i am really
naive on handling dlls.
Tao

On Thursday, November 6, 2014, Nicolas P. Rougier [email protected]
wrote:

Some more explanation at:
http://stackoverflow.com/questions/10411709/windowserror-error-126-when-loading-a-dll-with-ctypes

I cannot run the DependcWalker but you might get some interesitng
information from your freetype.dll

—
Reply to this email directly or view it on GitHub
#17 (comment).

from freetype-py.

Well, I'm also clueless, sorry.

from freetype-py.

Do you happpen to have a 64-bit version of freetype on windows that i can test with?

from freetype-py.

On 2014/11/9 12:03, Matthew Sitton wrote:

Do you happpen to have a 64-bit version of freetype that i can test with?

—
Reply to this email directly or view it on GitHub
#17 (comment).

No, I only have the freetype 2.3.5 under GnuWin32. i am using Windows,
so I do not know how to compile a 64-bit freetype under Windows. I
sincerely hope expert like you can help.
Tao

from freetype-py.

Ah so your using the 32-bit dll that would be why its not working correctly.

However i have been able to get a 64-bit dll for windows compiled. the CDLL calls work, but it fails when trying to get a function from it.

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "freetype\__init__.py", line 64, in <module>
    FT_Init_FreeType       = __dll__.FT_Init_FreeType
  File "C:\Python27\lib\ctypes\__init__.py", line 378, in __getattr__
    func = self.__getitem__(name)
  File "C:\Python27\lib\ctypes\__init__.py", line 383, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'FT_Init_FreeType' not found

I am going to try to replace the binding code with what i generally use when doing ctypes bindings. To see if that changes anything.

from freetype-py.

Ok so that error seems to be an issue with the dll that i built. With a 32 bit version of python a 32 bit dll does the same thing. hmm

edit:
found a stack overflow question about it:
http://stackoverflow.com/questions/6207176/compiling-freetype-to-dll-as-opposed-to-static-library
You need to add the following into the ftoption.h after the DLL export compilation comment:
#define FT_EXPORT(x) __declspec(dllexport) x
#define FT_BASE(x) __declspec(dllexport) x
#define FT_EXPORT_DEF(x) __declspec(dllexport) x

from freetype-py.

Yes, i am using WinPython 32 bit, and the whole thing (32 bit Win 7, 32
bit WinPython, 32 bit GnuWin32 freetype) works well in my home computer,
which is a 32-bit Win 7. I wonder since 64 bit Win 7 allows many 32 bit
softwares 32 bit freetype should also work.

Thanks,
Tao

On 2014/11/9 12:56, Matthew Sitton wrote:

Ok so that error seems to be an issue with the dll that i built. With
a 32 bit version of python a 32 bit dll does the same thing. hmm

—
Reply to this email directly or view it on GitHub
#17 (comment).

from freetype-py.

It doesn't you need to use 64-bit dlls.
here is a 64-bit freetype dll it seem to work with 64-bit python in my tests.
https://dl.dropboxusercontent.com/u/37405488/freetype.zip
edit:
Also that is the latest version of freetype 2.5.3.
I also used the Visual Studio 14 CTP that i have installed on my windows 10 VM(I'm on my mac right now). So if that shows any issues, I will compile it with Visual Studio 2013 on my desktop.

from freetype-py.

Here is also a x86 copy(32-bit) of the latest version of freetype(2.5.3):
https://dl.dropboxusercontent.com/u/37405488/freetype-x86.zip

from freetype-py.

On 2014/11/9 13:20, Matthew Sitton wrote:

Here is also a x86 copy(32-bit) of the latest version of freetype(2.5.3):
https://dl.dropboxusercontent.com/u/37405488/freetype-x86.zip

—
Reply to this email directly or view it on GitHub
#17 (comment).

Thank you very much for the files. I installed both WinPython 32bit and
64bit, and used two commands to test: import ctypes and
ctypes.CDLL("...\freetype.dll"). The directory is correct.

Now, under Python 32 bit, 32 bit freetype.dll throws the same error:
WindowsError: [Error 193] %1 is not a valid Win32 application. 64 bit
freetype.dll throws the error: WindowsError: [Error 126] The specified
module could not be found. 64 bit free
Under Python 64 bit, both versions of freetype.dll throws the same
error: WindowsError: [Error 126] The specified module could not be found.

from freetype-py.

Try giving the full path to the dll not a relative one see if that makes any difference.

Although that doesn't seem to make any difference to me.

>>> ctypes.CDLL("./freetype.dll")
<CDLL './freetype.dll', handle b0460000 at 23d1b00>
>>>

edit:

>>> ctypes.CDLL(".\freetype.dll")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\ctypes\__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)
WindowsError: [Error 126] The specified module could not be found
>>>

The issue is the slash you used: use / instead of \

Make sure you are only using one dot or 2 dots 3 dots don't represent anything.

from freetype-py.

On 2014/11/9 13:45, Matthew Sitton wrote:

Try giving the full path to the dll not a relative one see if that
makes any differance.

—
Reply to this email directly or view it on GitHub
#17 (comment).

I gave the full path ("c:\test32\freetype32.dll" and
"c:\test64\freetype64.dll"), and the same things happened.

from freetype-py.

>>> ctypes.CDLL("C:\\freetype-dll-test\\freetype.dll")
<CDLL 'C:\freetype-dll-test\freetype.dll', handle acca0000 at 23e1358>
>>>

Hmm still seems to work properly for me. time to test if it works on my desktop.

from freetype-py.

Try these dll's instead if they still don't work i'll need to install an older version of visual studio.
https://dl.dropboxusercontent.com/u/37405488/freetype-vs13.zip

from freetype-py.

On 2014/11/9 14:14, Matthew Sitton wrote:

Try these dll's instead if they still don't work i'll need to install
an older version of visual studio.
https://dl.dropboxusercontent.com/u/37405488/freetype-vs13.zip

—
Reply to this email directly or view it on GitHub
#17 (comment).

Thank you very much Matthew, the freetype version under x64 in your new
file works on my computer! Can you summarize what happened?
Thanks again,
Tao

from freetype-py.

Well it was mainly that the previous versions i was building with a pre-release version of the New Visual Studios, which the runtime libraries for arn't on most computers yet.

from freetype-py.

Unless you mean the whole issue in general and not what was wrong with the first dll's.

from freetype-py.

Thanks Matthew. Should we add something in the freetype-py README explaining the problem (it may happen again to other people I guess) ?

from freetype-py.

Maybe, the only thing that is really needed though is the correct dll for your python version. It might be good to put a link to the dlls somewhere.

Really all that needs to be mentioned is that you whichever version of python you have (x64 or x86) you need to have the freetype dll of the same archetecture. Then if you which to distribute the code that uses freetype-py the dll should be in the same directory as the script that starts the application.

from freetype-py.

On 2014/11/9 16:04, Matthew Sitton wrote:

Maybe, the only thing that is really needed though is the correct dll
for your python version. It might be good to put a link to the dlls
somewhere.

Really all that needs to be mentioned is that you whichever version of
python you have (x64 or x86) you need to have the freetype dll of the
same archetecture. Then if you which to distribute the code that uses
freetype-py the dll should be in the same directory as the script that
starts the application.

—
Reply to this email directly or view it on GitHub
#17 (comment).

Hi, Matthew and Nicolas,

I fully agree that we should put the latest 32bit and 64bit freetype.dll
somewhere for people to use. The freetype.dll that works well on my
32bit Win7 was from GnuWin32 freetype 2.3.5. It is an old version, in
which some functions such as Get_PFR_Advance have been replaced by
Get_Advance, as mentioned in one of previous comments. So latest version
of freetype is really necessary!

Another issue is that I did not test whether these new freetype.dll
files work under freetype-py 0.5.1 in Nicolas' git, I only used the
freetype-py that was installed via "pip install".

Tao

from freetype-py.

Alright, so rougler if a new release could happen that included my windows fixes that would also simplify stuff also.

edit: oh didn't see that you had already tagged a release a while back with. So ignore this :P

from freetype-py.

@mdsitton Aarrgghhh ! I forgot to add your name to the contributors (README), very sorry about that.
It has just been fixed.
@gtojty Can you send me your name such that I can add it to the README as well

As for the windows DLL, it might be good to contact freeype guys to ask whether there are some official repos for the DLL and if not, it it could be a good idea to add them.

I'm closing the issue now.

from freetype-py.

haha its alright.

Freetype has no official windows download they just link to a few other projects that have outdated versions.

from freetype-py.

Name: Tao Gong

发自我的 iPad

在 Nov 10, 2014，1:49 AM，Nicolas P. Rougier [email protected] 写道：

@mdsitton Aarrgghhh ! I forgot to add your name to the contributors (README), very sorry about that.
It has just been fixed.
@gtojty Can you send me your name such that I can add it to the README as well

As for the windows DLL, it might be good to contact freeype guys to ask whether there are some official repos for the DLL and if not, it it could be a good idea to add them.

I'm closing the issue now.

—
Reply to this email directly or view it on GitHub.

from freetype-py.

I compiled a 64 bit version of freetype.dll, from 2.6.3 source code on Win7 using VS2010 and it worked fine for me. You can get the dll here:

https://dl.dropboxusercontent.com/u/36575616/freetype.dll

from freetype-py.

Hello,

None of the dropbox files works currently. I also need the freetype.dll 64 bit version. Can one of you guys share with me?

Thanks

Oguzhan

from freetype-py.

@oguzhantogay Try this one: https://github.com/JonnoFTW/TonsleyLEDManager/raw/master/freetype.dll

from freetype-py.

Thanks

from freetype-py.

I'm getting the following error: function 'FT_Get_BDF_Charset_ID' not found
when loading the 64-bit Freetype DLL from https://github.com/ubawurinna/freetype-windows-binaries, and also when using the version posted by @JonnoFTW on 18 Sep 2017 above. Does anyone know how to get around this?

from freetype-py.

@pm-docuvive I suspect that this project has been updated since those binaries were compiled. Contact @ubawurinna for an update.

from freetype-py.

from freetype-py.

I've compiled freetype dll (v2.8.1) win32 and x64 for windows, It works well with freetype-py. you guys can have a try .

from freetype-py.

@adesun what would be useful is if you submit your changes to the visual studio project files for review before send to upstream, to make it official. One of the FreeType developers had added dll support to 2.8.x quite recently - apparently it was all static build before that. I have looked at what it builds, and it is quite minimal.

from freetype-py.

I think we need to minimize the number of differing and unofficial windows build of freetype floating around.

from freetype-py.

Thanks for that @HinTak . I am using an installed FT package without access to the source code. If I can get hold of the source code I will apply your suggestion.

from freetype-py.

@adesun @HinTak I will also try your other tips and new builds when I am back on this project (currently focused on other tasks), and will report back. Thanks for your responsiveness and support.

from freetype-py.

Thanks @HinTak, it worked for me

from freetype-py.

HinTak
sorry for so late. actually I tried your dll
but It didn't work on my PC (win8.1 and win server 2012 )
VS project files has been pushed now.

from freetype-py.

@adesun what sort of error did you get / better description of "didn't work"?

from freetype-py.

@pm-docuvive

For a quick fix, @pm-docuvive , you could also simply delete the two lines containing FT_Get_BDF_* in freetype/raw.py or protect it with a try/pass block (see
HinTak/freetype-py@fac3111 )

It's useful for me , Python 32 with Windows 7 64 , just modify C:\Python27\Lib\site-packages\freetype\raw.py

from freetype-py.

Aha ,today I find something maybe can explain this problem.

First, I use Python-32 on Windows7-64.

I create a test file aatest.txt in C:\windows\system32\ with python , and write some string, then close it.
Then I find the file location is "C:\Windows\SysWOW64\aatest.txt",
unbelievable, aha.

So I put an other test file bbtest.txt in C:\Windows\SysWOW64, read from python and set path='C:\windwos\system32', it print the data correctly

But when I move bbtest.txt to C:\windwos\system32, retry to read it , print an error "IOError: [Errno 2] No such file or directory: 'C:\windows\system32\bbtest.txt'"

It seems like Python treat "system32" as a soft link to "SysWOW64", and change all path like "C:\Windows\SysWOW64" to "C:\Windows\system32".

So when we copy freetype-32 to C:\windows\system32, it will put an error,because python can't find it in SysWOW64 .
filename = ctypes.util.find_library('freetype')
print filename
None

When we copy freetype-64 to C:\windows\SysWOW64, Python tell you ,"yes,I can find it ,and it's path c:\windwos\system32"
filename = ctypes.util.find_library('freetype')
print filename
c:\windwos\system32\freetype.dll
Then you load it ,
_lib = ctypes.CDLL(filename)
Because it really point to c:\windwos\SysWOW64\freetype.dll ,so it print an error like "not win32".

But when we copy freetype-32 to C:\windows\SysWOW64 ( I declare that it's wrong to do it ), it load correctly.

For the deep reason, I can't explain ,maybe somebody know why Python32 do this.
Looking forward to the answer

from freetype-py.

@likohank most of your observation about how 32-bit python behaves unders 64-bit windows is irrelevant. Microsoft Windows internally does a few things when runnng 32-bit applications on the 64-bit OS. One thing is that registry access is mapped to a different sub-tree ("WOW64Node" ), and another is that attempts to access %SYSTEM32 is remapped from \windows\system32 to \windows\syswow64. This is a general behavior of running 32-bit applications on 64-bit windows.

I assume this thread is about running 64-bit python - you cannot load 32-bit freetype dll with 64-bit python app, nor 64-bit freetype dll with 32-bit python app.

from freetype-py.

from freetype-py.