Thick lines are drawn by gdImageFilledRectangle(), which iterates over
the x ordinate first (Z order) to apply the style pattern. While this works
fine for vertical and diagonal lines, it obviously fails for horizontal
lines, which have to be iterated over in N order.
To fix this bug, we introduce the helpers gdImageFilled(H|V)Rectangle(),
which may be reused for other purposes as well.
This is basically the same fix as libgd/libgd/c2b91dbc.
The stack overflow is caused by the recursive algorithm in combination with a
very large negative coordinate passed to gdImageFillToBorder(). As there is
already a clipping for large positive coordinates to the width and height of
the image, it seems to be consequent to clip to zero also.
Contrary to imagefilledrectangle(), imagerectangle() has the documented
limitation that the given points have to be the upper left and the lower right
corner, respectively. However, libgd already caters to upper right / lower left
pairs, and not catering to the other two combinations seems to be an oversight.
The code in the bundled libgd uses libvpx and writes the riff manually. The
code generates the correct even size, but neglects the padding. It's possible
older versions of libwebp would decode this, but libwebp 0.4.0 does not.
Let's apply the patch supplied by one of the WebP developers.
Contrary to the external libgd, the bundled libgd doesn't use optimized
rotation algorithms for negative square angles. We fix that now.
There are other improvements in gdImageRotateInterpolated() in the external
libgd. I'll leave them out for now, in the hope that we'll be able to rejoin
the two libraries rather soon.
imagescale(..., IMG_BICUBIC) is not supposed to work with palette images, so we
fix that by converting to true color if necessary. Basically the same fix has
already been applied to the external libgd[1].
[1] <723ea520be>
To avoid drawing the corner pixels twice, gdImageRectangle() draws the vertical
lines 2 points shorter than the actual side of the rectangle. However, this
causes "whiskers" for rectangles with height 0. This patch fixes this issue and
at the same time optimizes the algorithm by drawing only a single line for zero
height and zero width rectangles.
Actually, this is not really a bug fix, but rather a simplification and
optimization in the same vein as has been done with the external libgd, but
going a small step further and joining both for loops.
From upstream d41eb72cd4
Fix build with latest libvpx 1.4.0
These new constants exist at least since 1.0.0
Compatibility ones have been droped in 1.4.0
strtok() is not thread safe, so this will potentially break in
very bad ways if used in ZTS mode.
I'm not sure why gd_strtok_r() exists since it seems to do the
same thing as strtok_r(), but I'll assume it's a portability
decision and do as the Romans do.
Upstream 463c3bd09b
Notice: this fix don't manage monochrome/monovisual values
but just fix the security issue CVE-2014-2497
failing when trying to load such an image
