(AKA Issue with grain merge layer mode)
Fall back to using the legacy grain-extract/merge modes when the
input image precision is integer, and only use the non-legacy modes
when the precision is floating point. The midpoint intensity value
of the non-legacy modes is 0.5, which isn't representable exactly
using integer precision, causing small deviations between the input
image and the reconstructed image.
A malicious XMC file can contain an invalid TOC count, which could lead
to an out of boundary write on 32 bit systems due to integer overflow.
This error occurs during thumbnail creation.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Without a domain error, glib outputs on console:
> g_error_new_valist: runtime check failed: (domain != 0)
Let's just create a domain error for the file-pdf-load plugin.
Add an option to keep the decomposition in a layer group.
Add an option to add layer mask to each scales layers.
Do not use 'new from visible' because it produces unexpected result when
- image is already composed by several layers
- target layer has not the same size as the image canvas
Replaced by succession of layer copy and merge down.
This is a new API function, so now is the right time to add missing
parameters! This will allow to load a selection of pages, and even to
reorder the document while doing so. Or simply load all pages in the
right order with n_pages <= 0.
... by default.
Even though selecting nothing is equivalent to selecting all in our
code, let's just explicitly select all pages before showing the dialog
so to make this behavior explicit.
When there is a well-documented GError domain/code, use these,
especially since messages can be localized (not sure if that is the case
for this one, but theoretically it could) and change over time.
Also remove the "nice-to-have" comment on file-pdf-load since we won't
be changing it now, but leave it on file-pdf-load2 parameters which can
still change before 2.10.
- Clean out some C++ style comments (our coding style only accepts
C-style comments. Anyway these comments were just old useless code).
- A block indentation fix.
- As a guideline, it is better to keep a GError as the last parameter.
- In non-interactive mode, the new procedure must use the value in
parameter, otherwise passing the password just doesn't work.
Supports for password protected PDF. When an encrypted PDF is opened, a
dialog box asks for the password.
When an encrypted PDF is opened, a dialog box asks for the password.
The password dialog box loops as long as the password is wrong (or user
hits CANCEL/escape key)
Reviewed and fixed by Jehan.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
The signature of the original file-raw-save procedure must not change,
so change it to use the old parameters.
Change the other procedure (with additional arguments) to
file-raw-save2.
Currently, toggling RGB565 makes the RLE toggle insensitive, but
if RLE is checked beforehand RLE is used anyway, with incorrect
results.
Fix this by adding RLE support for RGB565 data.
Current comment was implying that PDF had some kind of fixed PPI, or
that a 72 PPI was hardcoded in cairo. This is not at all what this is
about. Cairo simply has a concept of user-space coordinates, and from
what I gather, it seems that this is set as "point", the typographical
unit of measure (not as a screen point). In such context, cairo_scale()
is used to update the transformation matrix (which will transform from
user to device units, i.e. pixels) so that we can draw with pixels. In
other words, both the user and device units will be pixels in subsequent
calls.
It turns out that 1 inch == 72 points. This is not a PPI/DPI at all and
the comment was completely misleading.
No need to loop through layers, which may be wrong anyway with
layers-as-pages. Also we were using the layer sizes without even
checking their offsets yet filling from (0, 0). This code was flawed in
many aspects.
Cairo doc is pretty clear about cairo_mask_surface():
> A drawing operator that paints the current source using the alpha
> channel of @surface as a mask
Therefore when creating a mask surface, it must be in one of
CAIRO_FORMAT_* with an alpha channel and the mask data must be copied
into this alpha channel. I chose CAIRO_FORMAT_A8 (a format with alpha
only) which I map to "Y u8" babl format in GEGL so that
gegl_buffer_copy() copies the contents of Y into A.
The `if` test was inverted. When the option is checked, we don't want to
add the GIMP_EXPORT_CAN_HANDLE_LAYER_MASKS capability so that
gimp_export_image() applies the mask.
This is a first step to fix bug 783528, but it's not finished. Right
now, when the option is unchecked, the mask is simply ignored. We want
to export a PDF mask instead.
And revert file-pdf-save to its previous signature before commit
d03de52. For compatibility reason, we can't change the signature of a
procedure available in previous stable releases.
Also revert file-pdf-save-multi for the same reason. I don't create a
file-pdf-save-multi2 though even though layers-as-pages could still be
meaningful there (creating a multi-page PDF from several multi-layers
images) but that's likely a special case which can be dealt with later.
Obviously the interactive export will use file-pdf-save2.
Otherwise default values are not taken into account in interactive mode.
In particular, we want ignore-hidden to be checked (TRUE) by default,
because this is the most obvious behavior (WYSIWYG).
Commits 8d4642f and daa5611 reviewed. I was only unsured on usage of
header vs EOF palette as well as the non-B&W monochrome palette since we
don't find a single authoritative spec. Nevertheless the implementer has
good argumentation so let's go with this. Simply I add some comments
about these 2 points in the code, just in case for future references.
+Allows user to save indexed 1bpp and 4bpp PCX files automatically,
depending on the number of colors used.
+Creates a general function with parameters for both bpp and # of
planes, to handle more PCX file types (1bpp, 2planes; 1bpp, 2planes;
4bpp, 1plane).
+Removes assumption when loading colormap that 1bpp files are black &
white only; loads both colors from PCX palette header instead.
https://bugzilla.gnome.org/show_bug.cgi?id=159947
Allows saving 1bpp and 4bpp indexed PCX files based on number of colors
used in image. Also provides ability to load additional PCX formats:
2bpp, 2 planes 1bpp, 3 planes 1bpp, 4bpp.
Integer overflows allow out of boundary writes while reading GIH files.
The checks are copied from file-gbr.c. In turn, the necessary gsize
casts are added in file-gbr.c, too. These are important on 64 bit
systems. Without these casts, the precision of the calculation is still
32 bit, allowing overflows.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
If a PCX file contains a bytesperline entry which is too small, it is
possible to trigger an out of boundary read, which can lead to a
segmentation fault.
The bytesperline validation is incomplete. While checking if enough
bytes per line exist, the integer truncation during the division must be
taken into account.
An example would be a 1x1 PCX file with a bpp of 1 (monochrome). The
current check allows a bytesperline field of 0, which in turn would lead
to a 0 byte allocation in load_1. Yet, the code would access index 0.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
If either width or height is 0, gimp won't process the PCX file.
Instead, a bunch of error messages are printed.
It's nicer to quit parsing the file early on with a good error message
which is straight to the point instead.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
It was agreed that we should write "plug-in" consistently. Only possibly
user-visible strings were updated.
Thanks to scootergrisen for a first patch which could not make it
after changing decision on the canonical writing.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
