Previously, the software renderer could render transformed gradients
incorrectly. This could be seen in the backgrounds of the tabs in the
ComponentTransformsDemo when the view was rotated through around 45
degrees.
The new behaviour appears more consistent with the other renderers.
The glyph spacing for this font does not scale linearly with the font
size; at smaller font sizes, the spacing is relatively larger.
Typeface::getStringWidth, Typeface::getGlyphPositions, and the
equivalent Font member functions now take the font size and horizontal
scale into account when computing advances on Apple platforms.
This is sufficient for initial support of the system emoji fonts on each
platform:
- Noto Color Emoji on Linux and Android, png-based
- Apple Color Emoji on macOS and iOS, png-based
- Segoe UI Emoji on Windows 10 and 11, COLRv0-based
- This font also provides COLRv1 support, at least on Windows 11,
but JUCE will ignore that and use the COLRv0 data instead
Previously, the UnitTestRunner example in the DemoRunner would fail on
any tests that included ScopedJuceInitialiser_GUI, as DeletedAtShutdown
objects would be destroyed too early.
Previously, the UnitTestRunner example in the DemoRunner would fail on
any tests that included ScopedJuceInitialiser_GUI, as DeletedAtShutdown
objects would be destroyed too early.
This updates the behaviour of Typeface::getStringWidth,
Typeface::getGlyphPositions, and Typeface::getEdgeTableForGlyph to match
the documented behaviour of these functions. Previously, these functions
returned results normalised to a size of 1 point. The new (documented)
behaviour is to normalise to a JUCE height of 1.0 - that is, scaled so
that the sum of the ascent and descent is equal to 1.0.
