One of the big improvement in this commit is that text layers are now much
better at space accuracy. They were already space-aware, yet rendered as sRGB u8
only before being converted to the image's space. It means that text layers had
the following limitations:
* Any color out of sRGB gamut were trimmed.
* Precision was always 8-bit (even if the image was high-bit depth).
Now GimpTextLayout keeps track of its source space (for RGB and CMYK only, this
won't be as easy when we will support more backend, since Cairo has only RGB
support for image data) and the image TRC (in case it bypasses the color space's
TRB) and it draws within this gamut and space.
It means first that we are not limited to sRGB colors; we will draw text main
color in the full image gamut, with still 2 remaining limitations:
* Unbounded colors are impossible because Pango format (to color text) uses
hexadecimal (so even with half/float images, you can't draw out-of-gamut text
unfortunately).
* Main color precision is still 8-bit, yet a tiny bit better than before as we
at least follow TRC (so we avoid some of the precision loss when converting,
even though the bit-depth is still the biggest loss).
The outline color on the other hand is drawn through Cairo API entirely, in
float. This means that the outline color will now be without any precision loss.
Note that this depends on CAIRO_FORMAT_RGBA128F which is only available since
Cairo 1.17.2 which is not in Debian bookworm (our current baseline for GIMP
3.0). It means that the old precision will still happen with older Cairo
version, as determined by #if code at compilation.
Now text layers are proper types, which means that the binding API will also be
nicer (e.g. `txt_layer.set_text('hello world')` in Python).
This commit also adds the param specs allowing to create plug-in procedures with
text layer parameters.
Finally it fixes the few calls in file-pdf-save (apparently the only plug-in
using specific text layer API right now) with explicit type conversion.
… the public API.
This was initially proposed by Niels De Graef in !101, and though I
still think this is much less practical for day-to-day development, it
is actually much nicer for the public part of the API. So let's use
these only in public libgimp* API only, not in core.
I actually already started to use these for some of the libgimpwidgets
classes and am now moving libgimp main classes to these macros.
* It doesn't expose the priv member (which is completely useless for
plug-in developers, only to be used for core development).
* It forces us to never have any variable members in the public API
(which we were doing fine so far in newest API, but it's nice to be
enforced with these macros).
* When using G_DECLARE_FINAL_TYPE in particular, it adds flexibility as
we can change the structure size and the members order as these are
not exposed. And if some day, we make the class derivable with some
signals to handle, only then will we expose the class with some
_gimp_reserved* padding (instead of from the start when none is
needed). Therefore we will allow for further extension far in the
future.
Moreover most of these libgimp classes were so far not using any private
values, so we were declaring a `priv` member with a bogus contents just
"in case we needed it in future" (as we couldn't change the struct
size). So even the easiness of having a priv member was very relative
for this public API so far (unlike in core code where we actually have
much more complex interactions and using priv data all the time).
s/gimp_image_base_type/gimp_image_get_base_type/
s/gimp_image_width/gimp_image_get_width/
s/gimp_image_height/gimp_image_get_height/
Sorry plug-in developers, more porting work! But really this seems like
the right thing to do in order not to get stuck with inconsistent naming
for many more years to come.
which call gimp_item_get_by_id() and additionally check if the
returned item has the right type, and return NULL if not.
This is both shorter and more readable than
layer = GIMP_LAYER (gimp_item_get_by_id (id));
and additionally makes sure we don't cast e.g. a non-layer with
GIMP_LAYER(), which will give criticals but shouldn't, because the
wrong IDs can come from anywhere and are an input problem and not a
programming error (criticals are for programming errors).
Even when the function names may have stayed the same in most cases, the
API has changed. The "Since:" tag must therefore be bumped.
Also adding docs for gimp_drawable_get_sub_thumbnail_data() which had
none.
This means that images' ownership is not given to caller in particular.
libgimp will now keep a reference of all GimpImage-s it creates and
return this same reference if called again. It also means that you can
now compare images by pointer comparison (as 2 GimpImage objects
representing the same image ID will be equal).
Obviously as a side effect, gimp_image_list() is changed to (transfer
container) as you must only free the container now, not the elements.
Also various other functions creating new images are now (transfer none)
too.
Long-time plug-ins will have to be taken in consideration in a further
step (we currently never free GimpImage for destroyed images in
particular).
I did the same trick with GIMP_DEPRECATED_REPLACE_NEW_API macro, apart
for some minor widget API to preview drawable, which I will fix right
away in our plug-ins.
Same as previous commit: by default the new API will be used. But if a
plug-in builds with GIMP_DEPRECATED_REPLACE_NEW_API macro, then the same
function names will call the old API with ids.
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.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
Change gimp_pixbuf_create_buffer() to copy the pixels if a linear
buffer cannot be created. Add functions that convert between
GimpTempBuf and GdkPixbuf. Fix users of gimp_pixbuf_create_buffer()
to make the least possible copies. Patch modified by Mitch.
Move the pixbuf layer and image thumbnail function from libgimpui to
libgimp and move gimp_layer_new_from_pixbuf() to gimplayer.[ch] where
it belongs. Change gimp-2.0.pc accordingly, adapt plug-in Makefiles
and update devel-docs.
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
2007-10-16 Sven Neumann <sven@gimp.org>
* libgimp/gimplayer.c (gimp_layer_copy): removed obsolete
comment
about adding alpha before adding a layer above the background
layer.
svn path=/trunk/; revision=23837
2006-11-03 Michael Natterer <mitch@gimp.org>
* libgimp/gimpbrushes.c
* libgimp/gimpgradients.c
* libgimp/gimpimage.c
* libgimp/gimplayer.c
* libgimp/gimppalette.c
* libgimp/gimppalettes.c
* libgimp/gimppatterns.c
* libgimp/gimpselection.c: also let all non-generated deprecated
functions see their declarations.
2005-07-10 Manish Singh <yosh@gimp.org>
* libgimp/gimplayer.c (gimp_layer_set_preserve_trans): actually
return a value.
* plug-ins/pygimp/pygimp-drawable.c: create new lock_alpha attribute,
and deprecate old preserve_trans attribute.
* plug-ins/pygimp/plug-ins/shadow_bevel.py: use new lock_alpha API.
Jehan