| Age | Commit message (Collapse) | Author |
|---|
|
Not used, other than for the convenience of editing/searching.
|
|
In the JNI code, we attach a cloned context onto each thread
we encounter in thread local storage. When the thread shuts
down, we should destroy that context.
This can theoretically be achieved on pthreads by using the
destructor registered to the tls slot. I have yet to see
Android ever actually call this destructor yet though.
No such mechanism exists for windows thread, so we'll just leak
here for now. There is a potential fix for this, but it's
hairy, so details are left in a comment in the code.
|
|
Now linear time rather than n^2.
|
|
When we destroy a PDF document, currently we bin everything
from the store. Instead, drop just the objects that are
specifically tied to that document.
Any object tied to the document has a pdf_obj with the
required document pointer in it as the key.
|
|
|
|
If Java code creates e.g. a Document object and later calls
Document.destroy() and then keeps using the Document object
the library would end up crashing because the native pointer
was null. This case rather special case is now handled.
|
|
The underlying pdf_dict_put() converts into a null object.
|
|
But do not check it twice.
|
|
|
|
|
|
This case can be handled gracefully since commit
2d3eca6dec6b8fc7a169b3fc357904069df6b6c4.
|
|
The store is effectively a list of items, where each item is a
(key, value) pair. The design is such that we can easily get
into the state where the only reference to a value is that held
by the store. Subsequent references can then be generated by
things being 'found' from within the store.
While the only reference to an object is that held by it being
a value in the store, the store is free to evict it to save
memory.
Images present a complication to this design; images are stored
both as values within the store (by the pdf agent, so that we
do not regenerate images each time we meet them in the file),
and as parts of the keys within the store.
For example, once an image is decoded to give a pixmap, the
pixmap is cached in the store. The key to look that pixmap up
again includes a reference to the image from which the pixmap
was generated.
This means, that for document handlers such as gproof that do
not place images in the store, we can end up with images that
are kept around purely by dint of being used as references in
store keys. There is no chance of the value (the decoded pixmap)
ever being 'found' from the store as no one other than the
key is holding a reference to the image required. Thus the
images/pixmaps are never freed until the store is emptied.
This commit offers a fix for this situation.
Standard store items are based on an fz_storable type. Here we
introduce a new fz_key_storable type derived from that. As well
as keeping track of the number of references a given item has
to it, it keeps a separate count of the number of references a
given item has to it from keys in the store.
On dropping a reference, we check to see if the number of
references has become the same as the number of references from
keys in the store. If it has, then we know that these keys can
never be 'found' again. So we filter them out of the store,
which drops the items.
|
|
When invoking gs, pass in -gWIDTHxHEIGHT -dFitPage.
This avoids any possible mismatch betwen the page size we
expect and the page size that gs returns.
|
|
This is useful when a TIFF image is grayscale but
supplies more than a single component per sample.
|
|
|
|
|
|
The JNI interface throws exceptions of its own,
keep those instead of replacing them.
|
|
|
|
|
|
Page_getSeparation() does the corresponding conversion.
|
|
Also there is no need to check self pointer since JVM does not
even call the JNI binding for null pointers.
|
|
|
|
This makes debugging much simpler.
|
|
This avoids a symbol clash when using scripts/destatic.sh
|
|
We call Memento_addRef etc in fz_keep_impXX functions, so
don't call them in the callers too.
|
|
|
|
pages after use.
|
|
|
|
|
|
This commit puts in the UI for drawing with color
and line thickness. But it does not yet save this to
the document.
|
|
|
|
add five icons to the File toolbar (not yet functioning)
add a dialog to collect the password from the user for protected documents.
|
|
|
|
Getting a backtrace out with missing functions makes the
backtrace much less useful. Some backtrace routines (such
as that used by Memento on Android) are incapable of
resolving static functions.
We therefore provide 2 scripts (scripts/destatic.sh and
scripts/restatic.sh) that respectively remove and replace
the 'static' from function definitions.
The scripts do not affect "static inline" or "static const"
definitions, and they are are restricted to working in the
source directory (excluding source/tools), thirdparty/mujs
and the platform/{java,android} directories.
The transformed source should NOT be checked in.
To avoid problems with clashing symbols, some functions are
renamed or tweaked slightly in this patch.
|
|
|
|
Work around the problems in that androids logging only works
in whole lines by buffering until we have one.
Also, androids logging goes to a circular buffer that loses
data when it overflows. Hack around this by adding a 1ms sleep
after every line output.
|
|
|
|
Thanks to Sebastian for pointing out that the demangling code
wants a malloced block, cos it might realloc it. Drop back to
the dumber version.
|
|
Call Memento_fin rather than piecemeal functions to
ensure we get full details when available.
Ensure we link with the required lib for backtracing to
work in Memento builds.
|
|
Add backtrace abilities, and fix missing return value from
android logging.
|
|
Without this we don't pick up FZ_ENABLE_GPRF from the header
correctly.
|
|
The upshot of debugging this is that:
1) We can't trust the FontBBox. Certainly it appears that no
one else trusts it.
2) We can't trust the d1 values in all cases, as it can lead to
use rendering glyphs far larger than we'd want to.
So we have the compromise used here.
1) We never clip to the FontBBox.
2) If the FontBBox is invalid, then we calculate the bbox
from the contents of the data streams.
3) If the FontBBox is valid, and the d1 rectangle given
does not fit inside it, then we calculate the bbox from
the contents of the data streams.
This could theoretically produce problems with glyphs that have
much more content than they actually need, and rely on the d1
rect to clip it down to sanity. If the FontBBox is invalid in
such fonts, we will go wrong.
It's not clear to me that this will actually work in Acrobat/
Foxit/gs etc either, so we defer handling this better until we
actually have an example.
Tested with bug 694952, and bug 695843 which were the last 2 in
this area.
|
|
|
|
The gproof device should make use of the output intent if
it exists.
|
|
In the gproof pipeline MuPDF first generates a skeleton file
with page sizes in. Then it gets gs to generate individual
pages for that file.
In one case, the pdf file has a height of 203.4 - at 300dpi
that's 847.5 device pixels. MuPDF was rounding that up to
848pixels, whereas gs was rounding it down to 847, causing
an error on load.
Adjust MuPDFs skeleton file generation so that it matches
gs.
|
|
MSVC is obviously more picky than linux in some cases.
|
|
Windows requires sys/stat.h to be included.
|
|
|
|
|
|
|
