Difference: MupdfCppWrappers (1 vs. 24)

Revision 242021-02-09 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"
Line: 143 to 143
 
  • PyMuPDF has more information about links - fitz.LINK_GOTO, LINK_GOTOR, fitz.LINK_LAUNCH, fitz.LINK_URI.
  • PyMuPDF has abstraction for writing image files which calls fz_save_pixmap_as_png() or fz_save_pixmap_as_pnm() etc, depending on the filename.
  • PyMuPDF can copy a TOC into a PdfDocument.
Added:
>
>
  • Looks like PyMuPDF has fairly elaborate support for redactions. Makes use of pdf_redact_page() and then writes on top of the redaction?
  PyMuPDF: https://github.com/pymupdf/PyMuPDF-Utilities/blob/master/demo/demo.py

Revision 232021-02-05 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"
Line: 132 to 132
 
Changed:
<
<
    • added Document::lookup_metadata() method overload that returns std::string.
    • added const std::vector<std::string> metadata_keys
    • changed Outline iteration to include depth information
>
>
    • Added Document::lookup_metadata() method overload that returns std::string.
    • added global const std::vector<std::string> metadata_keys.
    • Changed Outline iteration to include depth information.
 
    • Fixed ref-counting in Page::load_links().
    • fixed Page::search_page() to return std::vector.
Changed:
<
<
    • added python wrapper for PdfDocument::page_write() out-params
    • Using improved scheme for wrapping functions/methods with out-params - instead of trying to use SWIG's typemaps, which are very clumy in the context of mupdfwrap.py and seemingly more designed for custom-written .i files, we now use simple C functions to package up out-params into a struct.
    • Make mupdf.Buffer.buffer_extract() return raw C (data, size) values; don't convert into a Python bytes, because can't find a way to convert a bytes back into (data, size) suitable for passing to mupdf.Stream constructor. [This allows us to mimic PyMuPDF-Utilities/demo/pdf-converter.py].
