Newlines get removed in the sanitised string, so we need to take extra
steps to keep track of their positions.
Co-authored-by: Aga Janowicz <aga@roli.com>
On Ubuntu 25.10, which includes Noto Color Emoji, I was seeing that the
FontsDemo would assert when attempting to render non-emoji text using
this font. It appears that FontConfig will tend to return Noto Color
Emoji when this family name is passed, even though the font may not
cover the required character set.
The new strategy is to use FontConfig as before, but then to check the
resolved font for coverage of the string. If the resolved font still
can't render the string, we relax the font matching constraints by
removing the family name from the pattern, then try matching again.
Harfbuzz doesn't support these font formats, so attempting to shape text
using these kinds of fonts will fail.
I noticed this on Ubuntu 25.10 for Arm, which seems to include pfb and
otf versions of some fonts. The FontsDemo would assert in cases where
the pfb font was selected instead of the otf font.
The default error handler could cause crashes, so we now set up a custom
error handler both when reading and writing PNGs.
The HeapBlock and BitmapData automatic variables have moved, so that
their destructors will still run as expected in the failure case. Note
that it's UB to call longjmp to unwind the stack to the previous setjmp,
if said unwinding would normally cause non-trivial destructors to run.
This partly reverts commit ad28684b10.
Prior to that change, getBrush() would always end up calling
SetTransform on gradient/image brushes. This is important because, when
drawing text, we combine the current brush transform with the text
transform. If we don't reset the brush transform each time, these
transforms end up accumulating across frames.
The code contains a performance optimisation for cases where the world
transform is translation only. In this case instead of applying the
brush transformation first and then the world translation, the order is
reversed. The translation is applied first and then the brush
transformation.
Flipping the transformations however is only correct in the special case
when both transformations are translation only.
This change is practically a no-op, because if the affected branch is
taken, then the world transform was not applied, so transform is a
unity matrix. But if transform was non-unity, then the wrong ordering
would cause an observable error.
Logically the brush transformation is nested inside the world
transformation so the right order is applying the brush transform first
followed by the world transform.
Reverts ca3abbb96d.
Prior to this fix gradually changing the Component scale would lead to
the jittery movement of drawn bitmaps, as their position would be
snapped to an arbitrary integral representation.
This is intended to address an assertion that sometimes fired during
shaping text on Android, for example when using the font "Noto Sans
Symbols" and shaping ASCII text including a line break in a multiline
text editor.
The cause of the issue seems to be that the shaper would search for
substitute fonts using the original string content, but would then
replace some characters in the string during shaping. Shaping could then
fail if the font did not contain glyphs for the replaced characters.
We now create a UTF32 string with replaced characters at the beginning
of the shaping process, and use that new string for all queries other
than unicode analysis.
Android 15+ removed the 'legacy' png-based emoji font. Modern Android
versions may include only a COLR-v1-based font, which JUCE cannot
render itself.
As a workaround, on Android, we use a Canvas object to render each emoji
glyph into a bitmap, and then render that bitmap in the same way as a
legacy png-based glyph. This won't look as crisp as rendering COLRv1
glyphs directly, especially at larger sizes, but this is a sufficient
stop-gap for the time being.
The OpenGL renderer listens for imageDataChanged() to invalidated cached
textures.
Before this change, the SimpleFFTDemo would display a static (outdated)
image on Windows when using the OpenGLRenderer.
When syncing from CPU->GPU storage, we currently copy the entire image
contents. The contents of the CPU backup completely replace the old GPU
image. Therefore, if any pixels need to retain their existing values, we
need to read those pixels before overwriting them. This in turn implies
that, when a BitmapData refers to a subsection of the image, we should
always flush GPU->CPU storage first, so that the subsequent CPU->GPU
sync doesn't clobber pixels outside of the BitmapData region with
outdated values.
It's clear that copying the entire image back and forth could be
suboptimal when writing to image subsections, but to optimise this
process we'd have to keep track of dirty image regions or similar, which
may in turn pessimise more common cases.
