The glyph in this test has extents that will be made smaller
by hinting, which poses some challenge for our renderers.
The scaled glyph rendering is too big for the 'small texture'
text setup, so we allow the test to fail there.
The goal is to fix all the context that influences the rendering
of text nodes in the node file. This will help with better font
testing.
The newly accepted properties are
hint-style: none/slight/full
antialias: none/gray
We are omitting font options and values that aren't supported
in GSK or have no influence on the rendering.
Note that these settings will get incorporated in the PangoFont
that gets set on the resulting text node.
Parser tests included.
We need precise bounds. And while hinting might shift the rendering
around from these bounds by a fraction of a pixel, we account for
this in the places where it matters: when determining diff regions,
when sizing offscreens, and when determining the size of atlas
regions for glyphs.
Add a function to change the cairo font options of a font to
to the given values while keeping everything else the same.
We use pango api for this if available.
Note that this is not a fully general api, but tailored to the
needs of GSK. We don't allow setting hint-metrics (because it
only influences layout, not rendering) or subpixel-mode (since
we don't have component alpha available).
This changes the approach we take to rendering glyphs in the
presence of a scale transform: Instead of scaling the extents
and rendering to an image surface with device scale, simply
create a scaled font and use it for extents and rendering.
This avoids clipping problems with scaling of extents in
the presence of hinting.
The pango code that is drawing hex boxes, invisible glyphs, etc,
is depending on the width being set in the PangoGlyphInfo. Once
we set that, everything falls into place.
Testcase included.
It is a bit annoying that one has to specify the glyph width
when specifying glyphs numerically for a text node, since this
information really is part of the font.
Make the parser more flexible, and allow to specify just the glyph
ids, without an explicit width. In this case, the width will be
determined from the font.
With this, glyphs can now be specified in any of the follwing
ways:
glyphs: "ABC"; (ASCII)
glyphs: 23, 45, 1001; (Glyph IDs)
glyphs: 23 10, 100 11.1; (Glyph IDs and advance widths)
glyphs: 23 10 1 2 color; (with offsets and flags)
Tests have been updated to cover these variants.
While it’s documented as being safe, it triggers warnings from ubsan.
While we work out the best way to deal with that inside the
implementation of `G_ADD_PRIVATE` in GLib, let’s pragmatically just
short-circuit the code which triggers the warning here. This is helpful
because `gdk_display_get_debug_flags()` is called from a number of
locations within GTK, so is likely to be hit if anyone is running a UI
app under ubsan.
See https://gitlab.gnome.org/GNOME/glib/-/issues/3267#note_2033550
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/3267
Gtk.Editable.get_delegate is allowed to return another
delegating Gtk.Editable. However, the AT-SPI text
implementationn for Gtk.Editables does not handle
delegate chaining.
In the wild, you will find a Gtk.Text as the delegate of
a Gtk.SpinButton, that is in turn the delegate of an
Adw.SpinRow in libadwaita.
Note: This does not handle the more dangerous possibility
of a delegate loop when built with G_DISABLE_ASSERT,
otherwise stops after the arbitrarily chosen number of
six steps of delegation.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
When testing VTE on GTK 3 using ATK, the variant parameter is <0> instead
of <''> on the wire. Make that match to increase the chances that tooling
will hit the same expectations.
In an autobuilder environment, there will typically be no hardware GPU
available, so Mesa will fall back from hardware to Zink to software
rendering. Unfortunately, Zink logs to stderr during loading if no
hardware GPUs are available. This particular test asserts that stderr
has desired contents, which means Zink's extra output causes the test
to fail. We can bypass this by disabling use of Zink.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6478
Signed-off-by: Simon McVittie <smcv@debian.org>
We were installing the timeout in root, but removing it in unmap,
which could lead to trouble if we ever dispose a GtkVideo widget
without mapping it.
Fixes: #6264
