| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
- Adds GPDL to TOC and tweaks Home icon CSS.
- A better TOC, updated copyright header.
- Adds headers in Use.rst for basic use examples.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Thanks to Bruno Voisin for spotting this.
|
| | |
|
| |
|
|
|
|
| |
Bug #706476 "<</DecodeParms null>> causes a bogus warning"
A null object for DecodeParams is legal. Pointless but legal.
|
| |
|
|
|
|
|
|
|
| |
Bug 706474 "Segfault in gs for PDF with encrypted streams and unencrypted strings"
This is a simple typo, unencrypted streams are handled by an early exit
from pdfi_filter, so we should never see a CRYPT_IDENTITY case, just
as the comment says. But we were looking at the string encryption,
not the stream encryption. A one letter typo....
|
| |
|
|
|
|
|
|
| |
Chunky separations were SEGVing due to a the device proc for
fill_rectangle_hl_color not being setup.
Planar separations were buffer overflowing due to a short allocation
for the bitmap due to unknown number of separations.
|
| |
|
|
|
| |
This makes it easier to see which exact interpreter function
is throwing an error.
|
| | |
|
| |
|
|
|
| |
Both planar and chunky separations need our own
fill_rectangle_hl_color routine.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The display device can be initialised in a 'disabled' form when
the callback is NULL. It seems we can get fill_rectangle called
when in such a state, and we may not have initialised it, causing
a SEGV.
The fix is to initialise this to the usual display_fill_rectangle,
function which will do nothing if callback is NULL, but won't
crash.
Thanks to Youngseok Choi for the report.
|
| |
|
|
|
|
| |
- Adds new version number to conf.py
- Removes -dOLDSAFER & old language-bindings folder.
- Updates PDF version
|
| |
|
|
| |
Leftover from the old HTML docs
|
| |
|
|
|
|
| |
Check a function pointer is non-NULL before calling it.
Thanks to Youngseok Choi for the report.
|
| |
|
|
|
|
|
|
| |
If "-Z:" debugging is enabled, and the interpreter exits without
doing anything, we can attempt to access a memory structure
without it being there. Guard against this.
Thanks to Youngseok Choi for the report!
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code is poorly documented, and an unholy mix of "int", "word"
and "ulong" pointers, but I think I've understood the problem
enough to solve it.
The bug uses a single pixel wide device. It's therefore dealing
with lines that are expected to be 3 bytes wide. It allocates
buffers based on this number.
But it actually processes a larger number of pixels per line -
namely the number of pixels that will fit into the expected
amount of storage, rounded up to a 'word'. When words are 64bits
this makes much more difference than when they are 32.
Accordingly, we allow for this extra when allocating our buffers.
This should be a harmless change, as effectively all I've done is
allocated a buffer to be slightly larger than before.
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we spot early on that that we can't create a complete copy of a font (i.e.
if the font is incrememntally defined), we discard the attempted complete copy
and set the "complete" pointer to the same as the "copied" (subsetted) pointer.
But it turns out that, later, there is also a code path that requires discarding
the "complete" font, which wasn't accounting for the possibility that the two
pointers pointed to the same font object.
So, we now check whether the two pointers are the same, and if so, we simply
null the "complete" pointer.
Fixes oddly hard to reproduce segfaults from the nightly and weekly tests.
|
| |
|
|
|
| |
If the font-specific glpyh name function returned an error then the
glyph name is not valid, don't attempt to use it!
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
In copy/pasting from one function to another, I had failed to
replace 'subfont' with 'font'. I thought tested this both
locally, and in the cluster. The cluster doesn't test this
file.
I can offer no such excuse for why my own local testing didn't
show it up. Apologies.
|
| |
|
|
|
| |
Not entirely sure when these became broken, but we now get results
in keeping with MuPDF's usage of extract.
|
| |
|
|
|
| |
The pgs doesn't change, and we only initialise once, so this
does the same thing, and is clearer.
|
| | |
|
| |
|
|
|
| |
I actually fixed this BEFORE the previous commit, but somehow I
failed to include it in the commit.
|
| |
|
|
|
|
|
|
| |
If fnamelen was very long (4091 or more) then later when we add in
the fontdirstr we could end up running off the end of a buffer (fstr)
which is set as being gp_filename_sizeof bytes long.
Change the length check to account for this possibility.
|
| |
|
|
|
|
|
|
| |
Attempt to autodetect between linux and darwin. 32bit/64bit/arm
options are just gravy.
Credit to Chris for the original version of this (that I've
probably broken).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
In my previous revision for this, I missed that the values from a CMap
(ToUnicode) are big endian, but the values from the built-in decoding are native
endian.
This should resolve that.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The "dynamic" X11 devices rely on accessing symbols that are not part of our
"public API", symbols that are "hidden" with --enable-hidden-visibility (now the
default).
So, in configure, throw an error if --enable-dynamic is used without opting
out of hidden symbols (--disable-hidden-visibility).
|
| |
|
|
| |
Need to explicitly include extract src dir in the includes.
|
| |
|
|
|
| |
A character array was accessed incorrectly and we now include a
complete dump of downloaded fonts with the font debugging option '='.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At various places in the code, we test for parameters from a
param_list by using:
if (!strncmp(param, "ParamValue", strlen("ParamValue"))
This is bad, because as well as matching "ParamValue" and
"ParamValue=", it will also match "ParamValueSomething".
Also, at various places in the code, we don't call strlen
(understandably, cos that's a runtime function call to retrieve
a constant value), and just wire in the constant value. But
in at least 1 location, we've got the constant value wrong.
Accordingly, move to using an 'argis' macro that tests correctly
and calculates the length at compile time.
|
| |
|
|
|
|
|
| |
Only stop passing params to languages on an error, not on
a non-zero return code.
This was causing arguments not to make it to SO for processing.
|
| | |
|
