Prior to this commit the returned values were always normalised to the
value returned by getHeightInPoints().
I.e. getAscentInPoints() + getDescentInPoints() would always equal
getHeightInPoints(), even if ascent or descent overrides were in place.
With this change in place getAscentInPoints() + getDescentInPoints()
will always equal
getHeightInPoints() * (getAscentOverride() + getDescentOverride())
JUCE classes don't use this value for layout logic, so this commit
causes no visible changes in how JUCE draws text.
This restores the JUCE 7 behaviour when the JUCE 8 font fallback
mechanism fails to resolve a non-null Typeface::Ptr. This behaviour is
significant when the base font specified is not available on the system.
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.
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.
Previously, it wasn't safe to access Font instances from multiple
threads because there was a chance that they might reference the same
shared internal state. In this case, calling getTypeface() or getAscent from
two threads simultaneously would cause a race on the typeface and ascent
data members, even though the Font instances appeared to be disjoint.
With this change in place, it is now safe to use Font instances from
multiple threads simultaneously.
It is still an error to modify the same Font instance from multiple
threads without synchronization!
// Fine:
Font a;
Font b = a;
auto futureA = std::async (std::launch::async, [&a] { /* do something with a */ });
auto futureB = std::async (std::launch::async, [&b] { /* do something with b */ });
// Bad idea:
Font f;
auto futureA = std::async (std::launch::async, [&f] { /* do something with f */ });
auto futureB = std::async (std::launch::async, [&f] { /* do something with f */ });
