Since 4122427748 assertions are guarding
the FontOptions::withName, withStyle and withTypeface member functions.
Since then the only way to replace an existing typeface without hitting
these assertions is to clear all three fields before calling
withTypeface, which then sets all three values. It is always legal to
just clear an existing Typeface and rely on the name and style fields.
Previously, code such as the following would return a smaller string
width for larger tracking values:
juce::Font f { juce::FontOptions{}.withPointHeight (16.0f) };
const auto g = f.withExtraKerningFactor (1.0f);
const auto a = f.getStringWidth ("foobar");
const auto b = g.getStringWidth ("foobar");
With this change applied, the width 'b' is greater than the width 'a',
as expected.
This fixes an issue with the text wrapping logic for text chunks ending
in a whitespace.
When trying to fit a text chunk, the logic works with two values: width
with trailing whitespace, and width without trailing whitespace.
When the trailingWhitespacesShouldFit option is false, the logic
checks if "withoutTrailingWhitespace" can still fit inside the remaining
width.
Prior to this fix, it then decremented the remaining width with
"withoutTrailingWhitespace", but it should have used
"withTrailingWhitespace" for the decrement operation, always, regardless
of the value of the withTrailingWhitespacesShouldFit option.
This mistake only caused an observable issue when multiple fonts were
used for the shaping operation, and a different font would be used
immediately after a whitespace falling at the end of a line.
Prior to this change, the spacing between line N and line N + 1 would be
lineHeight (N).
This resulted in incorrect spacing when using multiple fonts in a text.
This commit uses the correct spacing, which is
maxDescent (N) + maxAscent (N + 1). This is also the same rule that was
used by TextLayout prior to JUCE 8, and the rule that CoreText's
AttributedString features are using as a general rule.
Note: lineHeight (N) = maxAscent (N) + maxDescent (N).
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
