| 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.
|
|
|
|
|
|
And use the same enum for both the internal bidi code and the layout code.
|
|
Add code to convert to and from fz_text_language codes from
ISO 639 language strings. No validation is carried out.
|
|
We move to using bidirectional "levels" throughout. This should
give us better behaviour vis-a-vis nested l2r/l2r text. This
also allows us to carry xps levels throughout with no loss of
information.
This also avoids the need to special case numbers.
We accordingly carry more information into fz_text.
As well as wmode, also hold additional details about the text spans.
We now include the directionality of the bidi level text (either as
derived from bidi code, or from the original document (e.g. xps)),
the directionality of text (as specified in the original document
(e.g. html)), and the language of the text (if specified in the
original document).
|
|
|
|
|
|
The scissor argument is an optional (potentially NULL) rectangle
that can give hints to devices about the area that can be scissored.
This is used by the draw device and display list device to minimize
the size of temporary clip mask buffers.
The scissor rectangle, if used, must have been transformed by the
current transform matrix.
|
|
Match naming of fz_moveto/lineto etc for paths.
|
|
Use the flags when selecting a fallback font.
|
|
|
|
We can now group all clipped text into one fz_text object and simplify
the device interface.
|
|
|
|
|
|
Don't rely on having to run the page once with an identity transform
before being able to load the links.
|
|
For use in a later link parsing refactoring commit.
|
|
|
|
|
|
Make fz_link reference counting threadsafe.
Remember to free dests of GOTO links. Accordingly, ensure that XPS
does not create links with uninitialised dests.
|
|
|
|
|
|
Bug 696061 showed GhostXPS crashing with a SEGV. Checking MuPDF
showed that a fix had already been applied here, but Memento
shows that the fix was causing a leak.
We therefore patch the leak here.
|
|
Add fz_has_permission function to fz_document.
Add fz_lookup_metadata function to fz_document.
Remove fz_meta function from fz_document.
|
|
Firstly, we make the definition of the path structures local to
path.c. This is achieved by using an fz_path_processor function to
step through paths enumerating each section using callback functions.
Next, we extend the internal path representation to include other
section types, including quads, beziers with common control points
rectangles, horizontal, vertical and degenerate lines. We also roll
close path sections up into the previous sections commands.
The hairiest part of this is that fz_transform_path has to cope with
changing the path commands depending on the matrix. This is a
relatively rare operation though.
|
|
|
|
fz_open_file does not return NULL on failure -- it throws an exception!
|
|
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_*.
|
|
|
|
Disallow modification of shared fz_path and fz_text objects.
They should follow a create once, consume often pattern, and as such should
be immutable once created.
|
|
Starting with commit 2f4cdd4fd0580e3121773e89a7c6e7a9e1ffa54b,
xps_read_part zero-terminates the read data. It does however also count
that zero-terminator to the part's size which confuses callers handling
non-text data.
|
|
Commit 5add23c7233c3f34fdfa6387873b1d3bdb93e1d6 and commit
2f4cdd4fd0580e3121773e89a7c6e7a9e1ffa54b introduced three memory leaks
which only appear in error cases:
* unzip.c leaks if a ZIP archive uses a compression method other than
store or Deflate
* xps-zip.c leaks if fz_open_archive_with_stream throws for broken
ZIP archives
* xps-zip.c leaks also if a piece of a split file is missing
|
|
|
|
|
|
Add a whitespace preserving mode, for future use with XHTML.
Also parse XHTML entities. This is not strictly according to spec,
but for properly formed XML documents it should not matter.
|
|
|
|
Adobe Reader and Microsoft XPS viewer differ in their handling of
non-empty dashed strokes where the phase is 0: Adobe Reader considers
these to be faulty and omits them while Microsoft XPS Viewer renders
them the same as an empty dash (i.e. solid).
This patch makes Fitz no longer render such strokes and ensures that
MuXPS never emits them so that the desired behavior results (this is
the easier implementation since XPS rendering code renders stroked
paths in a single location whereas PDF rendering does it all over the
place).
See https://code.google.com/p/sumatrapdf/issues/detail?id=2339 for a
testcase.
|
|
xps_deobfuscate_font_resource assumes that a font has at least 32 bytes
of data required for deobfuscation. If a broken font has less data,
the buffer overflows.
Also, the data buffer is leaked when fz_new_font_from_buffer throws.
|
|
Per the ZIP specification, ZIP64 values are only used if the original
value was -1 (i.e. 0xFFFF for 16-bit and 0xFFFFFFFF for 32-bit values).
Microsoft's XPS viewer behaves according to specification and so
should MuXPS.
|
|
I think this is non-standard, but some applications seem to use it.
The email app on Android uses it, despite the fact the original email
actually embedded it as application/octet-stream. I guess the email app
is looking at the filename.
|
|
There are two issues where variables may be used unitialized:
* extract_exif_resolution fails to set xres and yres for JPEG images if
there's no valid resolution unit (mainly affects XPS documents)
* xps_measure_font_glyph uses hadv and vadv unitialized if the glyph id
isn't valid (i.e. if FT_Get_Advance fails)
|
|
fts_5904.xps and fts_5905.xps use namespace prefixes.
Work around that by ignoring the namespace prefix for tag names.
A more robust solution would be to expand or record the tag and
attribute namespaces in the fz_xml node structure, but that's a
overkill for our current needs.
|
|
|
|
Many times, the idiom p.x = x; p.y = y; fz_transform_point() is used.
This function should simplify that use case by both initializing and
transforming the point in one call.
|
|
xps_parse_color happily reads more than FZ_MAX_COLORS values out of a
ContextColor array which overflows the passed in samples array.
Limiting the number of allowed samples to FZ_MAX_COLORS and make sure
to use that constant for all callers fixes the problem.
Thanks to Jean-Jamil Khalifé for reporting and investigating the issue
and providing a sample exploit file.
|
|
We define a document handler for each file type (2 in the case of PDF, one
to handle files with the ability to 'run' them, and one without).
We then register these handlers with the context at startup, and then
call fz_open_document... as usual. This enables people to select the
document types they want at will (and even to extend the library with more
document types should they wish).
|
|
This bug shows 2 problems with our data handling.
Firstly, if a zip file entry has less data in the stream than it
is declared to have, we would leave the end of the data uninitialised.
We now put out a warning, and blank it with zeros.
Secondly, if the PNG decompression fails to decode enough data, we
don't notice. Now we give a warning and blank the remaining pixels.
|
|
These warnings are caused by casting function pointers to void*
instead of proper function types.
|
|
Some warnings we'd like to enable for MuPDF and still be able to
compile it with warnings as errors using MSVC (2008 to 2013):
* C4115: 'timeval' : named type definition in parentheses
* C4204: nonstandard extension used : non-constant aggregate initializer
* C4295: 'hex' : array is too small to include a terminating null character
* C4389: '==' : signed/unsigned mismatch
* C4702: unreachable code
* C4706: assignment within conditional expression
Also, globally disable C4701 which is frequently caused by MSVC not
being able to correctly figure out fz_try/fz_catch code flow.
And don't define isnan for VS2013 and later where that's no longer needed.
|
