| Age | Commit message (Collapse) | Author |
|---|
|
|
|
If we get the print profile given as '<EMBEDDED>' then use the
print profile (Output Intent) embedded in the file. If not, we continue to use
the defaults if given the empty string, or the given file otherwise.
|
|
For android this means it will go to our logging. This moves
the code out of gs.
|
|
|
|
We need to quote profile names if we use system, but not if we
use the GS_API. Update the code to cope.
|
|
Have both the GSAPI and non GSAPI invocations be identical.
Remove the -rxx bit because it is not required when using -gWxH
and -dFitPage.
Add some simple debug code.
|
|
If USE_GS_API is defined, we use the gsapi interface to call
gs.
The gsapi interface is defined in iapi.h, which is not included
in the mupdf source code. We therefore include a potted version
of this API inline.
To use the original, pass HAVE_IAPI_H at compile time.
|
|
|
|
The store is effectively a list of items, where each item is a
(key, value) pair. The design is such that we can easily get
into the state where the only reference to a value is that held
by the store. Subsequent references can then be generated by
things being 'found' from within the store.
While the only reference to an object is that held by it being
a value in the store, the store is free to evict it to save
memory.
Images present a complication to this design; images are stored
both as values within the store (by the pdf agent, so that we
do not regenerate images each time we meet them in the file),
and as parts of the keys within the store.
For example, once an image is decoded to give a pixmap, the
pixmap is cached in the store. The key to look that pixmap up
again includes a reference to the image from which the pixmap
was generated.
This means, that for document handlers such as gproof that do
not place images in the store, we can end up with images that
are kept around purely by dint of being used as references in
store keys. There is no chance of the value (the decoded pixmap)
ever being 'found' from the store as no one other than the
key is holding a reference to the image required. Thus the
images/pixmaps are never freed until the store is emptied.
This commit offers a fix for this situation.
Standard store items are based on an fz_storable type. Here we
introduce a new fz_key_storable type derived from that. As well
as keeping track of the number of references a given item has
to it, it keeps a separate count of the number of references a
given item has to it from keys in the store.
On dropping a reference, we check to see if the number of
references has become the same as the number of references from
keys in the store. If it has, then we know that these keys can
never be 'found' again. So we filter them out of the store,
which drops the items.
|
|
When invoking gs, pass in -gWIDTHxHEIGHT -dFitPage.
This avoids any possible mismatch betwen the page size we
expect and the page size that gs returns.
|
|
Without this we don't pick up FZ_ENABLE_GPRF from the header
correctly.
|
|
The gproof device should make use of the output intent if
it exists.
|
|
- use FZ_ENABLE_GPRF everywhere
- chasing changed fz APIs in gprf-doc.c
|
|
|
|
Surround the final filename parameter in quotes ("") so file and
folder names with spaces can be used.
|
|
Broken due to recent API changes.
Also retire SUPPORT_GPROOF in favour of FZ_ENABLE_GPRF.
|
|
Split compressed images (images based on a compressed buffer)
and pixmap images (images based on a pixmap) out into separate
subclasses.
|
|
Update the core fz_get_pixmap_from_image code to allow fetching
a subarea of a pixmap. We pass in the required subarea, together
with the transformation matrix for the whole image.
On return, we have a pixmap at least as big as was requested,
and the transformation matrix is updated to map the supplied
area to the correct place on the screen.
The draw device is updated to use this as required. Everywhere
else passes NULLs in, and so gets unchanged behaviour.
The standard 'get_pixmap' function has been updated to decode
just the required areas of the bitmaps.
This means that banded rendering of pages will decode just the
image subareas that are required for each band, limiting the
memory use. The downside to this is that each band will redecode
the image again to extract just the section we want.
The image subareas are put into the fz_store in the same way
as full images. Currently image areas in the store are only
matched when they match exactly; subareas are not identified
as being able to use existing images.
|
|
Use a macro to make fz_new_document nicer (akin to
fz_malloc_struct).
|
|
To be moved into a new document writer interface later.
|
|
Unadorned calling works on 64bit, but on 32bit we need to
ensure that the gsapi functions are declared as __stdcall.
|
|
|
|
|
|
|
|
|
|
- use core.fileFormat to decide whether a proof file is being viewed,
- don't show the proofing button except for PDF files.
- in a proofing activity, show the page that was being viewed when
the proof was requested.
- Add extra two arguments to fz_write_gproof_file in the Android build.
|
|
The default profile case (sRGB and SWOP CMYK) are indicated by
empty strings for those entries.
|
|
Ghostscript device has been changed from gproof to gprf for
sanity.
Also update the non-gsapi calling code to use the same options
as the gsapi calling code.
|
|
Setting the default post rendering ICC profile to sRGB will make the ghostscript
code use the ICC path with a SWOP CMYK device profile followed by a conversion to
sRGB for the RGB content in the gproof file.
|
|
This will be useful for identifying when we are proofing.
|
|
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.
|
|
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.
|
|
|
|
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.
|
