| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to facilitate exiting to the interpreter during text operations (such
as show, stringwidth etc) we store the text enumerator in an opaque Postscript
object on the execution stack.
Postscript refs have an attribute indicating what VM mode the object they
reference lives in (local, global or "system"). One of the places that uses that
is the garbage collector - if we're gc-ing local VM, we ignore refs with the
global attribute.
The problem is, we *always* allocate the text enumerator in local VM, but we
set the ref attributes with the current VM mode, meaning the enumerator would
never get marked by the garbager, and could be freed prematurely by the sweep.
Explicitly set the attributes to reflect the actual VM mode used to create
the enumerator.
Stems from work related to Bug 706368
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If set to true, stroke and fill operations that are fills
of DeviceGray, DeviceRGB, DeviceCMYK, ICC, or LAB colors
will be black. The exception is that white fills will remain white.
DeviceN, Separation, shading and pattern fills will remain as is.
We use the same structure as the -dBlackText option used to store
the color space into the graphic state. This structure has been renamed
black_textvec_state from black_text_state to denote this usage, as have
other variables.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Map all text to black. This is achieved by altering the
color space to DeviceGray with a fill of black during
gs_text_begin. When gs_text_release occurs, the color space
is restored. This will only occur with the option -dBlackText
and if the text is actually to be drawn.
When going to a raster device, the stroke and stroke fill of
the text is handled with a stroke or stroke fill command.
My original plan of storing the old color spaces and client
color in the text enumerator will not work in this
situation as it the enumerator will have already been
destroyed when the stroke or stroke/fill command occurs.
For this reason I store the old color space information
for the current and alternate color spaces
in the graphic state. The structure holding the information
is garbage collected as it is holding objects that may be
garbage collected. We also need to know if the target
was a high level device like pdfwrite, as that device
will handle the fill AND stroke, and we will need to restore
the color space when we tear down the text enumerator.
gs_text_release needed to have the pgs added as a parameter
to allow the possible release of the blacktext structure
when the text is released from the other languages. This
did not seem to be too big of an issue as gs_text_begin
passes the pgs also. If the pgs is not available, NULL can
be passed, and that is done in several locations.
A new special op was added to let us avoid doing the black
text setting if we are constructing a soft mask. If we did not
do this the mask could result in the loss of the text.
Finally, Type 3 fonts will NOT be affected by this process.
Type 3 fonts are often used for actual graphic logos etc.
Ken Sharp suggested we not have them affected by this setting.
There were also issues with trying to do type 3 fonts in
in that the PDF interpreter does some color space settings
of its state when dealing with type 3 fonts and this put the
interpreter's state out of sync with the graphic library state.
This was tested with a forced setting of black text enabled.
No seg faults or errors occurred. There were obviously a lot
of differences reported (over 33,000). All the images that were available
to me with bmpcmp were gone through. Problems were found
and addressed (the soft mask issue for example was found,
as were issues with color spaces not getting properly restored).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Some errors mean the graphics library will decrement the reference count,
potentially freeing, the text enumerator. So, on return to the interpreter
don't try to free it.
In these cases we can safely rely on the garbager to clean up the memory if the
graphics library didn't.
|
| |
|
|
|
| |
The exec stack cleanup done in 'show' needs applied to all the other similar
operators.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #700618 "Ghostscript - Invalid read in op_show_finish_setup()"
The problem occurs some time before the actual seg fault. The test file
is overly complex (not uncommon for fuzzed files), a simpler file would
be:
/S 80 string def
108 480 moveto
{ 1 S show
} loop
This runs in a loop, showing an empty string. But each iteration of the
loop leaves an object on the exec stack. Eventually we reach the stack
limit. The internals of 'show' require us to be able to push an object
(actually, 2 objects) on to the operand stack, so this results in a
stack overflow.
Although zshow() checks the return code properly, it does not reset the
exec stack pointer in the case of an error (it adds up to 11 objects
to the exec stack itself). For a fatal error this isn't a problem, but
stack overflow is non-fatal; the interpreter can increase the stack size
and retry.
This is where the problem exhibits. When we retry zshow() we have left
entries on the exec stack, in particular a 'mark', because we didn't
rewind the exec stack on error. We then try to use that to locate an
enumerator stored on the exec stack, but because we didn't complete the
setup, what we find is garbage.
The solution is simply to restore the exec stack pointer on error,
before we return. We should also free the enumerator to prevent a
(saved by garbage collection) memory leak. So also initialise the
pointer to NULL, so we can safely free it, even if we didn't get round
to allocating it.
There are 2 error conditions in this code, we need to update both.
|
| |
|
|
|
|
| |
Deleted C implementation.
Made finish_stringwidth() static since it no longer needs to be exported
to zglyphwidth().
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
In event of a Type 1 charstring font throwing an error setting up for a
CDevProc, ensure we use the correct path to exit the function, doing the
required cleanup along the way.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change how gstate initialisation is done:
Previously we relied on the imager state being a subset of the gstate (thus
assigning an imager state to a graphics state over wrote to the entries
common to both, and didn't overwrite any already set graphics state specific
entries).
Making the imager and graphics states the same means that approach doesn't work,
so this changes it to initialise the entries individually.
Renames gsistate.c->gsgstate.c and gxistate.h->gxgstate.h
Cleanup and fix the gs_state gc stuff.
Uses different check for pre/post clist pdf14 device
Previously, the code used "is_gstate" in the imager/graphics state object
to determine if the code was being called pre or post clist (post clist would
only ever have had an imager_state so is_gstate = false).
With no imager state any more, that test would no longer work (and I am dubious
about whether it was really safe, anyway). Other places check for the presence
of a clist reader device in the pdf14 device structure - so use that here
too.
Adds initial (NULL) value for show_gstate pointer in gs_state.
Removes the now pointless macro for the contents of the graphics state
Changes function names that had "imager" to use "gstate"
Removes the redundant 'is_state' flag
Cleans up gs_(g)state_putdeviceparams():
Previously we had to similar routines: one took a graphics state, and used the
device from the graphics state, the other took an imager state and the device
as an explicit parameter.
With the removal of the imager state, "merge" those two functions
Replaces gs_state with gs_gstate
It makes for less confusion as it really is a g(raphics)state
|
| |
|
|
|
| |
These were legacy remnants. Replace their remaining uses with the upper case,
non-deprecated equivalents.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #696503 " Regression: segfault with pdfwrite starting with 2deb460ef02e2802546e09979243764ede2d4173"
The bug title is something of a misnomer, the stated commit does not
cause the problem, it simply shifts memory around and exposes the
already existing bug.
The problem is caused by a faulty CIDFont, and the default behaviour of
the PDF interpreter, which does not halt when an error is encountered.
When running CIDFonts we need to execute a CDevProc in order to add the
PDF /W or /W2 values to the width of the glyph. However, the font we use
when setting up to run the CDevProc is broken so badly that we throw an
error from z1_set_cache. We return the error, but we don't terminate
the text enumerator, which leads to us continuing with the text. Not
surprisingly this eventually crashes.
This commit terminates the 'show' operation if it detects an error when
setting up to run the CDevProc.
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.
|
