| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
Check for pointer Functions being NULL before dereferencing. Avoids all
the callers having to check.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The PostScript code seems to get away with this, but for the PDF
interpreter we need the object pointed to by the various 'params'
structure members to be NULL after they are freed, so that we don't
try to free memory which has already been freed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #699528 "A rare edge condition can cause a function to incorrectly signal a rangecheck error"
This is rather difficult to describe. The problem occurs when we try to
check for monotonicity of a stitching function between two data points
of the parametric variable.
We actually calculate a series of points between the two values and
check to see that they all increase (or decrease). However, a stitching
function can contain multiple functions, and so we break the range of
values into groups at the limits of each function and check each
group of values.
If the lower value of the parameteric variable is 'close' to the upper
bound of the current function, we decide to 'punt' it up to the next
function, presumably to avoid the overhead of a miniscule break. That is
we simply don't bother calculating tiny amounts at the end of a function
we just do the next function.
However, if the upper range of the parametric variable happened also
to lie close to (but less than) the upper bound of the function, then
when we used it to evaluate the next function in the array, it would lie
below the bottom bound of that function, resulting in a rangecheck error.
This commit applies two fixes; firstly, if the upper and lower values
of the parametric variable are the same then this is a point, and there
is no point in checking it, so just jump straight out.
Secondly, the upper value is now promoted to the lower bound of the
current function if it is less than that. This prevents us trying to
use an out of bound value, in case we should somehow get both an upper
*and* a lower bound which lie within the 'noise' threshold.
Because the range of 'noise' is so small (the bounds values of the
function divided by 1 million) there is no practical likelihood of
us missing a function which is not monotonic between those data
points.
|
| |
|
|
|
|
|
|
|
| |
Also update copyright dates.
Remove gs_cmdl.ps as we no longer use it, and remove its entry from
psfiles.htm.
Remove xfonts.htm as this feature (xfont support) is long, long gone.
|
| |
|
|
| |
We checked the parameters for validity, but ignored the result !
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #696626 " A PDF file causes ps2pdf crash"
The code fro serialising a Type 2 function was assuming that C0 and C1
were valid (validated by the interpreter) and always present. In fact
both of these are optional. We were attempting to dereference a NULL
pointer.
Altered the type 2 serialise code to write the default values if either
or both of C0 and C1 are not present.
No differences expected.
|
|
|
Squashed into one commit (see branch for details of the evolution of the
branch).
This brings gpcl6 and gxps into the Ghostscript build system, and a shared
set of graphics library object files for all the interpreters.
Also, brings the same configuration options to the pcl and xps products as we
have for Ghostscript.
|
