This change makes it slightly easier to audit invariants of
ModalComponentManager, as we can now be certain that only member
functions of ModalComponentManager can access its data members.
This commit reverts commit: 9e9da250 as it introduced a regression.
On windows when exit is called on a dll it forcibly kills any threads
still running before destroying any static objects. This means if a
Timer object is static the timer thread will be killed. Later when the
static object is destroyed it will wait for the thread to exit, which
because the OS forcibly killed it will never come true.
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).
This commit implements fix for an issue where mixed punctuation can be rendered in the wrong order.
A regression test has been added to catch this in the future.
This commit encapsulates the following:
* Removal of public Unicode classes.
* Move to new 'blob' generated data format.
* Fix issue where numerical characters would be assigned incorrect bidirectional levels, resulting in them rendering in the wrong order.
* Adds a unit test for the number ordering issue.
* Refactor of Bidirectional and Line breaking algorithms.
Previously, drawing an opaque, scaled component with CoreGraphics could
lead to visible artefacts around the edge of the component.
When drawing the parent of an opaque component, the area covered by the
opaque component is excluded from the clip region. If the clip region is
non-integral when transformed into device space, anti-aliasing will be
applied on the edges of the clip region. Similarly, when drawing the
opaque component itself, anti-aliasing will be applied at the edges of
the component. When the two drawings are superimposed, the foreground
anti-aliased pixels will be blended with the background anti-aliased
pixels, leading to a noticeable border around the component. Ideally,
only the foreground anti-aliasing should be applied, and the background
should not be anti-aliased around its edges.
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.
In cases where there was a static or global instance of a class that
inherited from Timer, due to the order of events when a dll is unloaded
on windows, there was a risk of an infinite hang. Deleting the timer
thread before the dll is unloaded avoids this occurring.
