| Age | Commit message (Collapse) | Author |
|---|
|
This will be useful for identifying when we are proofing.
|
|
|
|
|
|
|
|
|
|
Android wants colors to be BGRA, not RGBA, so accomodate this.
|
|
Explicitly pass the page number into separation related
functions.
|
|
|
|
|
|
These headers are already included by mupdf/fitz/system.h.
|
|
|
|
gsview on windows does not support the use of stdout and stderr.
The calls to write out to these will return 0 leading to an i/o
error from gs. To avoid this we define dummy functions that
simply return the length that was to be written. To avoid
issues with including "iapi.h" in Android builds that do not
support gproof we wrap all of gprf-doc.c in an ifdef SUPPORT_GPROOF
|
|
Michael reports that adding -I%rom%Resource/Init/ to the args
solves some problems by ensuring that the ROM filing system
is used.
|
|
I missed a line when refactoring code.
|
|
We should use a void *instance, not a void **instance.
And fz_read_string is more correct than fz_read_line.
|
|
It's a C99ism.
|
|
Neatness doesn't override actually working.
This reverts commit efb5a38ca0bac3537ceaf3383681a518df133143.
|
|
When proofing an image without all the separations enabled, we
reconstitute it using the equivalent cmyk colors, and then
convert to rgb. The CMYK -> RGB step is important for quality,
and the whole point of GProof mode is to give the best possible
quality, so use the slower, but prettier code.
Also, fix the blatent bugs in the slower but prettier code that
I introduced when hurriedly fixpointing it.
|
|
The code for this was broken; the wrong flag was being tested
for selection number, and the values were being assembled per
line rather than per pixel.
|
|
Not sure if this is actually an issue at the moment, but it
potentially could be.
|
|
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.
|
|
Windows build was broken with commit 642a59a4de683a1359733229943be285e3e45c4f
|
|
|
|
|
|
|
|
|
|
When attempting to load pdf objects and a valid pdf object is found but
it has the wrong number, mark the xref object entry as being free before
attempting to repair the xref. This ensures that if the wanted object
cannot be found in the document then the missing object will be
considered to be null. Previously it was still assumed to be around, but
the object pointer was NULL triggering an assert in pdf_load_object().
|
|
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 these operators accepted out of range values which
triggered asserts in the rendering code.
|
|
When parsing dicts or arrays while reparing objects the xref should not
be used to try to resolve indirect objects since the xref has not been
fully rebuilt yet. As was the case prior to commit 07dd854.
|
|
Commit f533104 introduced optimized handling of pdf names, null, true
and false. That commit handles most object types correctly in
pdf_objcmp() but it does not correctly handle comparisons such as
pdf_objcmp("/Crypt", "true") or pdf_objcmp("null", "/Crypt").
Fixes one issue from bug 696012.
|
|
Previously encoding differences were allowed outside the valid unicode
codepoint range.
Fixes one issue from bug 696012.
|
|
Previously all output values were used, causing buffer overflows.
Fixes one issue from bug 696012.
|
|
Check flow is not NULL before dereferencing it. Everything else
in this area of the code copes with it being NULL.
|
|
If we build with DEBUG set, the native section will be built
with debugging enabled.
The debuggable flag in AndroidManifest still needs to be edited
manually, but it's set explicitly false here so we can grep for
it.
Also, send stdout/stderr to text files in DEBUG builds. The path
for this may not work on all phones (it certainly works on the
LG G3, running Lollipop), but it won't hurt on anything.
|
|
MuPDFCore now supports a gprfSupported method that returns
true iff we compiled the core with SUPPORT_GPROOF and a
libgs.so is available.
|
|
|
|
|
|
Hit the proofing button, and we create a new temporary .gproof file.
We invoke a new version of MuPDF on that. When that finishes control
returns to us, and we delete the .gproof file.
Currently the new version of MuPDF loads the .gproof file, but fails
to generate any pages from it, as we have no version of ghostscript
on the system. Generating this new ghostscript is the next job.
|
|
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.
|
|
|
|
Given a document, generate a gproof file from it. This encapsulates
the name of the file, the desired resolution for proofing, and the
page dimensions of all the pages in the file.
The idea is that an app will call this when it is asked to go into
'proofing' mode, and will reinvoke itself on this file. This gives
the gprf document handler just enough information to fake up a
document of n pages of the required sizes. Each page will then be
autogenerated on demand.
|
|
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.
|
