| Age | Commit message (Collapse) | Author |
|---|
|
|
|
_WIN32 is always defined on windows (it means the WinAPI is available).
_WIN64 is also defined on 64-bit targets.
This means the test for defined(_WIN32) || defined(_WIN64) is redundant,
since if _WIN64 is defined, then _WIN32 is always also defined.
MSC_VER is only defined for MSVC, so split the ifdef sections in
include/fitz/system.h into separate MSVC and WIN32 parts so that
we can build with MinGW and other non-MSVC compilers on windows.
|
|
|
|
The mupdf build included an implimentation of the pkcs7 functions that
are needed for signing documents and verifying signatures, the
implementation being either an openssl-based one, or a stub that returned
errors. This commit removes the pkcs7 functions from the main mupdf
library.
For the sake of verification, there wasn't really a need for the pkcs7
functions to be part of mupdf. It was only the checking function that used
them. The checking function is now provided as a helper, outside of the
main build. The openssl-based pkcs7 functions area also supplied as a
helper. Users wishing to verify signatures can either use the checking
function directly, or use the source on which to base their own.
Document signing requires more integration between mupdf and pkcs7
because part of the process is performed at time of signing and part when
saving the document. Mupdf already had a pdf_pkcs7_signer object that
kept information between the two phases. That object has now been extended
to include the pkcs7 functions involved in signing, and the signing
function now requires such an object, rather than a file path to a
certificate. The openssl-based pkcs7 helper provides a function that, given
the path to a certificate, will return a pdf_pkcs7_signer object.
The intention is that different implementations can be produced for
different platforms, based on cryptographic routines built into the
operationg system. In each case, for the sake of document signing, the
routines would be wrapped up as a pdf_pkcs7_signer object.
|
|
Rename HAVE_PTHREADS to HAVE_PTHREAD to match naming of other defines,
where the macro is named after the library that is linked.
|
|
|
|
|
|
It seems likely that we'll want people to able to use the MuPDF
C API as well as the MuOfficeLib helper lib. We therefore need
a way to get fz_context and fz_document values out of MuOfficeLib.
Potential problems exist with people calling MuPDF C API functions
using an fz_context that is in use elsewhere. Similarly, if an
fz_document is in use in a background thread (for instance in a
page render), we need to ensure that it can't be used at the same
time elsewhere.
We therefore provide MuOffice{Lib,Doc,Page}_run functions that
allow this to happen safely. This largely insulates callers from the
complexities of having to clone contexts etc, it safely ensures
that exceptions cannot be propogated beyond the topmost fz_try/
fz_catch, and it ensures that appropriate locking is used.
|
|
|
|
|
