Module ffi.mupdf
MuPDF API
This is a FFI wrapper for what was a Lua-based API in the past Some kind of C wrapper is needed for muPDF since muPDF uses a setjmp/longjmp based approach to error/exception handling.
That's one of the very few things we can't deal with using LuaJIT's FFI.
Functions
| openDocument (filename) | Opens a document. |
| renderImage (data, size, width, height) | Renders image data. |
| renderImageFile (filename, width, height) | Renders image file. |
| scaleBlitBuffer (bb, width, height) | Scales a blitbuffer. |
Issues
| ffi.mupdf-fixme20 |
: Don't make cache_size too low, at least not until we bump MµPDF, |
Functions
- openDocument (filename)
-
Opens a document.
Parameters:
- filename
- renderImage (data, size, width, height)
-
Renders image data.
Parameters:
- data
- size
- width
- height
- renderImageFile (filename, width, height)
-
Renders image file.
Parameters:
- filename
- width
- height
- scaleBlitBuffer (bb, width, height)
-
Scales a blitbuffer.
MµPDF's scaling is of much better quality than the very naive implementation in blitbuffer.lua. (see fzscalepixmap_cached() in mupdf/source/fitz/draw-scale-simple.c). Same arguments as BlitBuffer:scale() for easy replacement.
Unlike BlitBuffer:scale(), this ignores the blitbuffer's rotation (i.e., where possible, we simply wrap the BlitBuffer's data in a fitz pixmap, with no data copy, so the buffer's native memory layout is followed). If you actually want to preserve the rotation, you'll have to fudge with the width & height arguments and tweak the returned buffer's rotation flag, or go through a temporary copy to ensure that the buffer's memory is laid out accordingly.
Parameters:
- bb
- width
- height We need first to convert our BlitBuffer to a pixmap
Issues
- ffi.mupdf-fixme20
-
: Don't make cache_size too low, at least not until we bump MµPDF,
as there's a pernicious issue that corrupts its store cache on overcommit on old versions. c.f., https://github.com/koreader/koreader/issues/7627 (FZ_STORE_DEFAULT is 256MB, we used to set it to 8MB). And when we bump MµPDF, it'll likely have *more* stuff to store in there, so, don't make that too low, period ;). NOTE: Revisit when we bump MµPDF by doing a few tests with the tracing memory allocators, as even 32MB is likely to be too conservative.