Difference: MupdfCppWrappers (16 vs. 17)

Revision 172020-05-05 - JulianSmith

Line: 1 to 1

META TOPICPARENT	name="JulianSmith"

Changed:

<
<

Auto-generated mupdf C++ wrappers

>
>

Auto-generated C++ and Python APIs for mupdf.

Status

Changed:

<
<

As of 2020-4-28:

>
>

As of 2020-5-4:

Changed:

<
<

We generate class wrappers for all fz structs.

>
>

C++

C++ API is generated by mupdf:scripts/mupdfwrap.py, which uses python-clang.
We require clang-6 or clang-7.
We generate C++ class wrappers for all fz structs.

We auto-detect fz_*() fns suitable for wrapping as constructors, methods or static methods.
Some generated classes have auto-generated support for iteration.

Deleted:

<
<

We add various custom wrappers for fz_*() fns.

We add various custom methods/constructors.

Changed:

<
<

We provide access via wrapper classes to 686 fz_*() fns.
There are a total of 888 fz_*() functions. Most of the omitted functions don't take struct args, e.g. fz_strlcpy(). Of the remaining, some use fz_* enums (which we don't yet wrap); see https://ghostscript.com/~julian/mupdf/platform/c++/fn_usage.txt for more information.

>
>

We provide access via wrapper classes to 690 fz_*() fns.
There are a total of 890 fz_*() functions. Most of the omitted functions don't take struct args, e.g. fz_strlcpy(). Of the remaining, some use fz_* enums (which we don't yet wrap); see https://ghostscript.com/~julian/mupdf/platform/c++/fn_usage.txt for more information.

Python

Python API is generated by running SWIG on the C++ API's header files.
Python API is enough to allow implementation of mutool in Python - see mupdf:scripts/mutool.py and mupdf:scripts/mutool_draw.py.

We work with swig-3 or swig-4.

Changed:

<
<

We work with clang-6 or clang-7.
We work on peeved and jules-laptop.

>
>

General

We work on nuc1 and peeved and jules-laptop.
We require:
- python-clang (version 6 or 7)
- python3-dev (version 3.6 or later)
- swig (version 3 or 4)

Comments

Line: 31 to 44

https://ghostscript.com/~julian/pydoc/mupdf.html

Added:

>
>

mutool.py

mudpdf:scripts/mutool*.py are a Python re-implementation of the mutool application.

They do not use threads, or the include/mupdf/pdf/ functionality.

Files

Auto-generated C++ headers and implementation files, plus test outputs (.html files have syntax-colouring):

Line: 48 to 69

The generated Python module is tested by the (rather hacky) test_mupdfcpp_swig() function in mupdfwrap.py. For convenience, this function and its output can be viewed in https://ghostscript.com/~julian/mupdf/platform/python

Deleted:

<
<

In mupdfwrap.py:

See "Todo:" section in comment near top, for status of various todo items.

Integration with mupdf git.

Deleted:

<
<

In mupdf, have added various things:

    mupdf/
        build/

Changed:

<
<

release-shared/ libmupdf.so [generated file] libmupdfcpp.so [generated file, implements C++ API] debug-shared/

>
>

shared-release/

libmupdf.so [generated file] libmupdfcpp.so [generated file, implements C++ API]

Added:

>
>

mupdf.py [generated file, implements Python API] _mupdf.so [generated file, implements Python API internals] shared-debug/ libmupdf.so libmupdfcpp.so [implements C++ API] mupdf.py [implements Python API] _mupdf.so [implements Python API internals]

platform/ c++/ implementation/

Line: 75 to 94

mupdf/ *.h [generated files] python/

Changed:

<
<

mudf.py [generated file, implements Python API] _mupdf.so [generated file, implements Python API internals]

>
>

mupdfcpp_swig.cpp [generated by SWIG] mupdf_swig.i [generated by mupdfwraw.pynput to SWIG]

scripts/ mupdfwrap.py jlib.py

Added:

>
>

mutool.py mutool_draw.py

Line: 98 to 119

Changed:

<
<

Have also added crude support for building mupdf as a shared object, which is required for integrating with the SWIG python module. At the moment, mupdfwrap.py drives this to build mupdf.so.

>
>

View topic | History: r20 < r19 < r18 < r17 | More topic actions...