| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This silences the many warnings we get when building for x64
in windows.
This does not address any of the warnings we get in thirdparty
libraries - in particular harfbuzz. These look (at a quick
glance) harmless though.
|
|
TIFF 5.0 uses a slightly laxer set of rules for TIFF decode.
Specifically, when we hit the maximum code, we are not required
to send a clear code immediately, but it can overrrun.
We don't bother storing codes > 12 bits, because they can never
be used. This avoids the need to extend the table.
|
|
|
|
|
|
Purge several embedded contexts:
Remove embedded context in fz_output.
Remove embedded context in fz_stream.
Remove embedded context in fz_device.
Remove fz_rebind_stream (since it is no longer necessary).
Remove embedded context in svg_device.
Remove embedded context in XML parser.
Add ctx argument to fz_document functions.
Remove embedded context in fz_document.
Remove embedded context in pdf_document.
Remove embedded context in pdf_obj.
Make fz_page independent of fz_document in the interface.
We shouldn't need to pass the document to all functions handling a page.
If a page is tied to the source document, it's redundant; otherwise it's
just pointless.
Fix reference counting oddity in fz_new_image_from_pixmap.
|
|
Rename fz_close to fz_drop_stream.
Rename fz_close_archive to fz_drop_archive.
Rename fz_close_output to fz_drop_output.
Rename fz_free_* to fz_drop_*.
Rename pdf_free_* to pdf_drop_*.
Rename xps_free_* to xps_drop_*.
|
|
Ghostscript's LZW decoder accepts invalid LZW code 4096 if it's
immediately followed by LZW clear code 256 for handling files produced
by certain broken encoders and other common PDF readers seem to have
similar error handling. This patch makes MuPDF tolerate such broken
files as well.
|
|
Currently fz_streams have a 4K buffer within their header. The call
to read from a stream fills this buffer, resulting in more data being
pulled from any underlying stream than we might like. This causes
problems with the forthcoming 'leech' filter.
Here we simplify the fields available in the public stream header.
No specific buffer is given; simply the read and write pointers.
The underlying 'read' function is replaced by a 'next' function
that makes the next block of data available and returns the first
character of it (or EOF).
A caller to the 'next' function should supply the maximum number of
bytes that it knows it will need (possibly not now, but eventually).
This enables the underlying stream to efficiently decode just enough.
The underlying stream is free to return fewer, or a greater number
if it wants to.
The exact size of the 'block' of data returned will depend on the
filter in use and (possibly) the data therein.
Callers can get the currently available amount of data by calling
fz_available (but again should pass the maximum amount of data they know
they will need). The only time this will ever return 0 is if we have
hit EOF.
|
|
|
|
Content streams may contain multiple inline images compressed as LZW
data. The LZW filter used for such inline images might in some cases
be closed in a state where less than 8 bits remain unread. The parent
stream remembers that number (in stream->avail) and uses it again
when reading the next inline image instead of resetting the remaining
bit count when reading the next entire byte after the first inline image
(or resetting it when closing the LZW stream as this patch does).
|
|
|
