Occasionally, on Linux, Address Sanitizer can complain about a memory
region overlap in the arguments to memcpy, originating in
EdgeTable::intersectWithEdgeTableLine. I haven't been able to reproduce
this personally.
The final memcpy call in this function requires there to be
"srcNum1 * 2" valid entries after the current "src1" ptr, and none of
those entries may overlap with the area starting at "temp".
On inspection, I think that the memory region being read is too large.
At the point of the call, src1 will point to a LineItem::level, not
LineItem::x, so there will actually be (srcNum1 * 2 - 1) valid items
following it.
All this pointer arithmetic is very difficult to understand. In an
effort to make this function slightly more understandable, I've switched
to using Spans to delineate lines of the table, which makes it easier to
keep track of the size of each line.
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
