This new capacity was created just 3 commits ago (9933f46f85).
The point was that the real fix is to remove the implication
HANDLE_LAYERS => HANDLE_ALPHA, but this breaks public API behavior,
which is why I didn't go with it.
Still it just felt wrong to add a NEEP_OPAQUE capability when it should
be the same thing as not setting HANDLE_ALPHA. After discussion on IRC,
we decided that this implication was basically a bug, and since in all
core plug-ins, when HANDLE_LAYERS was set, we were also setting
HANDLE_ALPHA, no core plug-in code even has to be changed. As for
third-party plug-ins, let's assume that none has been relying on this
wrong assumption.
G3/G4 compression does not support transparency, yet in multi-layer
export, gimp_export_image() capability GIMP_EXPORT_CAN_HANDLE_LAYERS
implied GIMP_EXPORT_CAN_HANDLE_ALPHA. I guess multi-layer TIFF is more
for multi-page (at least with G3/G4 which is apparently a fax format, so
it makes sense) than actual multi-layer.
So I use the new GIMP_EXPORT_NEEDS_OPAQUE_LAYERS capability from
previous commit for this particular use case of export layers + G3/G4
compression.
Also it is better to run gimp_export_image() *after* the option dialog,
as we do for other formats, with variable capabilities depending on
which options was chosen, instead of running it before then after
merging layers when user chose not to export layers. This is duplicating
the purpose of gimp_export_image().
Currently capability GIMP_EXPORT_CAN_HANDLE_LAYERS implies
GIMP_EXPORT_CAN_HANDLE_ALPHA. Though in many cases, multi-layer implies
alpha for basic compositing, our export plug-ins sometimes use the
concept of "layer export" for multi-pages or collection files.
Additionally sometimes alpha may not even be supported at all whereas
layers are. This will be the case in the next commit which will make use
of this new capability.
file_open_location_response(): guard against g_file_new_for_uri()
returning NULL (which it shouldn't) and an error being NULL (which it
shouldn't either for the same reason). Spotted by Massimo.
...gimp_size_entry_set_resolution: assertion 'GIMP_IS_SIZE_ENTRY (gse)'
failed
In gimp_tool_options_manager_tool_changed() make sure the new tool's
tool options GUI always exists, so tools can access it even if the
tool options dockable is not currently open.
Found in my stashes, I have no idea why I even bothered but it just
needed a minor fix to work, so here we go. Stupid port that always
uses 8 bit and kills higher bit depths.
so gimp_curve_equal() doesn't fail on random uninitialized padding
bits. Fixes finding previously used settings in the curves tool (they
were piling up just by re-applying a previously used setting).
Don't clear the preset combo right after a preset was selected.
Instead, clear it as soon as any change is made to the settings in the
dialog. This way the last chosen preset's name stays in the combo as
long as the current settings are identical to the preset.
Use gimp_image_metadata_load_finish() and pass the right flags
depending on whether comment and profile were loaded. Also, set the
profile before creating the layer so its space is correct
automatically.
Use the drawable's space for the load/save formats to avoid unwanted
color conversions. Also cleaned up the loading code a bit, it was
doing weird duplicated stuff for the preview and !preview cases.
Make better subvision, as well as ruler steps, based on what seems to be
the common trends for rulers of these 3 units (inch, foot and yard), but
also based on common conversion needs.
Main changes are:
- Always subdivide inches by 2, down to 1/256, and get rid of the gap
where inches division jumped from 1/16 to 1/192 (which is not even a
multiple of 2).
- Add the 72 steps to inch ruler (1 fathom).
- Replace the 2 feet by a 3 feet (1 yard) step.
- Use base-10 steps for yard (there don't seem to be bigger units in the
imperial/US measurement system which needs specific steps).
- Add the 1/36 yard (= 1 inch) division.
- Below 1/12 feet and 1/36 yard, divide by multiples of 2 (inch-style).
...doesn't work
Rename the labels to "built-in sRGB color profile" and "built-in
grayscale color profile" because that's what the option does, it never
converted to the preferred profiles from preferences.
...always AdobeRGB!
Enable the code in gimp_image_metadata_update_colorspace() which syncs
the DCF information to the image's actual color profile, at least as
good as it can, and otherwise sets it to "unspecified".
Also fixes issue #301.
Jehan