| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
No one sets it. No one reads it. It's pointless, so excise it.
|
| |
|
|
| |
No longer used.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The x11mono, various x11cmyk*, two x11gray* devices work by "wrapping" the
real x11 device, rendering to the requested color spec, and converting that
rendered result to the native x11 representation before flushing to the real
x11 device.
When outputting a page, the wrapper device wasn't inheriting the PageCount
from the real x11 device, so naughty code that acccessed the device page
count directly would always see it as zero.
So, keep the wrapper and real device page counts in sync.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
For some reason, I changed the output_page routine called for
the x11cmyk devices. Probably a typo that I wasn't smart enough
to spot was a typo. Fixed here.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
An intermediate calculation results in a cast to 'int' which is then
promoted (on 64-bit systems) to an unsigned long long. If the top bit
of the intermediate value is set, then all the top bits of the final
value will be set.
Do an explicit cast to an unsigned to avoid this.
|
| |
|
|
|
|
| |
The X11 device copy_color proc was accessing indices outside its 16 value cache
causing improper color drawing for the cmyk2 device. For the cmyk4 device, the
bit manipulations mapping to rgb were incorrect.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run a release build on a linux machine to make arch.h etc. Then
run toolbin/headercompile.pl to test compiling each headerfile
by itself.
Resolve all the missing #includes, add missing repeated include
guards and copyright statements.
Also, update all the header dependencies in the makefiles.
It is possible that the object dependencies in the makefiles can be
simplified now, but that's a task for another day.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
More dead code exposed by the macro removal in gsbitops.h.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'load' and 'store' macros were deemed offensive for a number of
reasons; they declared variables, hiding them from casual view, they
hid flow control (switch statements started in one macro, ended in
another), returns from inside macros, some macros were not (and could
not be) bounded by "do{...} while" which means care needed to be taken
with ';' and were very deeply nested, the names chose for the macros
made them look like functions, finally macros are hard to debug, even
with a macro-expanding debugger.
Additionally there were the 'LINE_ACCUM' macros, some of which simply
called the 'load/store' macros directly, which just added another
layer of obfuscation, particularly since these macros were defined in
a different header file. Macros could be nested 4 or 5 levels deep.
This commit finishes removing all but one of the macros, the last
remaining macro has been renamed to upper case to make it clearer that
it is a macro. It can't easily be removed since it depends on the size
of gx_color_index, which is a compile time #define.
The functionality of the macros has either been expanded in line or
replaced with inline functions declared in gsbitops.h. The majority
of the macros have been replaced with functions, even for small functions
where it seemed useful to keep the name as a description of the actual
functionality.
I don't anticipate any differences, but I think this makes the code
easier to understand, easier to debug, and therefore easier to maintain.
|
| | |
|
|
|
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.
|
