| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, we look in TESSDATA_PREFIX (if defined).
If not found there, we look in ROMFS (in tessdata).
If not found there, we look at the configured "tessdata" path
(which defaults to ${datadir}/tessdata). (${datadir} defaults to
${prefix}/share on unix, and ${gsrootdir} on windows.)
If not found there, we look in the current directory.
Update doc/Devices.html (and fix some indexing).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the allocations from the bitmap cache are aligned to the platform's
required alignment, see commit:
260c443bc14cdffa4d94e14c3a57e35bebee3a5b
We also want the initial size of the memory pool used by the cache to be
"aligned".
This is so that code that attempts to identify cache entries to evict by
requesting a size equal to the entire size of cache memory pool doesn't get an
unexpected failure, because we've rounded up that allocation request to a value
larger than the entire size of the memory pool.
Because we don't expect an error to be possible at that point, a crash can
occur.
Of the "normal" platforms we use, this only exhibits on Win32 because that is
the only platform where the align_bitmap_mod we use is less than the
obj_align_mod used for the memory managers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found during Windows testing for a release.
The full test file for
https://bugs.ghostscript.com/show_bug.cgi?id=693365
would cause Ghostscript to crash due to an ICC profile being freed whilst a
reference was still being held for it. That was not counting up a reference
count when restoring the device profile back to a previous value.
Fixing that introduced a leak for other profiles. And that turned out to be
not decrementing the reference count when replacing a device profile.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
VS2019 release builds crash with the input file from bug 702916 and several
other files, in copied_glyph_slot() because the pointer retrieved and stored
in *pslot is non-sensical.
Debug/Profile builds and optimised builds with earler VS versions don't show
the problem.
Adding debug code to assign the calculated index to an interim unsigned integer
variable also cause the problem to go away.
So, use that as a workaround.
|
| |
|
|
|
|
| |
And a whitespace/indentation issue.
Noticed in passing....
|
| |
|
|
|
| |
s/RepiredAnError/RepairedAnError/ A simple typo that was missed because
we did not have a test file with a format error to trigger this code.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For efficiency, the glyph cache allocates "large" blocks of memory into which
it parcels out offsets for individual glyph cache bitmaps, as required.
Since cached glyphs are usually fairly small, and potentially can be short
lived, this saves the overheads of "full" memory for every cached glyph.
Unfortunately, in calculating the offsets for the cached glyph, it was failing
to account for the required alignment of the system. In any environment that
strictly enforces aligned memory accesses, this will potentially cause a bus
error.
In this case, it was switching the gs_glyph type to a 64 bit type that triggered
the issue. But any changed to the contents of the cached_char struct could have
resulted in it happening.
|
| |
|
|
| |
That page is now gone.
|
| | |
|
| |
|
|
|
| |
In a few cases we were using the wrong element in the union to read the
value back from the param list (and to range check the values).
|
| |
|
|
|
|
|
|
|
| |
The unconditional call to enable multi-threaded rendering during set up of the
gx_device_printer as a clist caused the SEGV of bug 702181, but enabling
multi-threaded rendering here isn't correct since it is usually done when we
output the page (gdev_prn_output_page_aux). The problem is that BGPrint would
setup a new clist device to render the page, but needs to enable multi-threaded
rendering for the background clist device. Do this if NumRenderThreads > 0.
|
| |
|
|
|
|
|
|
|
| |
The gpmisc.c does allocations for gp_file objects and buffers used by
gp_fprintf, as well as gp_validate_path_len. The helgrind run with
-dBGPrint -dNumRenderingThreads=4 and PCL input showed up the gp_fprintf
problem since the clist rendering would call gp_fprintf using the same
allocator (PCL's chunk allocator which is non_gc_memory). The chunk
allocator is intentionally not thread safe (for performance).
|
| |
|
|
|
|
| |
In order to safely allow for a 9.53.2 patch release that fixes BGPrint
with NumRenderingThreads while the issues with PCL and friends are
fixed, just ignore BGPrint in pcl/pl/plmain.c
|
| |
|
|
|
|
|
|
|
|
| |
We cannot combine shared and not shared libjpeg and libtiff - they either both
need to be "local" or both shared, and configure checks that and fails when
the two are incompatible.
However, that check would fail when either libjpeg or libtiff were not being
included at all. Since it is libtiff that is the "problem" for this
compatibility, now check if TIFF is included, and if not, skip the check.
|
| |
|
|
| |
Whilst hopefully not breaking the buildroot build.
|
| |
|
|
|
|
|
|
| |
Previously the directory in which to run the libtiff configure script was
initialised to an empty string, but that, in some toolchains, resulted in an
error due to "unsafe header/library path used in cross-compilation".
So initialise it something benign instead.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
With the change to 64-bits unconditionally for gs_glyph we can now
define GS_MIN_CID_GLYPH in 64-bit terms.
Previously we were using the architecture size of a long_long to
determine which define to use, and we do not define long_long on Windows
leading to us using an essentially 32-bit definition. This caused
indexing off the end of an array in copied_glyph_slot()
|
| |
|
|
|
|
|
|
|
|
| |
For various reasons we cannot combine shared and not shared libjpeg and
libtiff - they either both need to be "local" or both shared.
But the check for that compatibility was triggered during the recursive
configure call when setting up for cross compiling.
Skip the check for that recursive configure call.
|
| | |
|
| |
|
|
|
| |
In practice this has been required since commit
9b5008aa2bc1c6a6acb2c6f90d1ef8d6bad9e66a.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When we flush the alphabuffer, mapped_start and mapped_height are
both set to zero. When we refill it, mapped_height is set to
non-zero. USUALLY mapped_start is set to non-zero too, but it can
be set to zero when we are close to the bottom of the page.
Hence we should test for mapped_height != 0, rather than both
mapped_height and mapped_start being non-zero.
So the 'quick hack' that Chris used is actually correct.
|
| |
|
|
|
|
|
| |
Thanks to Herbert Voss for spotting this. Fixed the typo and updated the
version number in the warning from 9.53 to 9.53.0 to match the actual
version and patch number of the release (the decision to add the patch
level was taken after the original commit)
|
| | |
|
| |
|
|
|
| |
If it was finding any Tesseract data in ROM it was then not looking
for files.
|
| |
|
|
|
|
| |
We had to add the outputfile to the "control" file permission list (as well
as write), but for the "pipe" case, I accidentally added the call after the
break out of loop that checks for a pipe.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code to retrieve the Ghostscript paths from the Windows Registry
was generating a key based on the version number, but since we added the
patch the generation was incorrect.
Since this is the third (!) case of this, scan the code for any usage of
gs_version, gs_version_number, GS_VERSION, GS_VERSION_NUMBER,
gs_revision, gs_revision_number, GS_REVISION and GS_REVISION_NUMBER.
This reveals two more places, neither serious but we might as well fix
them while we're here.
Thanks to Akira Kakuto for finding this problem and suggesting a patch.
I chose to use the code we were already using in two other places, just
for consistency, but the supplied patch was equally good.
|
| | |
|
| |
|
|
| |
There were left over binary libraries, remove them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Firstly, in gx_device_delete_output_file the iodev pointer was being passed
to the delete_method incorrectly (passing a pointer to that pointer). Thus
when we attempted to use that to confirm permission to delete the file, it
crashed. Credit to Ken for finding that.
Secondly, due to the way pdfwrite works, when running with an output file per
page, it creates the current output file immediately it has completed writing
the previous one. Thus, it has to delete that partial file on exit.
Previously, the output file was not added to the "control" permission list,
so an attempt to delete it would result in an error. So add the output file
to the "control" as well as "write" list.
|
| |
|
|
| |
for 9.53.0 RC1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #702772 "Strange /Producer attribute"
The change to include a patch level for Ghostscript in the gs_revision
value wasn't being reflected in the code to generate the version
number used in the PDF /Producer string.
Copied the code from printf_program_ident() in base/gsmisc.c to the
code in pdf_store_default_Producer() and commented both pieces of code
to note the existence of each other so that in future hopefully we won't
forget to keep them in sync.
Thanks to Peter Cherepanov for spotting the flaw.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The loop is caused by a circular /ParentResources attribute.
This branch of code is triggered by an error in the sample file:
misplaced /Form resources in a Type 3 font. This font has /Resource
dictionaries added to /CharProcs entries rather than the font dictionary.
Note that this patch fixes the hang issue, but does not correct the
issue of not being able to find the correct resource (in the CharProc)
so that the file still output does not match Adobe (mupdf has that
same issue).
Thanks to Peter Cherepanov for this patch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To do this, we introduce gp_unlink and gp_rename, and call those
as appropriate.
Also, make gp_open_scratch_file add the file to the permit list.
When such a file is closed, it will be deleted from the permit list.
It will also be removed from the permit list if the file is deleted
using the PS deletefile operator.
On closedown, if scratch files haven't been deleted, then we'll
delete them as part of the closedown of gs_lib_ctx.
This means that 'purging' the control lists must not remove scratch
file paths from the list.
Also, ensure that gsapi callers can't maliciously (or accidentally)
remove scratch path paths from the list so as to leave them around
after closedown.
|
| |
|
|
| |
This makes it easier to issue patch releases for security problems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As this is change in behaviour, it's optional. The configure script now
uses (if set) a environment variable called "DARWIN_LDFLAGS_SO_PREFIX" -
included "DARWIN" because it only applies to DARWIN derived systems.
This allows the caller to use:
./configure DARWIN_LDFLAGS_SO_PREFIX="@loader_path/"
Thus meaning the build will use loader_path rather than "@executable_path".
Configuring/building without that environment variable will retain the current
behaviour.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the FirstPage and LastPage processing device did not allow
any means to reset the PageCount. This was because Ghostscript's
command line processing does not permit changing non-PostScript
controls (interpreter and some device parameters) after the first file
has been run.
GPDL however, has a new mechanism 'set_param' which can be used
programmatically, and that does permit for device and interpreter
parameters to be altered after the initial file has been processed.
To allow for this the gdevflp device now processes parameters itself
instead of relying on the underlying device to do so. The parameters
FirstPage, LastPage, PageList and DisablePageHandler now all reset the
page count to 0 when they are encountered. This means that, using gpdl,
it is possible to select a set of pages from one file, then select a
different set of pages from a second file. Sending any of these
parameters (except, obviously DisablePageHandler) also now automatically
enables the device again ie it sets DisablePageHandler to false.
It is not, unfortunately, possible to load the gdevflp device at any
time except when the underlying device is initially opened. This means
that if any file is to be processed using gdevflp the first file must
use one of the parameters, in order to load gdevflp. The simplest
solution is simply to set -dFirstPage=1 which will load the device and
run all the pages from the file.
This commit also includes a minor change to the PDF interpreter. Because
the PDF interpreter (currently) handles subsets of pages itself, it
does not want the first/last page device to be active, so it
disables the device by sending a 'DisablePageHandler' to it. However
(because of the GS command line, as described in the first paragraph) it
did not bother to re-enable the device. So here we add a line to
re-enable the device after processing is complete.
This is probably superfluous now that sending the params will re-enable
the gdevflp device anyway, but it should make the intention plain.
|
| |
|
|
|
|
| |
If the process color space does not match the source color space (for example
drawing an RGB image to a CMYK device) and overprint is true, then we should
still retain the spot colorants assuming the device supports them.
|
| | |
|
