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.
When working in high bitdepth, manually changing precision to 8bit or 16bit is
an extraenous step, this adds a conversion step - but doesn't permit dithering
- and also doesn't permit using the palette modes of PNG. However it makes
workflows with single precision linear floating point much more usable.
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
Exif tags may have long values, which can choke GTK if we display
them in their entirety. Truncate tag values (based on type, and
with proper indication) to avoid that.
This commit also hides private tags, and fixes some memory leaks.
Michael Natterer