This behaviour, previously available in JUCE 7, was missing since the
JUCE 8 changes related to Unicode text drawing.
With this commit, words that are too long to fit in a line are again
broken up, with the caveat, that we can expect this approach to produce
quirks with bidirectional text. We don't expect that such a feature
could be satisfactorily provided for bidirectional text, so this is a
stopgap measure for legacy applications.
Previously, when attempting to create a font with a name different to
that of any font on the system, the returned typeface could be nullptr.
This could lead to crashes when attempting to use the typeface.
Now, if we fail to find a matching font using DirectWrite, we fall back
to the older LOGFONT and DC approach, which will generally locate a
usable typeface, though not necessarily an exact match.
The new behaviour more closely matches the behaviour of JUCE 7, which
would attempt to construct a DirectWrite typeface, but would fall back
to creating an HFONT on failure.
The main reason for removing this call is that this function is
deprecated, and is no longer needed now that we keep our own cache of
CTFonts that have been loaded from memory, and now that we no longer use
CoreText text layouts.
This also appears to fix an issue with garbled text which was
occasionally seen when different versions of the same font were
available, e.g. because differing versions of the font were
simultaneously embedded as BinaryData and installed on the system.
- Reject surrogate code points for all unicode encodings
- Prevent out of bounds access in some cases
- Move ASCII and UTF character validation functions to CharacterFunctions
- Add more unit tests
Prior to this calling AudioFormatReader::read() with an AudioBuffer
with one channel would crash, even if the useReaderLeftChan and
useReaderRightChan parameters prescribed a valid operation.
Unlike other implementations, WindowsMediaAudioFormat would use the last
source channel multiple times if numDestChannels > numSourceChannels, as
opposed to zeroing out the extra destination channels.
The documentation specifies that the "Duration" property is given in
100 nanosecond units, which is a good thing, otherwise the calculation
wouldn't be correct.
toWideCharPointer() returns a pointer to a buffer managed by the String.
The wchar_t pointers are not read until the invocation of
TaskDialogIndirect, so the String instances must remain alive until this
point.
Fixes bugs in AndroidInputStreamWrapper introduced in
0d2e34f34c
- Now that AndroidInputStreamWrapper is moveable, its destructor must be
able to handle the situation where stream is null
- The move assignment operators of AndroidInputStreamWrapper and
AndroidContentUriInputStream could previously end up calling
themselves recursively
Previously, maximising a frameless window on a secondary display could
result in the window's coordinates being computed incorrectly, leading
to graphical glitches.
Reverts b12088a1f6
After some investigation, it appears that ClearType rendering is
unsuitable when
- the render target has translucent pixels underneath rendered text, or
- the render ouput is rotated, scaled, subpixel-translated, or otherwise
transformed before display.
This necessitates avoiding ClearType when rendering into transparent
bitmaps.
Unfortunately, a commmon use-case for transparent bitmaps is buffered
component images. Even if ClearType were enabled for opaque targets,
ClearType text could then end up displaying next to non-ClearType text
rendered to an intermediate texture, leading to an inconsistent
appearance.
There's also not a straightforward way of exposing a ClearType rendering
option in all of the places that it would be required, and a change of
this size is difficult to justify given that subpixel text rendering
controls would only have an effect on Windows.
This fixes an issue introduced in
340f531c71 where embedded OpenGL windows
would incorrectly have the WS_EX_LAYERED style bit set, which in turn
prevented them from displaying correctly.
Before the window-transparency refactoring, OpenGL windows would not
have the layered bit set because only peers with windowIsSemiTransparent
were created with the layered bit, and the layered bit was only updated
if the peer alpha was changed.
The new behaviour is to always set WS_EX_LAYERED if the peer's component
is non-opaque with no titlebar, or if the component has an alpha < 1.0f.
The OpenGLContext's placeholder component has no titlebar, so it must be
opaque in order to avoid setting the layered style bit.
