| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Makes it easier to alter the setup for some action types
|
|
|
|
No idea how it seemingly worked without these changes.
|
|
Conflicts:
Makefile
apps/mudraw.c
pdf/pdf_write.c
win32/libmupdf-v8.vcproj
|
|
|
|
Rather than specifically checking for the nesting getting too deep and
hence throwing an error, the error handling should do this for itself.
Make it so that we spot the depth being too great in the fz_try() and
throw to the fz_catch().
|
|
Unused objects could cause problems with the sort order and picking
the object to start with. Now coped with.
If the hintstream object replaces another object that already had a
stream, pdf_open_raw_filter would get confused by the presence of a
stm_buf. Now fixed.
Fix a 64bit problem in page_objects_list_ensure, as well as tweaking
the code for readability.
When outputting single page files, we can end up with opts->start = 1
and this upset the offset calculating logic.
Insist on compacting the xref when linearising.
Thanks to Sebras and Zeniko for providing test cases. This commit
should (hopefully) stop the SEGVs, but there are still cases where
Acrobat doesn't think that the files output are "Optimised for Fast
Web View". I cannot see why.
|
|
|
|
|
|
Also delete the 'I' element to avoid the indexes and values disagreeing.
|
|
|
|
PDF documents that do not have a page tree will have zero pages.
Calling fz_count_pages() twice or more on those documents will have
pdf_load_page_tree() repeatedly trying to load the page tree, each
time leaking the page objects/refs arrays.
Thanks to Zeniko for pointing out this fix.
|
|
Previously fix 13943b92f10796efb175e769afe5b0aea85d879a introduced
continued rendering of further pages for documents where one page
failed to load. However, if the entire page tree was missing from a
PDF document then no display list would be obtained, yet MuPDF tried
to render the display list causing a null pointer dereference. Now,
check for a valid display list before trying to render it.
|
|
|
|
Thanks to Zeniko for pointing out this fix.
|
|
|
|
|
|
Previously the jpeg decoder state had to be fully initialized in order
to be freed when the jpeg decoder is closed, e.g. due to an error. Now,
signal that the decode state is initialized earlier, even if the state
has not been fully initialized, so that the state is freed.
|
|
|
|
Thanks to Zeniko for pointing out this fix.
|
|
Thanks to Zeniko for pointing out the inconsistency.
|
|
Thanks to Zeniko for pointing out this fix.
|
|
|
|
Thanks to Zeniko for pointing out that version as missing.
|
|
Thanks to Zeniko for pointing out this fix.
|
|
|
|
Previously we would run out of error stacks in the context and fail abruptly.
Now, throw an exception and hope for the best. At least this plugs any memory
leaks.
|
|
Sub functions that make up a stitching function can be evaluated with
the wrong number of inputs/outputs, so it is not necessary to throw an
exception if the number of inputs/outputs do not match when loading
sub functions.
|
|
The cmap table length counts how many entries there are currently in
the table. The table length was previously tested against USHRT_MAX
which is 65535. However, the desired value to compare with was 65536
which would be the maximum number of entries allowed in a cmap table.
All comparisons of the cmap table length are now using USHRT_MAX + 1.
|
|
Previously, during repair of a pdf, an object stream was loaded and an
attempt was made at repairing the objects stored inside the object
stream. Failure to repair the stream caused an exception which was not
handled by the code loading the object stream, it was just passed on.
This meant that the loaded object stream caused a memory leak. Now we
catch that exception, free the object stream and rethrow the exception.
|
|
There was a call to fz_drop_image() in the error handling code,
however the fz_storable freeing function was not yet set which
meant that the image was not freed. Instead call pdf_free_image()
to free the image.
|
|
|
|
Thanks to Zeniko for pointing out this fix.
|
|
|
|
|
|
|
|
|
|
pdf_write_document() may throw an exception and this was uncaught up
until now.
|
|
Once enough operands were push on top of the operand stack an
exception would be thrown. The exception handling ignored the
exception, printed a warning and continued processing the content
stream. Unfortunately the token was never consumed, so once the
interpreter retried parsing the stream it encountered the same token
again, causing the loop and thus a stack overflow. Now, make sure each
token is consumed before throwing a new exception thereby breaking the
eternal loop and letting pdfs with excessive operands be rendered,
albeit with both errors and a warning.
|
|
|
|
Out of range object numbers cause the repaired object to be
ignored. Out of range generation numbers are clamped to the
permitted range.
|
|
This is just a lexical change, no semantic change as
the MAXN and MAXM constants are equal.
|
|
The u modifier to to the ar replace command tells ar to only
insert those object files into a static library that are newer
than those already in the library (both having the same name).
Moreover ar only stores timestamps down to second accuracy.
This may cause situations where the object file already inside
the library is considered equal to a newly built object file
(which might include a new function) because their timestamps
differ only in the sub-second part. One of the apps might have an
object file that references this new function. Since the static
library retains the old object file there will be a linking error
when linking the app. Even re-running make will not fix the issue
since the static library will have its modification time updated
to a timestamp later than the newly built object file, which
means that ar will not be run again. The only option is to make
nuke and rebuild from scratch.
From now on, the u modifier to the ar replace command is removed.
This means that ar will rebuild static libraries without taking
timestamps of object files into account, to make sure that the
build never ends up in the situation described above.
|
|
|
|
|
|
|
|
|
|
|
|
|