>
>
    • Added python wrapper for PdfDocument::page_write() out-params
    • Using improved scheme for wrapping functions/methods with out-params - instead of trying to use SWIG's typemaps, which are very clumy in the context of mupdfwrap.py and seemingly more designed for custom-written .i files, we now use simple auto-generated C functions to package up out-params into a struct, then extract into a tuple in auto-generated Python.
    • Provide two wrappers for mupdf.Buffer.buffer_extract() - return raw C (size, data) values or return a Python bytes. The former can be used to construct a mupdf.Stream constructor (doesn't seem possible to convert a Python bytes back into (size, data)). [This allows us to mimic PyMuPDF-Utilities/demo/pdf-converter.py.]
 
  • PyMuPDF has more information about links - fitz.LINK_GOTO, LINK_GOTOR, fitz.LINK_LAUNCH, fitz.LINK_URI.
  • PyMuPDF has abstraction for writing image files which calls fz_save_pixmap_as_png() or fz_save_pixmap_as_pnm() etc, depending on the filename.
Added:
>
>
  PyMuPDF: https://github.com/pymupdf/PyMuPDF-Utilities/blob/master/demo/demo.py

Revision 222021-02-04 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"
Line: 6 to 6
 

Status

Changed:
<
<
As of 2021-2-2:
>
>
As of 2021-2-4:
 
Line: 137 to 137
 
    • changed Outline iteration to include depth information
    • Fixed ref-counting in Page::load_links().
    • fixed Page::search_page() to return std::vector.
Added:
>
>
    • added python wrapper for PdfDocument::page_write() out-params
    • Using improved scheme for wrapping functions/methods with out-params - instead of trying to use SWIG's typemaps, which are very clumy in the context of mupdfwrap.py and seemingly more designed for custom-written .i files, we now use simple C functions to package up out-params into a struct.
    • Make mupdf.Buffer.buffer_extract() return raw C (data, size) values; don't convert into a Python bytes, because can't find a way to convert a bytes back into (data, size) suitable for passing to mupdf.Stream constructor. [This allows us to mimic PyMuPDF-Utilities/demo/pdf-converter.py].
 
  • PyMuPDF has more information about links - fitz.LINK_GOTO, LINK_GOTOR, fitz.LINK_LAUNCH, fitz.LINK_URI.
  • PyMuPDF has abstraction for writing image files which calls fz_save_pixmap_as_png() or fz_save_pixmap_as_pnm() etc, depending on the filename.
Line: 223 to 226
 -- Julian Smith - 2020-03-04

Comments

Deleted:
<
<
<--/commentPlugin-->

Revision 212021-02-02 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"
Added:
>
>
 

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

Status

Changed:
<
<
As of 2020-5-11:
>
>
As of 2021-2-2:
  Customer page:
Line: 121 to 127
 
Added:
>
>

Comparison with PyMuPDF

  • Am writing equivalent code to some example programmes in https://github.com/pymupdf/PyMuPDF-Utilities.
  • Method names are usually different, because PyMuPDF uses its own names instead of basing names on the underlying MuPDF API.
  • Have made various additions/fixes to mypdfwrap.py (for details see: https://git.ghostscript.com/?p=user/julian/mupdf.git;a=summary)
    • added Document::lookup_metadata() method overload that returns std::string.
    • added const std::vector<std::string> metadata_keys
    • changed Outline iteration to include depth information
    • Fixed ref-counting in Page::load_links().
    • fixed Page::search_page() to return std::vector.
  • PyMuPDF has more information about links - fitz.LINK_GOTO, LINK_GOTOR, fitz.LINK_LAUNCH, fitz.LINK_URI.
  • PyMuPDF has abstraction for writing image files which calls fz_save_pixmap_as_png() or fz_save_pixmap_as_pnm() etc, depending on the filename.

PyMuPDF: https://github.com/pymupdf/PyMuPDF-Utilities/blob/master/demo/demo.py

Equivalent code using mupdfwrap:

#! /usr/bin/env python3

import mupdf

import os
import sys


assert len(sys.argv) == 7
filename, page_num, zoom, rotate, output, needle = sys.argv[1:]
page_num = int(page_num)
zoom = int(zoom)
rotate = int(rotate)

document = mupdf.Document(filename)

print('')
print(f'Document {filename} has {document.count_pages()} pages.')
print('')
print(f'Metadata Information:')
print(f'mupdf.metadata_keys={mupdf.metadata_keys}')
for key in mupdf.metadata_keys:
    value = document.lookup_metadata(key)
    print(f'    {key}: {value!r}')
print('')

outline = mupdf.Outline(document)
for o in outline:
    print(f'    {" "*4*o.m_depth}{o.m_depth}: {o.m_outline.title()}')

if page_num > document.count_pages():
    raise SystemExit(f'page_num={page_num} is out of range - {filename} has {document.count_pages()} pages')

page = document.load_page(page_num)
links = page.load_links()
if links:
    print(f'Links on page {page_num}:')
    for link in links:
        if link.m_internal:
            print(f'    extern={mupdf.is_external_link(link.uri())}: {link.uri()}')
else:
    print(f'No links on page {page_num}')

trans = mupdf.Matrix.scale(zoom / 100.0, zoom / 100.0).pre_rotate(rotate)

pixmap = page.new_pixmap_from_page(trans, mupdf.Colorspace(mupdf.Colorspace.Fixed_RGB), alpha=False)

def save_pixmap(path):
    suffix = os.path.splitext(path)[1]
    if 0: pass
    elif suffix == '.pam':   pixmap.save_pixmap_as_pam(path)
    elif suffix == '.pbm':   pixmap.save_pixmap_as_pbm(path)
    elif suffix == '.pcl':   pixmap.save_pixmap_as_pcl(path, append=0, options=mupdf.PclOptions())
    elif suffix == '.pclm':  pixmap.save_pixmap_as_pclm(path, append=0, options=mupdf.PclmOptions())
    elif suffix == '.pdfocr':pixmap.save_pixmap_as_pdfocr(path, append=0, options=mupdf.PdfocrOptions())
    elif suffix == '.pkm':   pixmap.save_pixmap_as_pkm(path)
    elif suffix == '.png':   pixmap.save_pixmap_as_png(path)
    elif suffix == '.pnm':   pixmap.save_pixmap_as_pnm(path)
    elif suffix == '.ppm':   pixmap.save_pixmap_as_ppm(path)
    elif suffix == '.ps':    pixmap.save_pixmap_as_ps(path, append=0)
    elif suffix == '.psd':   pixmap.save_pixmap_as_psd(path)
    elif suffix == '.pwg':   pixmap.save_pixmap_as_pwg(path, append=0, pwg=mupdf.PwgOptions())
    else:
        raise Exception(f'Unrecognised output format: {path}')
save_pixmap(output)
hit_quads = page.search_page(needle, max=16)
print(f'search text {needle!r} found {len(hit_quads)} on the page')
for hit_quad in hit_quads:
    pixmap.invert_pixmap_rect(hit_quad.rect_from_quad().irect_from_rect())
save_pixmap(f'dl-{output}')
 
Added:
>
>
print('finished')
 

Revision 202020-09-25 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

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

Line: 6 to 6
  As of 2020-5-11:
Added:
>
>
Customer page:

 

C++

  • We generate C++ wrapper functions for most fz_ and pdf_ functions. These wrapper convert fz_ exceptions into C++ exceptions, and use auto-generated per-thread fz_context's.

Revision 192020-08-18 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

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

Line: 8 to 8
 

C++

Deleted:
<
<
  • C++ API is generated by mupdf:scripts/mupdfwrap.py, which uses python-clang.
  • We require clang-6 or clang-7.
 
  • We generate C++ wrapper functions for most fz_ and pdf_ functions. These wrapper convert fz_ exceptions into C++ exceptions, and use auto-generated per-thread fz_context's.
  • We generate C++ class wrappers for most fz_ and pdf_ structs.
  • We auto-detect fz_*() and pdf_*() fns suitable for wrapping as constructors, methods or static methods.
  • Some generated classes have auto-generated support for iteration.
  • We add various custom methods/constructors.
  • Wrapper class constructors and methods provide access to 1270 fz_*() and pdf_*() fns, out of a total of 1513 wrapped fz_*() and pdf_*() functions. Most of the omitted functions don't take struct args, e.g. fz_strlcpy().
Added:
>
>
  • The C++ API is built by mupdf:scripts/mupdfwrap.py. It requires clang-6 or clang-7, and python-clang.
 

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.
Changed:
<
<
  • We work with swig-3 or swig-4.
>
>
  • Building the Python API requires swig-3 or swig-4.
 

General

  • We work on nuc1 and peeved and jules-laptop.

Revision 182020-05-11 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

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

Status

Changed:
<
<
As of 2020-5-4:
>
>
As of 2020-5-11:
 

C++

  • C++ API is generated by mupdf:scripts/mupdfwrap.py, which uses python-clang.
  • We require clang-6 or clang-7.
Changed:
<
<
  • We generate C++ class wrappers for all fz structs.
  • We auto-detect fz_*() fns suitable for wrapping as constructors, methods or static methods.
>
>
  • We generate C++ wrapper functions for most fz_ and pdf_ functions. These wrapper convert fz_ exceptions into C++ exceptions, and use auto-generated per-thread fz_context's.
  • We generate C++ class wrappers for most fz_ and pdf_ structs.
  • We auto-detect fz_*() and pdf_*() fns suitable for wrapping as constructors, methods or static methods.
 
  • Some generated classes have auto-generated support for iteration.
  • We add various custom methods/constructors.
Changed:
<
<
  • 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.
>
>
  • Wrapper class constructors and methods provide access to 1270 fz_*() and pdf_*() fns, out of a total of 1513 wrapped fz_*() and pdf_*() functions. Most of the omitted functions don't take struct args, e.g. fz_strlcpy().
 

Python

Line: 32 to 32
 

Comments

Changed:
<
<
  • We use clang to extract doxygen-style comments, and propogate them into generated header files.
  • If swig is version 4+, we tell it to propogate comments into generated mupdf.py.
>
>
  • We use clang to extract doxygen-style comments, and propagate them into generated header files.
  • If swig is version 4+, we tell it to propagate comments into the generated mupdf.py.
  Here are Doxygen html representations of the mupdf C API and the generated mupdf C++ API:
Changed:
<
<
>
>
  And pydoc html representation of the generated mupdf.py API:
Changed:
<
<
>
>
 

mutool.py

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

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

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

Files

Line: 59 to 57
 
Changed:
<
<
Information about fz_*() fns that are not in the class-based API:
>
>
Information about fz_*() and pdf_*() fns that are not in the class-based API:
 

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
 
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.
>
>
 

Revision 162020-04-27 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Status

Changed:
<
<
As of 2020-4-24:
>
>
As of 2020-4-28:
 
  • We generate 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.
  • We add various custom wrappers for fz_*() fns.
  • We add various custom methods/constructors.
Changed:
<
<
  • We provide access via wrapper classes to 715 fz_*() fns.
  • There are a total of 935 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 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 work with swig-3 or swig-4.
  • We work with clang-6 or clang-7.
  • We work on peeved and jules-laptop.
 

Comments

Line: 58 to 61
 
    mupdf/
        build/

Changed:
<
<
shared/
>
>
release-shared/ libmupdf.so [generated file] libmupdfcpp.so [generated file, implements C++ API] debug-shared/
  libmupdf.so [generated file] libmupdfcpp.so [generated file, implements C++ API] platform/ c++/
Deleted:
<
<
Makefile
  implementation/ *.cpp [generated files] include/ mupdf/ *.h [generated files] python/
Deleted:
<
<
Makefile
  mudf.py [generated file, implements Python API] _mupdf.so [generated file, implements Python API internals] scripts/
Line: 90 to 94
 
    cd mupdf/
Changed:
<
<
./scripts/mupdf.py -b 0123 -t
>
>
./scripts/mupdfwrap.py -b all -t
 

Revision 152020-04-24 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Line: 19 to 19
 
  • We use clang to extract doxygen-style comments, and propogate them into generated header files.
  • If swig is version 4+, we tell it to propogate comments into generated mupdf.py.
Added:
>
>
Here are Doxygen html representations of the mupdf C API and the generated mupdf C++ API:

And pydoc html representation of the generated mupdf.py API:

 

Files

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

Revision 142020-04-24 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Added:
>
>

Status

As of 2020-4-24:

  • We generate 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.
  • We add various custom wrappers for fz_*() fns.
  • We add various custom methods/constructors.
  • We provide access via wrapper classes to 715 fz_*() fns.
  • There are a total of 935 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.

Comments

  • We use clang to extract doxygen-style comments, and propogate them into generated header files.
  • If swig is version 4+, we tell it to propogate comments into generated mupdf.py.

Files

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

Added:
>
>
Information about fz_*() fns that are not in the class-based API:

 These were generated by the mupdfwrap.py programme, which also runs g++ and SWIG to generate a Python module that gives a Python API:

Line: 57 to 80
 
Changed:
<
<
cd mupdf/platform/python make make test
>
>
cd mupdf/ ./scripts/mupdf.py -b 0123 -t
 
Deleted:
<
<
The makefiles build things by running ../../scripts/mupdfwrap.py.
 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.

Revision 132020-04-20 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

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

Changed:
<
<
>
>
  These were generated by the mupdfwrap.py programme, which also runs g++ and SWIG to generate a Python module that gives a Python API:
Changed:
<
<
>
>
 
Changed:
<
<
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 separately:

>
>
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.
  In mupdfwrap.py:

  • See "Todo:" section in comment near top, for status of various todo items.
Deleted:
<
<
The files linked to above are updated periodically (e.g. every 1-2 days), so don't pay particular attention to the date stamp below, which is for this twiki page alone.
 

Integration with mupdf git.

Line: 44 to 41
  Makefile mudf.py [generated file, implements Python API] _mupdf.so [generated file, implements Python API internals]
Added:
>
>
scripts/ mupdfwrap.py jlib.py
 

See:

Deleted:
<
<
 
Changed:
<
<
To build, ensure that julian-tools is checked out next to mupdf, then:
>
>
To build:
 
Line: 63 to 63
 
Changed:
<
<
The makefiles build things by running ../../../julian-tools/mupdfwrap.py.
>
>
The makefiles build things by running ../../scripts/mupdfwrap.py.
  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,

Revision 122020-04-16 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Line: 21 to 21
  The files linked to above are updated periodically (e.g. every 1-2 days), so don't pay particular attention to the date stamp below, which is for this twiki page alone.
Added:
>
>

Integration with mupdf git.

 
Changed:
<
<

mutool.py

>
>
In mupdf, have added various things:
 
Changed:
<
<
Python implementation of mutool.

As of 2020-4-3, this implements "trace", "convert" and "draw" sub-commands. It will have lots of bugs, but works in a few simple tests.

>
>
    mupdf/
        build/
            shared/
                libmupdf.so  [generated file]
                libmupdfcpp.so [generated file, implements C++ API]
        platform/
            c++/
                Makefile
                implementation/
                    *.cpp [generated files]
                include/
                    mupdf/
                        *.h [generated files]
            python/
                Makefile
                mudf.py [generated file, implements Python API]
                _mupdf.so [generated file, implements Python API internals]
  See:
Changed:
<
<
>
>

To build, ensure that julian-tools is checked out next to mupdf, then:

    cd mupdf/platform/python
    make
    make test

The makefiles build things by running ../../../julian-tools/mupdfwrap.py.

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.


  -- Julian Smith - 2020-03-04

Revision 112020-04-03 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Line: 24 to 24
 

mutool.py

Changed:
<
<
Python implementation of mutool. as of 2020-4-1, this only implements some of the "trace" sub-command. See:
>
>
Python implementation of mutool.
 
Changed:
<
<
* https://git.ghostscript.com/?p=user/julian/julian-tools.git;a=blob;f=mutool.py;hb=HEAD
>
>
As of 2020-4-3, this implements "trace", "convert" and "draw" sub-commands. It will have lots of bugs, but works in a few simple tests.

See:

 
Added:
>
>
  -- Julian Smith - 2020-03-04

Revision 102020-04-01 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Line: 22 to 22
 The files linked to above are updated periodically (e.g. every 1-2 days), so don't pay particular attention to the date stamp below, which is for this twiki page alone.
Added:
>
>

mutool.py

Python implementation of mutool. as of 2020-4-1, this only implements some of the "trace" sub-command. See:

* https://git.ghostscript.com/?p=user/julian/julian-tools.git;a=blob;f=mutool.py;hb=HEAD

 -- Julian Smith - 2020-03-04

Comments

Revision 92020-03-26 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Line: 12 to 12
  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 separately:
Changed:
<
<
>
>
 

In mupdfwrap.py:

Revision 82020-03-25 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Changed:
<
<
Generated wrappers:
>
>
Auto-generated C++ headers and implementation files, plus test outputs (.html files have syntax-colouring):
 
Deleted:
<
<
 
Changed:
<
<
These were generated by:
>
>
These were generated by the mupdfwrap.py programme, which also runs g++ and SWIG to generate a Python module that gives a Python API:
 
Added:
>
>
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 separately:

 In mupdfwrap.py:
Deleted:
<
<
  • See test_mupdfcpp_swig() function for example python code that uses the generated API.
 
  • See "Todo:" section in comment near top, for status of various todo items.

The files linked to above are updated periodically (e.g. every 1-2 days), so don't pay particular attention to the date stamp below, which is for this twiki page alone.

Revision 72020-03-24 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Line: 16 to 16
 
  • See test_mupdfcpp_swig() function for example python code that uses the generated API.
  • See "Todo:" section in comment near top, for status of various todo items.
Added:
>
>
The files linked to above are updated periodically (e.g. every 1-2 days), so don't pay particular attention to the date stamp below, which is for this twiki page alone.
 -- Julian Smith - 2020-03-04

Comments

Revision 62020-03-18 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Generated wrappers:

Changed:
<
<
>
>
  These were generated by:

Changed:
<
<
See test_mupdfcpp_swig() function for example python code that uses the generated API.
>
>
In mupdfwrap.py:

  • See test_mupdfcpp_swig() function for example python code that uses the generated API.
  • See "Todo:" section in comment near top, for status of various todo items.
  -- Julian Smith - 2020-03-04

Revision 52020-03-17 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Generated wrappers:

Added:
>
>
  These were generated by:

Added:
>
>
See test_mupdfcpp_swig() function for example python code that uses the generated API.
  -- Julian Smith - 2020-03-04

Revision 42020-03-13 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Line: 8 to 8
  These were generated by:
Changed:
<
<
>
>
 
Deleted:
<
<
Also this (very hacky at moment) script uses SWIG to generate python version of C++ API:

  -- Julian Smith - 2020-03-04

Revision 32020-03-06 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Line: 10 to 10
 
Added:
>
>
Also this (very hacky at moment) script uses SWIG to generate python version of C++ API:
 
Added:
>
>
  -- Julian Smith - 2020-03-04

Revision 22020-03-05 - JulianSmith

Line: 1 to 1
 
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Changed:
<
<
Article text.
>
>
Generated wrappers:
 
Changed:
<
<
Standard wrappers:

Using class template for exceptions:

>
>
  These were generated by:

Revision 12020-03-04 - JulianSmith

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="JulianSmith"

Auto-generated mupdf C++ wrappers

Article text.

Standard wrappers:

Using class template for exceptions:

These were generated by:

-- Julian Smith - 2020-03-04

Comments

<--/commentPlugin-->
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 2014 Artifex Software Inc