| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706367 "ESC/Page driver does not set page size correctly"
The PLRM indicates (Table 6.2, page 401, PageSize) that page dimensions
are considered to match if they are within a tolerance of 5 units in
each direction. This device (like others) was insisting on a precise
match.
Just add the tolerance.
I have no way to test this, other than looking at the content of the
output from the device, written to file, which appears to be correct.
|
|
|
|
| |
Function protoype mismatch warnings.
|
|
|
|
|
| |
Pick a default paper size so Coverity can see that we never reach
the use of paper_command without having set it.
|
| |
|
|
|
|
| |
Will probably never happen, but the fix is simple.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to Robin for suggesting the structure form
to get the globals at a common offset for the
raster and vector forms of the device. That coupled
with pushing the device through all the methods and
doing initialization was the biggest effort.
Thanks also to Chris for his help in providing
understanding as to what this device was actually doing.
This commit includes a test harness for the opvp
device, which uses the device client API to write
out the commands it receives to a text file for
comparison. To build the driver use ./build_opv_harness.sh
To use the driver use a command line like
-sDEVICE=opvp -sDriver=libopv.so -o output.txt -f ./examples/tiger.eps
The command lines are always dumped to the same
file which is opvp_command_dump.txt. Note that the
harness itself has to rely upon globals due to our
inability to change the client API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some devices within Ghostscript (currently the x11 devices,
uniprint and opvp/oprp) use non const static variables, so cannot
be run in multiple instances at a time.
We now maintain a core "count" of how many non-threadsafe devices are
being used at any time. This value can be atomically adjusted by calls
to gs_lib_ctx_nts_adjust.
Non threadsafe devices now call gx_init_non_threadsafe_device either
as or as part of their initialise_device proc. This function attempts
to increment the non-threadsafe count and fails to init if there is
already a non-threadsafe device running.
On success, the device finalize method is modified so that it will
decrement the count at the end.
The known non-threadsafe devices are updated to call this.
In order to have somewhere safe to store this count, we introduce
a gs_globals structure, shared between instances. Setting this up
without race conditions requires some new gp_ functions that can
make use of platform specific threading primitives. We have these
implemented for both windows and pthread based platforms. On other
platforms, we drop back to the old unsafe mechanism for counting
instances.
While we do this work, we take the opportunity to push the
gs_memory_t pointer used for non-threadsafe debug printing into thread
local storage.
This enables us to remove the remaining GS_THREADSAFE guarded
compilation from the source code. What is left is broadly down to
allowing debugging collection for statistics, and these are now
controlled by specific COLLECT_STATS_XXX defines. It is assumed
that anyone wanting to collect such stats is smart enough to not
try to do so while using Ghostscript in a multi-instance environment.
|
|
|
|
| |
This should make the devices threadsafe.
|
|
|
|
| |
Thanks to the bug submitter for noticing it and this patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch, from Alex Cherepanov, updates the following devices to
use decode_color and encode_color rather than relying on the default
implementations that lean on the older, obsoleted color mapping
functions:
cdj670
cdj850
cdj880
cdj890
cdj1600
chp2200
cdnj500
cdj970
lxm3200
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
High level devices do not generally keep a rendered bitmap
version of the page. As such they cannot honour get_bits_rectangle
requests.
This causes certain rendering operations to fail; notably those
that involve ROPs that involve 'D'. This can cause runs to
error out prematurely.
For instance, a 72dpi page mode PCL run of j9_acrobat.pcl to the
lips4v device dies with an error.
Accordingly, we add a gx_blank_get_bits_rectangle routine that
returns 'empty' rectangles, and we make lips4v use that. This
gives imperfect renderings (in the same way that pdfwriting
files that use ROPs gives imperfect renderings), but we do at
least get a rendering out at the end.
In testing this, I found a suspect spot in lips4v where valgrind
spots us operating on uninitialised data. Patch around that to
init it to 0 to quell valgrind.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The device initialize function currently performs 2 jobs. Firstly,
it fills out the device_procs. Secondly, it performs any minimal
initialization required by the device (typically none).
At various points in the code we want to be able to copy procs
from one 'prototype' device to another, so we call initialize
for that. This populates the device procs, but does other work
that typically requires a 'derived device' structure rather
than a vanilla gx_device to work in.
Accordingly, we split the job into two; initialize_device_procs
(the first part) and initialize_device (the second part). The
initialize_device_procs function will set up the initialize_device
function pointer along with the rest if required.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move the initialize procedure out of the device procs table,
and into a bare function pointer at the start of the device proc.
Devices just initialise this, and the rest should fall into place.
This means changes to the device instantion macros (and all the uses
thereof), but makes the code nicer overall. In particular, this
removes the vestigial 'static_procs' structure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It used to be that finish_copydevice(dev, const old_dev) would be
used to copy stuff from a prototype to a new instance of a device.
Now, no copying is ever done.
Also, it's a confusing name. Rename it to be 'initialize', which
is clearer. Also, it should become even more appropriate in
future, if we have this function be the one that is responsible
for filling out the procs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are 4 devices (pr201, pr1000, pr150, and pr1000_4) that are
all basically the same code. They differ in the number of lines
of data they deal with at once.
The first 3 use 24, 40 and 48 lines respectively - all numbers
that are multiples of 8. The code reads that many lines at once
and then "transposes" the data to send 'columns' of 24/40/48
pixels at once.
The pr1000_4 variant uses 60 lines. This means we read outside
the input buffer into uninitialised data.
I have my doubts that this device actually works properly, but
the change here simply bumps up the buffer sizes to be larger
and initialises it all to 0 so we get consistent SHAs in cluster
testing.
|
|
|
|
|
| |
We cannot the test old versions, so this will merely bitrot
and make maintenance harder.
|
|
|
|
| |
This enables more contrib devices to be debugged/run under windows.
|
|
|
|
|
|
|
|
|
|
| |
gdevescv.c used strdup, which wasn't previously caught by Memento.
Accordingly it was careful to release the memory using
'unvectored_free' (i.e. free before Memento got involved).
Now that Memento has been updated to catch strdup this is not
required (and indeed causes problems). Accordingly, simplify the
code.
|
| |
|
|
|
|
|
|
|
| |
Header files shifted around so that the redefinition of printf happens
after cdefs.
Also removes redundant CONTDEVH definition from contrib/contrib.mak
|
|
|
|
|
|
|
|
| |
This contributed device is odd how it changes its color model.
Unfortunately it does not change the ICC profile. This mismatch
between the ICC profile and the color information that is
being changed by the device causes all sorts of problems. This
should fix the issue.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It has code which triggers security warnings, it has not built as it stands
since before 8.71 (so >10 years) and has significant (segfaulting) problems
when modified to successfully build.
Since it cannot have been used (and no one has complained) in over ten years,
we're removing it.
|
| |
|
|
|
|
|
|
|
| |
Avoid using the same header include guard in more than one file.
Use the correct format specifier in a printf-like error string
in lcms2mt.
|
| |
|
| |
|
|
|
|
|
| |
Since I use the Git commit hooks to verify no white space problems I
can't merge master into the pdfi branch without first fixing these.
|
|
|
|
| |
Also changed some fns from void to int so we can propogate any error.
|
|
|
|
| |
coverity issue.
|
| |
|
| |
|
| |
|
|
|
|
| |
shifting.
|
|
|
|
| |
coverity issue.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Simplified code accordingly, and removed static fn oki_compress() as no longer
referenced.
|
|
|
|
|
| |
This code is slightly odd, and didn't want to make major changes, so have ended
up with odd-looking extended expression whose actual value we ignore.
|
| |
|
| |
|