The new metadata viewer is based on a version of the old metadata
plugin that still contained this bug, and a few other bugs that've
been fixed since then. Reapply those fixes to the new plugin.
This is essentially an adaptation of commits
f8e291bf31,
ce9e7feabd,
38c79600f1,
and 801bd8fb3f.
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.
There are now (up to) three steps to locate an installed darktable used
to load raw files:
1. The environment variable DARKTABLE_EXECUTABLE. It should point to the
main darktable executable without any file extension. So on Windows
leave the ".exe" away!
2. If the environment variable isn't set there is a platform dependent
part. On OSX it uses Kris' code to look for installed app bundles, on
Windows it checks for the registry key written by darktable's installer.
3. Last but not least we fall back to crossing our fingers and hoping
that darktable is in PATH.
query() is run only the first time for efficiency. Yet this plugin is
dependent on the presence of `rawtherapee` which may be installed or
uninstalled between GIMP startups. Therefore we should move the usual
gimp_install_procedure() to init() so that the check is done at every
startup instead.
I wonder if these should not rather be simply removed instead, but well
I'll leave them if the plugin developer needs these regularly for
testing. Use at least C-style comments as per our coding style.
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.
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.
Michael Natterer