| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue is that the pdf14 device will close and reopen the
target device under certain cases and the X11 devices were not
cleaning themselves up sufficiently. Also added a finalize
method where the call to XCloseDisplay should actually be made.
The pdf14 device does this close and open dance to ensure that
the page_has_transparency parameter will be set in the device.
It is possible that we could end up in the pdf14 device
push without page_has_transparency if the call is done from
Postscript code. The PDF interpreter
always sets the page_has_transparency value before doing the
push so this should not be a problem with PDF.
Thanks to Chris Liddell for helping with this.
|
| | |
|
| |
|
|
|
|
|
| |
Move the definition of x_pixel within the headers to ensure
gdevcmp.h stands alone.
Include a ufst header to ensure that gxfapiu.h stands alone.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The x11 devices can either unbuffered (where rendered objects go straight to the
screen) or buffered (where objects are rendered to a memory buffer device, and
then blitted to the screen).
Additionally, the 'real' x11 device always uses the resolution and color specs
of the X11 server on which it is running. Then devices such as x11mono and
x11cmyk using a "wrapper" device in order to keep the x11 device using the
specs of the X11 server, whilst presenting an appropriate character to the rest
of Ghostscript (so, even though x11 is *probably* running 24bit RBG, x11mono
needs to look like a pure monochrome device).
Because we need the 'real' x11 device to handle get_params/put_params, and we
need to temporarily 'patch' the color info of the 'real' x11 device so it
retrieves/applies the params correctly.
The problem arises when we run one of these 'wrapper' devices in buffered mode.
The memory buffer device (particularly after a resizing of the page buffer),
would end up being configured based on the color settings of the 'wrapper'
device, rather than the 'wrapped' device. So we could end up treating a 1bpp
mono bitmap (from the memory buffer device) as a 24bpp RGB pixmap and blitting
to the screen. Causing a buffer overflow, and segfault.
To solve that, store the color info we need away from its place in a
standard device, and use the x11 device's own dedicated copy for setting up
the memory buffer device.
|
|
|
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.
|
