We introduced a bug in GIMP 3.2.2 where some text layers with NULL
markup (i.e. defined as bare text) would store an empty markup inside
the XCF. As a consequence, this empty markup string would override the
text.
This bug got fixed with my previous commit. Unfortunately the XCF files
would still be available in the wild and they would still lose their
content upon editing the text layer, if we were to only fix the XCF
saving. This additional commit will add some special-casing to handle
this edge case, which would simply delete the empty markup upon
encountering it. This makes our XCF loading robust to faulty XCF files.
Resolves#11409
After Jehan's update to
gimp_drawable_filter_refresh_crop () in
0157a958, it no longer calls the cropping
functions which this commit was intended
to work around.
Additionally, thanks to other changes in
the filter code since then, reverting this
commit resolves an issue where some
Render filters would not update as you
typed more characters.
This patch prevents the following CRITICAL:
gimp_rasterizable_restore: assertion
'gimp_rasterizable_is_rasterized (rasterizable)' failed
It is possible to call gimp_text_layer_set () on a text layer
that is not rasterized. Since gimp_rasterizable_restore ()
is always run even when we don't need to restore the layer
to non-rasterized format, it threw a CRITICAL. This patch
adds a check for gimp_rasterizable_is_rasterized (), similar
to earlier in this same function, to prevent the call on
non-rasterized layers.
Though the crash in #14139 won't hopefully happen again, thanks to my
previous commit, these additional assert may help in debugging if ever
it does again. Because truth is that even with partly-loaded fonts, this
was weird. If we had a GimpFont already, why did we fail to get a pango
font, or to query its file path through fontconfig?
I can't reproduce this issue, because when I set a fake font file as a
broken symlink, or a file without read access, it is simply not returned
as part of my font list to start with.
But from the issue discussion and traces, this should be the right fix.
Checking for valid font files thourgh harfbuzz or freetype (as it's done currently)
is slow, to speed up font loading a but, a less robust but faster check is done, which
is just reading and checking the first 4 bytes of every font file.
The previous commit was not taking into account usages of
gimp_cairo_surface_create_buffer(), other than the text layer rendering
usage, as it was focused on fixing #14970.
In particular, in other pieces of code, we were using a temporary
GeglBuffer as a way to edit the original Cairo surface but the syncing
back was not happening anymore. So previous commit was breaking all
thumbnails of layers or images, as well as PDF export for all raster
layers.
After some thought, I decided to implement a new function
gimp_cairo_surface_get_buffer() which would do what
gimp_cairo_surface_create_buffer() was doing, but adding a boolean flag
to declare whether or not we were expecting to sync back into the Cairo
surface's data. After all, when we don't need to sync back, better avoid
the useless work of copying possibly huge data.
I also added back the possibility of returning a linear-memory backed
buffer, after some discussion with pippin. Because for very small
surfaces, and if we are indeed looking to sync back into the source
Cairo surface, the advantages of using a linear buffer may still be
worth it, even though it's not true for the general case (where tiled
buffers will be much more efficient). I used 4096 (64^2 because our
current tile dimensions are 64 right now in GIMP), though this number is
kinda random and doesn't matter too much (it doesn't have to be the
square of the tile's width or height). I don't put any info about this
in the new function's documentation because developers should not have
any expectations on the type of buffer they get (only whether or not it
will sync back to the source).
As a consequence of all this, gimp_cairo_surface_create_buffer() has
been deprecated as of GIMP 3.2, though it will still work the same. The
new function will be recommended as a replacement.
Resolves#4275
Text layers should have transparency when they are
not rasterized. It is possible to remove the alpha channel
when a text layer is rasterized, which causes a CRITICAL
when gimp_text_layer_render () runs to re-render the
vector-based text layer when the rasterization is reverted.
This patch adds a check in the set_rasterized () function to
verify the text layer still has an alpha channel when it's being
converted back to a vector-based layer. If the alpha channel
was removed, it is restored before re-rendering.
This commit prevents the on-canvas text editor from being dragged outside
the image bounds by checking the overlay's position and adjusting the
coordinates to keep it within the canvas. Additionally, it checks whether
the overlay is entirely outside the canvas and, if so, pushes it back inside.
Once the on-canvas text editor has been moved, its position should be
preserved across editing sessions. This commit stores the editor's
position per text layer and restores it when the layer is activated again.
Rasterizable objects are all created from some side data and can be
renamed automatically based on this data (from the link file for link
layers; from the path for vector layers; from the text for text layers).
So let's share code.
Share the whole rasterize logic of the text, link and vector layer into
an interface. I didn't write it as an abstract parent class, because we
might have more rasterizable items in the future, which may not be
layers (e.g. there were discussions of vector masks).
Pango shows all fonts in the family as "Skia Bold", unless the psname is not matched
so we make an exception for skia and don't match on psname in the custom fontconfig xml.
see issue 14659.
These 2 new actions are meant to be usable on all 3 types of non-raster
(and non-group) layers, i.e. link, text and vector layers, to
respectively rasterize and un-rasterize them.
This will also work with multiple selected layers, and is not specific
to one type of layers.
I also change how gimp_text_layer_discard() used to work, by marking the
text layer as modified instead of actually discarding all text
information. The main consequence of this was that a layer rasterized
this way was forever lost. Now it can actually be revived as a text
layer, not only through the new layers-retrieve action, but also by
trying to edit it with the Text tool, which will trigger the same dialog
as when a text layer had been rasterized by editing it with a paint
tool.
Whereas the label of "layers-rasterize" seem to be quite straightforward
(simply "Rasterize" per discussions in gimp-ux#252), I am really unsure
of the label for "layers-retrieve". Further UX discussions should help
on this front.
This patch moves the enums for GimpTextOutline
and GimpTextOutlineDirection so that they are
accessible to plug-ins/scripts. This will allow
for us to add PDB functions to get/set text outline
properties.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
hb_ft_font_lock_face() (and unlock) exists since harfbuzz 2.6.5 and our
current requirement for this dependency is 2.8.2.
Fixes this compilation warning:
> app/text/gimpfont.c:1196:3: warning: ‘hb_ft_font_get_face’ is deprecated: Use 'hb_ft_font_get_ft_face' instead [-Wdeprecated-declarations]
> 1196 | face = hb_ft_font_get_face (hb_font);
While there is a style "background color", the idea of a "widget
background color" is completely bogus, the widget background can be a
gradient or whatever.
- Get rid of "background" in GimpViewable's preview API, only leave the
"foreground color" there for things like brushes or fonts.
- In GimpViewRenderer, add the background types to be used to class and
instance, so each renderer type can choose what it needs.
- Render all previews to alpha surfaces, and do the background
for all renderers generically in gimp_view_renderer_real_draw(),
then render the preview surface on top of it.
This same code will also be usable for GimpVectorLayer and
GimpLinkLayer. It was made generic so that we don't copy the same code
over and over.
Now it also supports the case when the layer to copy was already added
to the image, which is going to be necessary for GimpVectorLayer.
This patch provides a temporary fix for issue
14442. Currently, gimp_drawable_size_changed ()
is called whenever a drawable's size changes (like by
scaling, rotating, resizing, etc). When called, it resizes
filters to the layer's new width and height.
Unfortunately, it is currently also called when typing new
text, as that changes the layer size too. This causes filters
like Drop Shadow to be cut-off because they originally
extended outside the bounds of the layer.
This patch checks if the layer has been rasterized - if it hasn't,
then size_changed () is not called. As stated, this is a temporary
fix for GIMP 3.1.4, and will likely be replaced with a more
permanent fix for GIMP 3.2
This also depends on the same settings to render brushes with theme
colors, because this is data, not user interface. Therefore following
theme colors is not necessarily what creators would expect.
Previous code was using the correct background color from the theme, but
the foreground color was always either white or black (depending on GUI
config color scheme). Instead, just use the foreground color from theme.
Since core/ doesn't have access to GTK, hence the theme, we had to
update GimpViewable's get_preview() and get_pixbuf() abstract methods to
have a color argument for recoloring previews (when relevant, which for
most types of viewables is not).
This fixes 2 such warnings:
> app/text/gimpfontfactory.c: In function ‘gimp_font_factory_load_names’:
> /usr/include/glib-2.0/glib/gstring.h:74:5: warning: ignoring return value of ‘g_string_free_and_steal’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
The (void) ! trick was also possible but this is so ugly so I went for
actual usage of the return value as we should.
Also clean up some trailing whitespaces.
This is to make sure than regardless of how many fonts there are, font loading
won't delay startup.
FontConfig if compiled against libxml2 might fail to parse huge xml configs.
So instead of passing it a huge xml, pass the xml every MAX_NUM_FONTS_PER_CONFIG (currently 1000) fonts.
Also made GimpFontFactory custom config strings private because there is no reason for them to be public.
Profiling showed that a significant amount of time was spent created the hb_blob, and calling FcParseAndLoadFromMemory.
To allow only fonts that pango/harfbuzz recognize, an hb_blob was created from
every font to test if harfbuzz recognizes it, which is obviously a lot of overhead.
FontConfig allows to check if the Font is SNFT and wether it's a WOFF[2] font.
For some reason pango returns a FontDescription with name "Normal" when called
with empty string. This caused crashes in pango markup serialization. This
patch checks if the font before serialization is a valid font object, otherwise fallback to the fallback font.
Also font's reference count wasn't increased in one case when opening xcf file with a text layer.
Whenever the font in the Context (e.g. through selecting another font
from the fonts list) changes, a signal is emitted to propagate the
change to the active text layer, but if the font is set to NULL in
Context, we don't want that to propagate (because this would change the
current text's font to some fallback font).
In other similar codepaths (e.g. brushes) this is not a problem because
selecting a brush that doesn't exist will prevent painting until an
existing brush is selected.
Fullname might not be suitable for display (e.g. if contains family and
style with no whitespace between them), so when available,
use "family style" for display instead.
Sometimes there is more than one name in the font file, the heuristic to
use the second name instead of the first assumed that the first name is
in english and the second is in the font's primary language, but that's
not the case.
e.g. on Windows "Times New Roman Italic" second name is "Times New Roman Cursiva".
Previously buttons in the style editor meant just "faux" bold/italic,
which is different from the behaviour of 2.10, where real bold/italic
was used if available.
Unfortunately this might break in some cases if fontconfig doesn't return the correct face,
but at least it's consistent with 2.10.
When opening an old XCF, we try to match the fonts specified in the text
layers (and the text tool) with the closest font (if the exact font isn't available).
This patch improves the matching heuristic a bit.
