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.
By default, _DATA files are not included. Hence `make distcheck` fails
with:
*** No rule to make target 'pyconsole.py', needed by 'all-am'.
Let's add it back.
As a consequence of commit efae55a, plug-ins should not install
data/library files alongside on the root plug-ins/ directory. If they
have such files, they should create a subdirectory named as the entry
point file. Obviously we should be the first to follow this guideline.
We had one such plug-in: python-console.py, which is importing
pyconsole.py. Let's have both these files under
plug-ins/python-console/.
Add "import-raw-plug-in" to gimprc, and a new procedure
gimp_register_file_handler_raw(). On startup, remove all load
procedures that are marked as "handles raw" but are not implemented by
the configured plug-in. Add the list of available plug-ins to prefs ->
import/export. Register all file-darktable procedures as handling raw.
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.
... and get rid of the dedicated op. This gives us support for all
the blend/composite options for this mode.
Rename COLOR_ERASE to COLOR_ERASE_LEGACY, with perceptual blending/
compositing and immutable everything, and add a new COLOR_ERASE
mode, defaulting to linear blending/compositing, with mutable
everything. Modify affected code.
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.
being exported to libgimp, and having a non-exported value, this is a
horrible mess like with GimpLayerMode, but at least the cruft value
names are deprecated now.
Commit e518b97 broke Win32 compilation with a non-defined variable
"monitor". I made a dirty "fix" by using shootvals->monitor.
Apparently, seeing previous comment, that is probably not the right
value but Mitch is on it and I leave him work it out.
At least now it builds.
The colon-separated list used in the plugin originally comes from
gimp_help_get_locales() anyway. My previous code was using different
lists of locales in different places, which was inconsistent.
Be a little cleverer about what locale we care about in the context of
the help system. Variants and encoding in particular are of no interest
to us.
Let's also always add a base language (like "en" for "en_GB") rather
than fully trusting g_get_language_names() since it seems to return
funny results on some platform.
Finally check for duplicates before adding to language list.
It seems that the Windows platform could sometimes return locales in the
form en-GB (so an IETF language tag, I guess) instead of a POSIX locale.
This little hack should take care of the easy cases until we get a
better and generic fix.
Jehan