And always pass URIs to all file procedures, the ones what didn't
register as "handles remove" will only ever get local file:// URIs.
Change all file plug-ins (also legacy ones) to expect URIs instead
of filenames, and convert to local paths in the plug-in.
The wire protocol should now be almost 100% clean of non-UTF-8 strings.
Commit dc069e424a removed the
assumption that 1-bpp PCX files are B&W, in favor of using the
provided palette, which is (supposedly?) the correct behavior.
However, there are evidently B&W files that do not specify a
palette, resulting in an all-black image (i.e., a 2-color indexed
image, whose both palette entries are black). Since other
software, including older versions of GIMP, load such files
"correctly", let's fix this by falling back to a B&W palette when
the provded palette is uniform.
Add line data padding when necessary.
Additionally I realize we should convert to little-endian after checking
the bytesperline oddness (this bug was most likely unnoticed until now
as most desktop proc are little endian now anyway).
...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().
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.
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>
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.
and clean up the formatting of the call and the lines around it. Now
we can check the various (disabled) export options for regressions
again by changing a single line in gimp_export_image().
I'm sure some plug-ins need to add their items *not* at the toplevel,
but since making plug-ins really tree-aware is a lot more work than
just fixing insert positions, I went for passing -1 as parent in
almost all cases. And because of laziness...
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2008-08-18 Sven Neumann <sven@gimp.org>
* plug-ins/common/file-mng.c
* plug-ins/common/file-pcx.c: for the most common errors,
pass the error message with the return values instead of calling
gimp_message().
* plug-ins/common/file-gif-save.c
* plug-ins/common/file-pdf.c
* plug-ins/common/file-png.c: minor cleanup.
svn path=/trunk/; revision=26638
2008-08-11 Michael Natterer <mitch@gimp.org>
* plug-ins/bmp/*
* plug-ins/faxg3/*
* plug-ins/fits/*
* plug-ins/fli/*
* plug-ins/ico/*
* plug-ins/jpeg/*
* plug-ins/psd/*
* plug-ins/sgi/*
* plug-ins/uri/*
* plug-ins/xjt/*: removed these...
* plug-ins/file-bmp/*
* plug-ins/file-faxg3/*
* plug-ins/file-fits/*
* plug-ins/file-fli/*
* plug-ins/file-ico/*
* plug-ins/file-jpeg/*
* plug-ins/file-psd/*
* plug-ins/file-sgi/*
* plug-ins/file-uri/*
* plug-ins/file-xjt/*: and moved them here. Changed executable
names to "file-foo".
* plug-ins/Makefile.am: changed accordingly.
* plug-ins/common/*: rename all file plug-ins to file-foo.c. Get
rid of the names "poppler" and "postscript" and call them
"file-pdf" and "file-ps" because the conflict with standard
autofoo targets is gone.
* plug-ins/common/plugin-defs.pl: changed accordingly.
* plug-ins/common/mkgen.pl: make sure cflags variables are named
"PLUG_IN_NAME_CFLAGS" and not "PLUG-IN-NAME_CFLAGS"
* plug-ins/common/Makefile.am: regenerated.
* configure.in: change folders and variable names to match above
changes.
svn path=/trunk/; revision=26494
Michael Natterer