| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #703750 "-dRenderIntent=0 not working on linux"
For unknown reasons the Windows build calls gx_default_put_params()
twice with the same set of parameters. Linux, however only calls it
once.
The reason this is a problem is because the first time it is called the
device's icc_struct member is NULL (not been allocated) and so the
put_params call simply discards the request (without warning). On
Windows the second request succeeds but since Linux only calls put_params
once, it ends up discarding the request entirely.
On examining the code it is clear that the gx_default_put_intent() and
similar functions all create the device's icc_struct member if it is not
already present, so clearly this is a problem which has been encountered
before. Since this is the case, there is no need for the guard against
dev->icc_struct being NULL in gx_default_put_params() and removing it
properly stores the requested parameters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing a fill stroke in the presence of transparency, we use
a knockout group to get the correct results.
When we use alphabits, this results in the actual plotting
happening via copy_alpha_color.
The pdf14 copy_alpha_color routines don't ever appear to be called
in normal runs, and they don't seem to take note of the backdrop
for knockout runs.
Accordingly, we update them here so they do.
Also, to avoid nasty lines around the edge of stroke segments
we ensure that do_fill_stroke keeps the lop_pdf14 bit set
until AFTER the stroke is complete.
While this gives VASTLY improved rendering in most cases, this does
leave us with the classic 'white halos' around knocked out shapes.
What typically happens during a fill/stroke is that we push a
knockout group, and draw the fill into it. Then we draw the stroke
into it. As the stroke is drawn, all we have for each pixel is a
color and an alpha.
The old code used to use the alpha to mix between the given color,
and the current group contents. This is wrong, because it stops
knockout happening.
The new code uses the alpha to mix between the given color, and the
original background. This correctly knocks out colors, but leaves
nasty white halos around the edge of things.
I think the issue here is that we are getting a single alpha, when
really we'd like both opacity and shape. To do this properly, I
think we should combine the color and the original background by
opacity, and then combine the result of that with the current group
contents by shape. But we only have the combined opacity and shape
value. So we're probably doing as well as we can hope to for now.
|
| | |
|
| |
|
|
|
|
|
| |
Unused variables, 'may be used unset' or implementations not
matching prototypes.
These show up now as the gcc version on the nodes has increased.
|
| | |
|
| |
|
|
| |
We were passing the wrong param to the poststroke handling.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSS-fuzz #58582
The fundamental problem here is that pdfwrite was assuming that the
font WMode could only ever be 0 or 1 (the only two valid values) and so
was using it as a bitfield, shifting and OR'ing it with other values.
The file in this case has a CMap which contains :
/WMode 8883123282518010140455180910294889 def
Which gets clamped to the maximum unsigned integer 0x7fffff
This led to a non-zero value in the flags to the glyph info code, when
the value *should* have been 0, which caused the graphics library to
take a code path which wasn't valid. This led to us trying to use a
member of a structure whose pointer was NULL.
I can't be certain whether other places in the code use WMode in the
same way, so I've chosen to fix this at several levels.
Firstly, in the code path we shouldn't reach (gs_type42_glyph_info_by_gid)
check the value of pmat before calling gs_default_glyph_info. That code
will try to use the matrix to scale the outline, so if it is NULL then
the result is undefined. This prevents the seg fault.
Secondly, in gdevpdtc.c, scan_cmap_text(), set wmode to be either 0 or
1, to ensure that it does work as a bit, rather than using the integer
value from the font and assuming it will be 0 or 1.
Finally in the three places in the PDF interpreter where we set the
WMode for the font, check to see if the value is either 0 or 1 and if it
is not, raise a warning and make it 0 or 1.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSS-fuzz bug #58423
The problem is reported as a use-after-free, what I see is a colour
space persisting until long after the PDF interpreter has been freed,
and being cleaned up by the end of job restore.
Because the colour space was created by the PDF interpreter it has a
custom callback to free associated objects. But by the time we call that
callback the PDF interpreter has vanished.
This happens because in gx_pattern_load() we try to push the pdf14
compositor (the pattern has transparency) which fails. Instead of
cleaning up we were immediately returning, which was leaving the colour
space counted up, which is why it was not counted down and freed before
the interpreter exits.
Fix that here by using a 'goto' the cleanup code instead of returning
the error code immediately.
Also, noted in passing, we don't need to set the callback in
pdfi_create_DeviceRGB(), because that is done in pdfi_gs_setrgbcolor.
Not only that, but there are circumstances under which we do not want
to set the callback (if the space came from PostScript not created by
the PDF interpreter) and that is catered for in pdfi_gs_setrgbcolor()
whereas it wasn't in pdfi_create_DeviceRGB. So remove the callback
assignment.
|
| |
|
|
| |
See bug for full discussion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tests/pdf/Bug6901014_CityMap-evince.simplified.pdf.bitrgbtags.300.1.gs
tests/pdf/Bug6901014_CityMap-evince.simplified.pdf.pgmraw.300.0.gs
tests/pdf/Bug6901014_CityMap-evince.simplified.pdf.pgmraw.300.1.gs
tests/pdf/Bug6901014_CityMap-evince.simplified.pdf.ppmraw.300.1.gs
tests/pdf/Bug6901014_CityMap-evince.simplified.pdf.psdcmyk.300.1.gs
tests/pdf/Bug6901014_CityMap-evince.simplified.pdf.psdcmykog.600.1.gs
tests/pdf/Bug6901014_CityMap-evince.simplified.pdf.psdrgb.300.1 gs
tests/pdf/Bug6901014_CityMap-evince.simplified.pdf.tiffscaled.600.1.gs
tests_private/pdf/uploads/333.pdf.bitrgbtags.300.1.gs
tests_private/pdf/uploads/333.pdf.ppmraw.300.0.gs
tests_private/pdf/uploads/333.pdf.ppmraw.300.1.gs
tests_private/pdf/uploads/333.pdf.psdcmyk.300.1.gs
tests_private/pdf/uploads/333.pdf.psdcmyk16.300.1.gs
tests_private/pdf/uploads/333.pdf.psdcmykog.600.1.gs
tests_private/pdf/uploads/333.pdf.psdrgb.300.1.gs
These seem to be caused by us creating a memory device, then
detecting an error, and exiting with the device unused, but
half setup. That was enough to trip a problem when the device
is finalized by the gc system later.
Now, we move the operation that might cause an error to be before
the allocation of the memory device.
This leaves these files returning an error where previously they
didn't. This is less than ideal, so I've opened bug 706695 to track
that.
|
| |
|
|
|
| |
Copying a value twice. Fixing more for neatness than for
expectation of any other benefit.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, it looks like we are hitting a problem with the fix for
bug 703324.
When that fix resets the fillstrokealpha value after the stroke
it does so by fiddling directly in the pgs. In the clist writing
case, this means that the pgs changes without the change being
considered for putting into the reader. This can cause the reader
and writer to get out of sync.
The fix, implemented here, is to call gs_update_trans_marking_params
to ensure that the change happens via the compositor mechanism
first. This keeps reader and writer in sync.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code to handle fill_stroke in the presence of transparency
was being confused by the scaling applied to clipping regions.
When we fill_stroke, if transparency is present, then we need to
push a group. The bounds for this group are calculated based upon
the bounds for the path in question, expanded by an appropriate
amount for the current stroke strate, and then clipped by the
clipping path.
In the presence of alphabits, the path is scaled up, and so the
bbox for it needs to be scaled down. The clipping path is similarly
scaled, so this too needs to be scaled down.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSS-fuzz #58341
The problem is that a Pattern PaintProc uses another Pattern; the
initial Pattern dictionary does not use transparency, and does not
declare the use of the child pattern, that is used by name and found in
the /Page /Resources dictionary. The child Pattern uses transparency.
There's basically no way for us to tell that the initial pattern should
push the pdf14 device, so we don't. Later on when we do push the device
for the child pattern we try to copy the DeviceN parameters, but the
device we are pointing at is the pattern accumulator, which doesn't
store the DeviceN parameters and can't return them, so it returns NULL.
We then try to dereference the NULL pointer.
Obviously this is only a problem when trying to use a DeviceN device,
in this case the psdcmyk device.
To fix this 'properly' we would either need to push the pdf14 device for
every pattern or have the pattern accumulator copy, store and return the
DeviceN parameters when requested.
For now I've chosen just to avoid the crash because this isn't really
my field and I'm wary about making extensive changes. If anyone ever
comes up with a real PDF file where this causes problems we'll address
it then.
Note that the PDF file is already contravening the spec which says that
the /Resources dictionary is *required* for Patterns (at least if the
Pattern uses any named resources).
|
| |
|
|
|
|
|
| |
Another set of typos in the shading optimisation code. This is a
different "class" of typo than before. I've checked the code
so that we should be free of problems of this class at least
in future.
|
| |
|
|
|
|
|
|
| |
Bug #706571 "Segmentation violation at base/gscparam.c:342 (in c_param_write function)"
We don't permit mixed type arrays when parsing parameters, the number
parsing checked the array wasn't a string array, but didn't check to see
if it was a name array.
|
| |
|
|
|
|
| |
This is so that Memento wrapped blocks get the same alignment % 32
as the underlying malloc blocks. This is important for setjmp
buffer usage on Windows (at least, probably linux too).
|
| | |
|
| |
|
|
|
| |
If a device is marked as "non_strict_bounds" then any clipping
device built upon it should also be.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We've had several bugs in this code to do with getting stuck in
infinite loops, due to the accuracy of calculating midpoints.
Here, we tweak the tests so that they always choose NOT to loop
if the midpoint is close enough to the edge, so we should
always be safe.
Also, move the "completely out" clipping test to the top of the
loop where it can be more effective.
|
| |
|
|
|
|
|
| |
Where we combine and convert the font matrix and CTM scaling to pass through
the FAPI interface, we were always rounding values "up", meaning negative scale
values could rounded in the "wrong" direction, losing magnitude and hence
causing unintended drop-outs at very small scales.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706494 "Buffer Overflow in s_xBCPE_process"
As described in detail in the bug report, if the write buffer is filled
to one byte less than full, and we then try to write an escaped
character, we overrun the buffer because we don't check before
writing two bytes to it.
This just checks if we have two bytes before starting to write an
escaped character and exits if we don't (replacing the consumed byte
of the input).
Up for further discussion; why do we even permit a BCP encoding filter
anyway ? I think we should remove this, at least when SAFER is true.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Product family, date docs version for 10.01.0 RC 1
Update News.htm for 10.01.0
Version and dates in man pages
Dates and product string for 10.01.0rc2
Dates and product string for 10.01.0 release
|
| |
|
|
| |
Leftover from the old HTML docs
|
| |
|
|
|
|
|
|
| |
It seems that the pipe opening code can copy a string on top
of itself. No point in that, and it's strictly against the
C rules. Avoid that case.
Thanks to Youngseok Choi for the report.
|
| |
|
|
|
|
|
|
|
|
|
| |
In the command line dictionary parsing, we were assuming
that there would be a close dict marker (">>") in the string
buffer after parsing completes. When that wasn't there
we might overrun the buffer.
Now check for it being there and raise a syntax error if not.
Thanks to Younseok Choi for the bug report.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running:
gs "-I%%"
will cause gs_parse_file_name to be called with pname="%%" (no
terminator!) and len == 2. pdelim = pname + 1.
So the test for pdelim[1] == 0 overruns the buffer.
The fix is simply to reverse the order of tests within
the if.
Many thanks to Youngseok Choi for the report.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When asking for the free space available, we have to be careful
when returning what might be a size_t in an int. In particular
this causes problems with 3G bufferspaces resulting in errors
as the value they return becomes a negative int.
The fix here is to clip the available buffer space at INT_MAX.
This is fine, but reworking the code to use an explicit
size_t return would probably be better eventually.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We create a device structure on the stack, and fill in just
enough of it to be able to use existing code to return the
size.
Unfortunately, this produces valgrind warnings as some of
the proc setup code trips over the device procs not all being
zerod to start with.
For the sake of valgrind, just clear the device when we
create it. This is not something that happens often, so
the speed hit should be negligible.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No bug report, this came up from cluster 32-bit testing.
Commit 6894a2826210baf24f9ccd024bbca211b17d1f9b altered the params
union of the colour space structure. At the time I made a change in
gs_cspace_final() because it was possible for us to fill in some of the
new params, and have them write to areas of the union which, when
interpreted as a DeviceN params structure, meant that the
devn_process_space member of that structure was not NULL.
Because the code only checked if the member was non-NULL and didn't
check if the colour space meant it should even be interpreted as a
DeviceN params structure this meant we could try to free random
memory.
It turns out there are two other important places that do the same, the
garbage-collected pointer and relocation code do pretty much the same
thing with the devn_process_space member.
This commit checks the colour space to see if its a DeviceN space and if
it is not then it does not attempt to relocate the pointer, nor does it
enumerate it (enumerates a NULL instead).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #705865 "PDF Writer is dropping the /Alternate color space for ICC based color profile"
This commit starts off with the bug referenced above. Prior to this
commit the PDF interpreter never set the /Alternate space for an
ICCBased colour space. For rendering there is no need since Ghostscript
will always use the ICC profile, or will set the /Alternate instead
(if there is an error in the ICC profile) or will use the number of
components (/N) to set a Device space if there is a fault in the ICC
profile and no /Alternate.
However, this means pdfwrite never sees an Alternate space to write out
for an ICCBased space. This should not be a problem since the
/Alternate is optional for an ICCBased space and indeed the PDF 2.0
specification states "PDF readers should not use this colour space".
The file for the bug has a /ICCBased space where the /Alternate is
an Lab space. Obviously any PDF consumer should use the ICCBased space
but it seems that Chrome, Firefox, possibly other browsers cannot handle
ICCBased colour and so drop back to the Alternate. Surprisingly they
can handle Lab and get the expected colour. Obviously if we drop the
/Alternate then these consumers cannot use Lab and have a last ditch
fallback to RGB (based on the number of components, and that *is* in the
spec). But RGB != Lab and so the colours are incorrect.
Ideally we would simply use the existing colour space code and attach
the alternate space to the ICCBased space's 'base_space' member. That
would write everything perfectly well. But we can't do that because
when we are called from Ghostscript the ICC profile cache is in GC'ed
memory. So we have to create the ICCBased colour space in GC'ed memory
too. We have special hackery in the PDF interpreter colour code to do
exactly that.
Colour spaces call back to the PDF interpreter when freed (with more
hackery for ICCBased spaces), but if we create colour spaces in non-GC
(PDF interpreter) memory and attach them to the ICCBased space in GC'ed
memory then they can outlive the PDF interpreter, leading to crashes.
I did start down the road of making all colour spaces in GC-ed memory,
but that rapidly spiralled out of control because names needed to be
allocated in GC'ed memory, and functions and well, all kinds of things.
Without that we got crashes, and it quickly became clear the only real
way to make this work would be to allocate everything in GC'ed memory
which we really don't want to do.
So instead I added a new enumerated type member to the colour space, in
that member, if the current colour space is ICCBased, we store the type
of Alternate that was supplied (if any). We only support DeviceGray,
DeviceRGB, DeviceCMYK, CalGray, CalRGB and Lab. I also added the
relevant parameters to the 'params' union of the colour space.
In the PDF interpreter; add code to spot the afore-mentioned Alternate
spaces if present, and if we haven't been forced to fall back to using
the Alternate (or /N) because the ICC profile is broken. When we spot
one of those spaces, set the colour space ICC_Alternate_space member
appropriately and for the paramaterised spaces gather the parameter
values and store them.
In the pdfwrite device; if we are writing out an ICCBased space, and
it's ICC_Alternate_space member is not gs_ICC_Alternate_none, create
a ColorSpace resource and call the relevant space-specific code to
create a colour space array with a name and dictionary containing the
required parameters. Attach the resulting object to the ICCBased
colour space by inserting it into the array with a /Alternate key.
This also meant I needed to alter the parameters passed internally to
pdf_make_iccbased so that we pass in the original colour space instead
of the alternate space (which is always NULL currently).
There are also a couple of fixes; when finalising a colour space check
that the colour space is a DeviceN space before checking if the device_n
structure in the params union has a non-zero devn_process_space. The new
members in the union meant we could get here and think we needed to
free the devn_process_space, causing a crash.
In the PDF interpreter; there's a little clause in the PDF specification
which mentions a CalCMYK space. Apparently this was never properly
specified and so should be treated as DeviceCMYK. The PDF interpreter
now does so.
Finally another obsrvation; the initial code wrote the /Alternate space
as a named colour space, eg:
19 0 obj
<</N 3
/Alternate /R18 /Length 1972>>stream
....
Where R18 is defined in the Page's ColorSpace Resources as a named
resource:
<</R18
18 0 R/R17
17 0 R/R20
20 0 R/R22
22 0 R>>
endobj
But this does not work with Chrome (I didn't test Firefox). For this to
work with Chrome we have to reference the object directly, which should
not be required IMO. I believe this to be (another) bug in Chrome's PDF
handling.
|
| |
|
|
|
|
|
|
|
|
|
| |
A C parameter list leaks when used in gpdl. Presumably this is
not seen in gs operation because of garbage collection.
We already have a function to allocate a C parameter list
(gs_c_param_list_alloc). We've always been releasing this
(gs_c_param_list_release), but that just releases the contents
not the list itself. Add a new function (gs_c_param_list_free)
that both releases and frees, and call this as appropriate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the display device with separations in chunky mode, we
insist on 8 components all the time.
In planar mode, the calculations go wrong, and we get crashes.
Update it here so that we don't crash.
Planar separations will use a maximum of 64 components.
In the case of a PDF file where the number of components in use
are known up front, we will run with the correct number of
components.
In the case of a PS file where the number of components is unknown
until rendering has completed, we run with the maximum number of
components, and the display device user can just take the required
number at the end.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Revert "Bug 706368: alphabits device declares invalid width/height."
Use the horrible, hacky non_strict_bounds flag instead.
Ideally this should be fixed in a better way, but this should
hopefully stabilise things for the release.
|
| |
|
|
|
|
|
| |
This indicates that callers cannot assume that any calls to a
device will be clipped at device bounds. In particular the
alphabits device needs to set this as the width/height that
it uses are misleading at best.
|
| |
|
|
|
|
|
| |
We missed updating the clist code to initialise the new
imagematrices_are_untrustworthy member. Consequently in
some cases we were failing to clip the amount of images
we were interpolating.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Spun out of bug 706373, though not believed to be a fix for it.
When we calculate pattern matrixes and bboxes etc, floating point
accuracy conspires to work against us, in particular where we
end up mapping boxes back and forth via inverse matrices.
The rounding is such that we can end up expanding the number of
repeats that we have to render.
We try to be smarter about that (or at least to give saner bboxes
and matrices that are easier to debug) by employing some smart
("sane") rounding.
|
| |
|
|
|
| |
The logic for subdividing patches can be stymied by illegal
rectangles. Detect these early on.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the new subdivide_patch_fill_floats code (and indeed
in subdivide_patch_fill), there was a flaw in the logic.
Consider a rectangle (0,0) (100,100) and a patch with
v[0].p = v[1].p = v[2],p = v[3].p = (0,101).
We would therefore arrive at check_rot_bottom, and calculate
m0 = m1 = 101.
This is not <= rect.q.y, so we would continue through the
calculation, setting changed without actually changing the
coords of the patch.
The fix is to test against the same value in the middle of the
loop as we do at the end.
Do this throughout the code.
|
| |
|
|
|
|
|
|
|
|
| |
We now assume that every device will give a true width and
height (or set them to zero), so that callers can clip graphic
operations to the extent of the device that is being called.
The alphabits device was breaking this, and giving a much smaller
width/height than was really the case. This caused us to incorrectly
clip.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing arguments, we have special handling for quote
marks. We interpret them as literal quotes, unless they are
either at the start of an argument, or immediately following
an '=' sign, so that:
ThisIsAFileWithA"InTheName.pdf
and
-sOutputFile="File 1.pdf"
both work as you'd expect.
Unfortunately, in the dim, dark, uncharted past that is
Ghostscript history, someone decided that it'd be a spiffy
idea for people to be able to use the hash character (that
one that I can't type in here because git will think it's
a comment character) as a replacement for '='.
The special handling to keep track if we had just seen an
equals sign was not coping with having just seen a hash
mark. Fixed here.
We also take the opportunity to fix a memory leak in the
handling of @files - ensuring we free the allocated block
for the stream when we return from reading from it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we set out to render an image, we calculate the target
rectangle. We attempt to reduce this according to the
clip path as much as we can so as to limit the amount of
excess work we do - particularly for interpolated images.
Unfortunately, in some cases (including some clist cases) this
code is called without a clip path in place, and so we were
failing to clip the target at all. This meant that for images
that spanned the whole page, we could end up interpolating the
whole image for every single band.
Here, we adapt the code so that in the absence of a clip path
we use the bbox of the target device as bounds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The pdfwrite device can 'rewrite' the image matrixes in a
particularly nasty way that is not easy to avoid. It does this
to be able to capture images with masks of a different size.
Unfortunately, this breaks any possibility of us using the
imagematrix to figure out which source region of the image
we actually need for clipping.
Introduce a new flag to capture when this happens so we can
avoid relying on an untrustworthy imagematrix.
|
| |
|
|
|
|
|
|
| |
Shadings which have patches that are so large that they won't fit
in fixed point representation could be slow. By duplicating the
code from subdivide_fill_patch into a floating point version
(subdivide_fill_patch_floats), we can drastically improve
performance on such cases.
|
