| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
These headers are already included by mupdf/fitz/system.h.
|
|
|
|
It's a C99ism.
|
|
Neatness doesn't override actually working.
This reverts commit efb5a38ca0bac3537ceaf3383681a518df133143.
|
|
Use that within gproof. The existing use of fz_read_line was broken
and was resulting in bad values for separations.
|
|
Get separation information out to the Java level.
|
|
|
|
Use an endian-ness independent method of reading, instead of byte swapping.
|
|
Easier than duplicating getopt for wchar_t, since we already
have windows specific functions to convert wchar_t strings.
|
|
|
|
|
|
|
|
Previously out of range phase values were accepted which led to overly
long loops when processing moveto. This could be triggered e.g. by
2222222222222222222 [ 4 6 ] 0 d in a content stream.
|
|
In preparation for a bugfix concerning path phase.
|
|
Previously all output values were used, causing buffer overflows.
Fixes one issue from bug 696012.
|
|
|
|
By default in MuPDF, when we render an axis aligned image, we
'gridfit' it. This is a heuristic used to improve the rendering
of tiled images, and avoid the background showing through on the
antialiased edges.
The general algorithm we use is to expand any image outwards so that
it completely covers any pixels that it touches any part of. This is
'safe' in that we never cause any pixels to not be covered that
should otherwise be so, and is important when we have images that are
aligned with (say) line art rectangles.
For gproof files though, this gives nasty results - because we have
multiple images tiled across the page all exactly abutting, in most
cases the edges will not be on exact integer coordinates. This means
we expand both images and 1 (destination) pixel is lost. This severely
hurts the rendering (in particular on text based pages).
We therefore introduce a new type of grid fitting, where we simply
align the edges of images to the closest integer pixel. This is safe
because we know that neighbouring images will be adjusted identically
and edges will stay coincident.
We enable/disable this behaviour through a new device flag, and make
the gproof interpreter set/clear this flag when generating the page -
thus normal rendering is unaffected.
We *could* have just poked the dev->flags fields directly, but that
would require magic in the display list device to check for them
being set/unset and to poke the dev->flags fields on playback, so
instead we introduce a new fz_render_flags function (that calls a
device function) to set/unset flags.
The other attraction of this is that if we ever have devices that
'filter', we can neatly handle passing flag changes on with those.
Currently the display list implementation only copes with set/clear
of the FZ_DEVFLAG_GRIDFIT_AS_TILED option. We only readily have 6
bits available to us, so we'll just extend this as required if we
add new render flags.
|
|
Doesn't actually trigger generation from ghostscript, or load
images from files generated by ghostscript yet.
|
|
In android, we can't write to '.', and we don't have
TMP defined. Therefore use the path of the supplied file as
a hint.
|
|
MuPDF (the win32/linux viewer) leaks a span_soup each time it
is run, even if (seemingly to the user) no text extraction
operations are done.
This is because the view does a text extraction pass silently,
during which 'begin_page' is called for both page contents and
annotation contents. This causes a leak of a span_soup.
Change the implementation to allocate the span_soup just in time
instead.
|
|
Important for gproof files.
|
|
Include code to free the list of separation names.
|
|
Simple set of functions for managing sets of separations. Separations
have names, equivalent rgb/cmyk colors, and can be enabled/disabled.
|
|
Ensure that subsampling and caching happen in the generic image
code, not in the specific.
Previously, the subsampling happened only for images that were
decoded from streams. Images that were loaded direct were never
subsampled and hence were always cached at full size. After this
change both classes of image are correctly subsampled, and
the subsampled version kept in the cache.
This produces various image diffs in the cluster, none of which
are noticable to the naked eye.
|
|
Previously, we had people calling image->get_pixmap directly. Now we
have them all call fz_image_get_pixmap, which will look for a cached
version in the store, and only call get_pixmap if required.
Previously fz_image_get_pixmap used to look for the cached version
in the store, and decode if not - hence the decoding code is now
extracted out into standard_image_get_pixmap.
This was the original intent of the code, it just somehow didn't end
up like that.
This nicely queues us up for being able to have fz_images that use
a different get_pixel implementation, such as that which will be
required for the gprf code.
|
|
This will be required for the gprf work.
|
|
fz_read_int16le, fz_read_int32le, fz_read_int64le.
|
|
Previously, only the unix executable had been updated to take
command line flags; update the windows one in line with it.
We have to cope with the argv being in Unicode; add a windows
specific version of getoptw for this.
Also note that that fprintf's in the windows mupdf exe won't work
as GUI apps don't have a console window, and can't write to the
parent one. Fixing that is a larger project than I have time
for right now.
|
|
|
|
|
|
Add -U option to mupdf and mudraw to set a user stylesheet.
Uses a context to store user the stylesheet, just like the AA level.
|
|
Firstly, when displaying a list of nested blocks, don't suppress
outputting a block just because it contains a pointer to itself.
Various valgrind fixes from the gs version of memento.
Experimental C++ operators. See writeup in memento.h comments for
how to integrate.
|
|
If FZ_LARGEFILE is defined when building, MuPDF uses 64bit offsets
for files; this allows us to open streams larger than 2Gig.
The downsides to this are that:
* The xref entries are larger.
* All PDF ints are held as 64bit things rather than 32bit things
(to cope with /Prev entries, hint stream offsets etc).
* All file positions are stored as 64bits rather than 32.
The implementation works by detecting FZ_LARGEFILE. Some #ifdeffery
in fitz/system.h sets fz_off_t to either int or int64_t as appropriate,
and sets defines for fz_fopen, fz_fseek, fz_ftell etc as required.
These call the fseeko64 etc functions on linux (and so define
_LARGEFILE64_SOURCE) and the explicit 64bit functions on windows.
|
|
|
|
|
|
|
|
|
|
Add fz_has_permission function to fz_document.
Add fz_lookup_metadata function to fz_document.
Remove fz_meta function from fz_document.
|
|
The new pdfclean sanitize functionality mean that mutool now
needs the data files, so maintaining the split that was designed to
keep data files out of mutool is no longer viable.
|
|
|
|
|
|
Trigger the default layout when needed, but only if no manual layout has
been done. This avoids doing a pointless double layout (once with default
when loading the document, then with the manual layout call with the
desired layout options).
|
|
When advancing a glyph in vertical mode, it should advance down the page.
The origin of the glyph as supplied is bottom left, not top right - allow
for this in calculations. Previously glyphs were not being collated into
spans because of this.
|
|
In vertical motion mode, when calculating bboxes we should use
horizontal rather vertical displacements from the 'axis of
movement'.
In horizontal mode, we displace by 'ascender' and 'descender'.
Those concepts don't rotate with the motion mode, so repurpose
those fields to hold bbox.x0 and bbox.x1 in vertical mode.
|
|
|
|
Just for internal use, no external interface.
|
|
Stroke segments that are horizontal or vertical get the same
antidropout treatment as filled rectangles.
|
