| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
This in turn causes MIN_INT phases, which upsets stuff in the
graphics library when attempting to fit a tile to a device
in copy_mono.
|
| |
|
|
| |
Probably unnecessary, but this is cleaner.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Historically gs_image_common_t has been distinct from gs_data_image_t.
This was, apparently, to cope with image type 2's not having explicit
Width/Height's. We no longer support image type 2's, so the additional
complexity of this is not required.
Therefore, just make gs_image_common_t be the same as gs_data_image_t.
This obviates the need for the 'source_size' image function, so
remove that too.
|
| | |
|
| |
|
|
|
|
| |
There was an area in gx_begin_image3_generic setup for bug 700538 to
detect rangecheck but it did not check all extremes. Note that this
stems from an absurd CTM in the PDF: 548.0 0 0 -1.43262569e+37 0 0 cm
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Release testing has shown up another case that needs help.
gs/bin -sDEVICE=ppmraw -o out.ppm -r300 -dMaxBitmap=1G
tests_private/pdf/sumatra/1901_-_tiling_inconsistencies.pdf
This shows horizontal white lines in the "Next" "Up" "Previous"
images at the top of the page.
Investigation shows this is due to the images having Masks as well
as SMasks.
The Mask image is run to a 1 bit memory device, which means that
the gxdso to check if we are in an SMask doesn't work. We work
around this by introducing a new flag to gs_pixel_image_common
that we can set to indicate that we are within an smask. We set
this when we set the masked image up (using the gxdso), and check
it when we come to do the gridfitting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #693814 "Valgrind reports uninitialised value(s) in pdf written image streams"
The valgrind warnings are real, but essentially benign. If the wisth of
the mask data for a type 3 masked image is not a multiple of 8, then we
do not completely write to each bit of the final byte of mask data.
When writing the mask data to a PDF file, we obviously write the entire
last byte, which causes valgrind to (correctly) complain about using
uninitialised data. Of course the uninitialised bits are never actually
used, even by the PDF consumer.
We could put a PACIFY_VALGRIND around this line, but writing
uninitialised bytes means we could run the same input twice and get two
slight different PDF files, which would flag as a diff in our testing.
It would also annoy the 'reproducible builds' people, potentially.
Since its only a single byte, just clear it for reproducibility, even
when we aren't running valgrind.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Valgrind is not smart enough to realise that <undefined_value> * 0 =
defined 0.
Thus, initialise raster to 0.
This makes the following command run without warnings:
valgrind --track-origins=yes bin/gs -sOutputFile=out.pdf
-dMaxBitmap=400000000 -sDEVICE=pdfwrite -r300 -Z:
-dNOPAUSE -dBATCH -K2000000 -dClusterJob
/home/marcos/cluster/tests_private/comparefiles/Bug692226.ps
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to Ken for doing most of the investigation on this.
The problem is that we have a double value of 5e9 that won't fit
into an int (and becomes INT_MIN). This huge negative value is then
added to a pointer and we access out of range.
The fix is simply to check for our double values being representable
as ints before we proceed - if not we throw a rangecheck. This is
reasonable as it corresponds to an image being positioned stupidly
far off the page.
The complication with this commit comes in that it collides with
some very suspect old fixes for Bugs 686843 and 687411. The patch
for 686843 makes the same change in 2 places in the code. It looks
like 687411 is reported as the same issue, but the fix for it appears
to be reverting one of the fixes for 686843 - I suspect that the
patch was reversed.
Given that we can't reproduce the original problems that these bugs
were trying to solve any more, I am reverting the code to a saner
form. If the problems recurr, we can reexamine then.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
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.
|
