Has anyone tried updating LibHaru's Python bindings to Python 3.9 (64-bit)?

Question content

I'm running Python 3.9, 64-bit, and have used VS 2022 to compile libharu and some extensions into DLLs, including libpng. After adding minimal code adjustments to find the VS runtime DLL (libhpdf), the DLL can be loaded into Python. dll dependency and seems to work (only 5 .py files in the bundle) I've built a DLL with PTRACE enabled to track progress. C demos have also been dynamically built using this DLL and they all work, generating PDFs.

I'm trying to run the python demo example included in the binding, arc_demo.py Want to generate the same PDF file

I can say that everything works fine until the line where I add the documentation: pdf = HPDF_New (error_handler, NULL) Output similar to the trace obtained using the compiled C version of the example.

But... var "pdf" is not what HP_AddPage() expects, because when the next call is issued, the page is added page = HPDF_AddPage (pdf) I came across this: **ctypes.ArgumentError: Parameter 1: <class>: int too long to convert**</class>

I think this may have something to do with the original bindings being built and tested with 32-bit only. Another suspect is ported ctypes.

So now I'm modifying the bindings, mainly hpdf.py. Currently struggling with Python to DLL intercommunication, checking that ctypes handles things as expected. Convert *pdf * to c_void_p using byref , ... no luck. If the call is done via ref(c_void_p(pdf)) I get rid of the error, but I am not able to properly access the contents of the HPDF_Doc structure

Any suggestions? Might you be able to help? Comparative approaches to debugging Python using a C-based DLL?

Thanks, Ignacio

PS: Classes will eventually be written for Haru PDF internals. But this happens after I am able to run the python example without errors.

Correct answer

ctypesinterface in if/python/hpdf.py is not defined for all functions.argtypes. For 64-bit handles and pointers, it is especially important to define the correct parameter types for each function. The original developers may not have understood this, as shown by the switch from the windll to the cdll interface. windll Uses the __stdcall calling convention and requires knowledge of parameter sizes.

For example, hpdf_doc is defined as hpdf_handle, which is defined as ctypes.c_void_p. This is a 64-bit pointer on a 64-bit operating system. hpdf_new and hpdf_addpage are defined as:

#hpdf_doc hpdf_new (hpdf_error_handler user_error_fn, void *user_data)
hpdf_new=haru.hpdf_new
hpdf_new.restype=hpdf_doc

#hpdf_page hpdf_addpage (hpdf_doc pdf)
hpdf_addpage=haru.hpdf_addpage
hpdf_addpage.restype=hpdf_page

ctypes Assume the argument passed to hpdf_addpage is c_int since to has no argtypes. The handle value is >32 bits, hence the error. Ideally, all functions should explicitly declare their argument types so that ctypes can type check and correctly marshal (convert) arguments from python objects to c types, for example:

HPDF_AddPage.argtypes = HPDF_Doc,  # must be a list or tuple...comma makes this a 1-tuple.
HPDF_New.argtypes = HPDF_Error_Handler, c_void_p

Please note that parameter types must be based on ctypes types. You must carefully keep track of the arguments and declare .argtypes for each function.

The above is the detailed content of Has anyone tried updating LibHaru's Python bindings to Python 3.9 (64-bit)?. For more information, please follow other related articles on the PHP Chinese website!