| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
We already used aarch64 everywhere (am conditionals, macros, filepaths)
except for this one config-internal cpufamily variable.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GDI uses case-insensitive matching. We now request the font's full name,
but if it case-insensitively matches the family name, GDI decides that
it's a family-name match and returns the family name from GetTextFace
instead of the full name we originally requested, which then fails our
case-sensitive equality check.
An actual example of an affected font is Microsoft YaHei UI (Regular).
Its family name is spelt "YaHei" in the name table records marked English
and Chinese, but its full name is actually spelt "YaHei" in the English
record but "Yahei" in the Chinese one. Thus, on Chinese locales only,
requesting "Microsoft YaHei UI" gets "Microsoft Yahei UI" back, fails the
check and discards the font, causing the bold version to be used instead,
as reported in https://github.com/mpv-player/mpv/issues/13845.
|
| |
|
|
| |
Fixes: https://github.com/libass/libass/issues/744
|
| |
|
|
|
|
|
|
|
|
| |
mpv (temporarily) enabling colourspace-matching for HDR videos,
showed by now a noteable amount of subs exist expecting to
remain SDR when placed on HDR video.
After further discussion in #297 we thus decided to revise
the default for subs on HDR to forego exact colour-matches, see:
https://github.com/libass/libass/issues/297#issuecomment-1991497184
|
| |
|
|
|
|
|
| |
Node16-based actions are deprecated;
no adjustments needed for bumping to v4.
The msys2 actions is already following the latest major release.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our old code deviated from VSFilter in many ways, though
the tokenisation differences only affected nonsensical
or technically invalid drawing command sequences.
While it is possible to retrofit the existing tokenisation loop
to emulate VSFilter’s logic, the result is not as readable as just
directly using greedy point aggregation and a search for the next
valid command similar to VSFilter.
Unfortunately, this has the downside of making the individual
compatibility changes/issues less visible in the diff. Instead
they are spelled out below:
- VSFilter ignores invalid commands together with their coordinates.
Prior to this, libass ignored invalid commands itself but appended
their coordinates to the preceding valid command. This was even
intentionally exploited to (not-)implement p, resulting in different
behaviour if p was following something other than s.
- VSFilter will accept n as the first node
if an _invalid_ m command appeared before
- VSFilter drops points from b which are not part of a triplet.
- VSFilter ignores s commands with less than three points.
- VSFilter ignores p commands if there aren’t at least 3 nodes yet.
(The last one strictly speaking only holds for xy-VSFilter and
MPC-HC ISR — but guliverkli2 VSFilter just crashes on such input)
Furthermore, until now libass recognised q for conic bezier in the
tokeniser. This does not exist in VSFilters and was also never
implemented in libass’ token-to-outline parser.
Other than the lack of distinction between spline start and extension
nodes (which also requires support in the parser) our tokenisation
result should now exactly match modern VSFilters.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Regression in commit b6650bd51b4c471c32dd3977ca9416c0b35f6358:
fullnames and families are no longer allocated, so freeing them
is pointless, wherease extended_family is allocated in their stead
and yet is never freed.
Reported-by: @moi15moi
|
| |
|
|
|
| |
Fixes: https://github.com/libass/libass/issues/634
Fixes: https://github.com/mpv-player/mpv/issues/13322
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
I don't know if it is actually _possible_ in practice for DirectWrite
to return zero WIN32_FAMILY_NAMES for a font, but we do currently guard
against this in ass_directwrite_info_template.h. Use the same logic here.
This name seems somewhat likely to fail to be found by match_fonts
depending on the exact font and version of the Windows environment,
but this is still better than not even trying.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DirectWrite sometimes returns names that differ from GDI's. Instead of
trusting it, use our own GDI-compatible code, even if it costs us some
extra resources.
Conceptually, this reverts commit 4fb7394f7b9b4f4e4f3e2825c5ec5344a69619f2
"directwrite: read metadata from IDWriteFontFace3 if possible":
the refactoring is kept, and so is the read of the PostScript name
purely for logging purposes in case of error, but we turn back to
(re)reading all metadata on our own. In addition to reverting the logic
of the IDWriteFontFace3 path, this also makes the CreateFontFromLOGFONT
path similarly go via FreeType.
This fixes https://github.com/libass/libass/issues/675
and facilitates future improvements to long font name matching
(https://github.com/libass/libass/issues/459).
To avoid exotic failures, especially font fallback failures,
save DirectWrite's WIN32_FAMILY_NAME as our extended_family.
get_fallback returns the WIN32_FAMILY_NAME, and it *should* match what
we read for the same font via FreeType, but it is not unfathomable that
in some exotic cases it might not match or we might not read any family
names at all. fontselect consults the extended_family for fallback fonts
and for primary fonts that otherwise have no family names.
We might actually want to use WWS_FAMILY_NAME (or presumably equivalently,
DirectWrite's first-class font family names) as the extended_family to
allow better fallback to multi-weight families given tags like \b900,
but there are at least two reasons why WIN32_FAMILY_NAME seems better
at the moment:
* Across all Windows versions and variants, match_fonts is only
guaranteed (if even that) to find a font by its WIN32_FAMILY_NAME.
For the fallback font to work, we obviously need match_fonts
to be able to find it.
We could alleviate this by querying DirectWrite for fonts by its
first-class family name in addition to the primary GDI-based path.
* While WWS_FAMILY_NAME joins, for example, Arial and Arial Bold,
which is desirable, it also joins Arial and Arial Narrow, but we
do not distinguish between fonts that differ only in width/stretch.
Barring additional width-based ordering logic somewhere, this could
lead us to choose an inconsistent combination of fallback font faces,
e. g. regular Arial for \i0 with Arial Narrow Italic for \i1.
|
| |
|
|
| |
Fixes https://github.com/libass/libass/issues/719
|
| |
|
|
| |
This is clearer and improves type correctness.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This matches VSFilter in its traditional ABIs.
It also avoids potential truncation of valid values in ABIs with
smaller ints and signed overflows on ABIs with 64bit ints, like ILP64.
Both are rare in practice.
Still, even as a cosmetic change this makes the supported value range
clearer and matches similar transitions in other parts of the code.
|
| | |
|
| |
|
|
| |
Fixes https://github.com/libass/libass/issues/714.
|
| |
|
|
|
|
| |
All lower case has been the preferred spelling variant
for many years now. This is the only place where current
versions of libass are still referred to as “LibASS”.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears plausible for the problem from
358770835248e26241e4796f38f02073a3bae252 to
affect more places in the rendering code.
However, for resolutions large enough to exhibit this
problem, there will likely be playback problems anyway.
Either API users will be unable to allocate a sufficiently large
buffer to blend into (> SIZE_MAX), or there will be issues during
playback with only parts of the subtitles actually being rendered
as larger events cannot create an ASS_Image (> INT_MAX).
Indeed a quick check reveals at least some truncations on floating point
to int conversion, although in this instance no OOB acceses occured.
libass/ass_render.c:3040:35: runtime error: 3.27509e+09 is outside the range of representable values of type 'int'
Given this, the new limits seem unlikely to affect any valid use cases.
Thus limit the permissable frame size appropiately and
for consistency apply the same limit to storage size.
As a bonus and to avoid division by zero, both extents
will now always be set to zero if either one is invalid.
With this the check specific to BorderStyle=4 from
358770835248e26241e4796f38f02073a3bae252
is no longer needed, since its w and h are already
effectively limited to at most frame size.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The buffer was allocated and memset using the unchecked result of
multiplying the width and height of the image. This multiplication can
overflow in two ways, both of which ultimately lead to allocating a too
small buffer and later OOB reads when the API user processes the image.
Nothing in libass processes the image buffer after this initial alloc
and memset.
Width and height are ints and capped to the extent of the render frame.
ass_aligned_alloc and memeset use size_t for the the size parameters.
For one, since both operands are sigend integers an overflow in the
multiplication is undefined behaviour. In practice on common systems
today, it will wrap around and then through conversion to size_t
effectively limited to UINT_MAX.
However while uncommon, SIZE_MAX may also be smaller than either
UINT_MAX or INT_MAX. As a result the multiplication itself might not
overflow, but the conversion to size_t will truncate the result.
(ISO C99 only requires SIZE_MAX to be >= 65535 with
no restrictions relative to other types.)
To avoid both error sources omit the BorderStyle=4 background box
if the image’s pixel count exceeds the limits of int or size_t.
The first problem was discovered by CodeQL.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the logic in HarfBuzz's hb-coretext. See:
1. https://github.com/harfbuzz/harfbuzz/pull/952
2. https://github.com/harfbuzz/harfbuzz/pull/1180
Core Text was introduced in 10.5, so this is as far back as we can go.
Tested on ppc32 10.5.8 in:
https://github.com/libass/libass/issues/595#issuecomment-1324548120
Manrope Regular failed to be selected by full name,
but other fonts (including other faces of Manrope) worked fine,
so this should be good enough to avoid requiring Fontconfig.
I have tested that the code in the 10.5-compatible branch still works
on 10.13.6 (the newest macOS instance I have access to), but the API
involved is officially "deprecated" and produces deprecation warnings
during compilation unless the build's deployment target is set to a
version below 10.8. In addition, it's not unimaginable that it might
work worse in some specific situations now or in the future: for example,
it uses FSRef, which, according to the docs, is "designed to work
with 32-bit inode numbers", which "may result in performance issues"
on newer systems. As far as I'm aware, Apple doesn't tend to remove
APIs/ABIs completely except when combined with architecture changes,
but it seems the overall safest course of action is:
* to prefer the newer API if it is available at runtime,
* and to avoid referencing the older API at all
if it's known at compile-time to be unnecessary.
To nearly maximize build-environment compatibility,
use Availability.h and CHECK_AVAILABLE:
* Recent versions of Apple's compiler support __builtin_available for
OS version detection, and so does modern non-Apple Clang. This is what
Apple recommends nowadays. However, none of Apple's official compilers
on macOS up to 10.10 have had this builtin, and no third-party
compilers besides Clang have ever had it. Non-Clang compilers may
have issues with Apple's more recent SDK headers anyway, but they're
perfectly viable with older SDK releases and all the more likely
to be used when the build is being performed on an older machine,
e. g. when targeting that same machine, which is precisely where
the 10.5-compatible code is most likely to be relevant.
On 10.5 or nearby versions, the build is most likely to use one of
Apple's old compilers or a custom-built modern upstream GCC.
Apple's older method of checking for availability at runtime
is to check whether the symbol's address is NULL, which works
in all of Apple's compilers and in upstream Clang and GCC.
We implement this in our CHECK_AVAILABLE macro.
* There are multiple ways to determine whether the newer symbol
is declared at all. To keep it simple, avoid a configure check
and stick to a simple macro check.
In older versions of Apple's SDK, Core Text headers have reacted to
"Mac OS X version max allowed" control-knob macros and marked newer
APIs "unavailable" (making any use of them a compilation error) even
if they were known to that SDK. However, the exact macros differ
between SDK versions, and this mechanism (unlike the "version min
required") has apparently never been exposed in compiler/IDE knobs
and possibly not publicized at all. Newer SDKs also no longer mark
symbols unavailable in any case.
So do the simplest thing and just check for the existence
of a macro that was introduced in the same SDK version.
* In 10.5-10.6 SDKs, Core Text used AvailabilityMacros.h and its
MAC_OS_X_VERSION_MIN_REQUIRED; in later versions, it switched to
Availability.h and its __MAC_OS_X_VERSION_MIN_REQUIRED with two
leading underscores. Both headers are available since 10.5, and
Availability.h is more flexible as it has version iOS macros in
addition to macOS, which we may need for other APIs in the future,
so just use Availability.h.
|
| |
|
|
|
|
| |
This allows us to use weak symbols on older Clang and GCC
while guarding them with __builtin_available on newer Clang
to support -Werror=unguarded-availability.
|
| |
|
|
|
|
|
|
|
|
| |
This partly reverts commit d0566318ee5035ca3a4d2d65d46a80a4e3d8244c
and complements the previous commit,
which removed other uses of the FontDescriptor.
By the way, I don't know why check_glyph returns true if !set.
It's been this way since the very first ass_coretext commit,
but no explanation is available, so I'm not sure this is correct.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets us get rid of the font format check in ass_coretext,
which is not available on Mac OS X 10.5 and prerelease 10.6.
This fixes https://github.com/libass/libass/issues/595,
which is about 10.6 prerelease build 10A190, the last Mac OS X
build available for PowerPC CPUs. A separate commit will expand
on this and make us compatible with 10.5 on all CPUs.
This partly reverts commit d0566318ee5035ca3a4d2d65d46a80a4e3d8244c,
where eager is_postscript was replaced by lazy check_postscript because
back then ass_directwrite eagerly loaded all of the system's fonts
and reading is_postscript from each font slowed it down significantly.
But eventually (in particular but not only because even without this
it was still slow for huge font collections) ass_directwrite learnt
to load fonts lazily, so there's a decent chance that this lazy
check_postscript (as well as the lazy get_font_index) isn't necessary
at all any more and can be removed in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On macOS (with Core Text) and some versions of Windows (with DirectWrite)
(specifically, Windows 10+ Win32 as well as all versions of WinRT/UWP),
we read font metadata on our own via FreeType, filling implicit_meta in
ass_font_provider_add_font. However, we forgot to free it upon successful
font registration, leaking the memory allocated for the font name strings.
The list of affected platforms would likely have expanded in the future,
as we eventually intend to read font names on our own across the board.
Leak introduced in commit 887e6cc50bfbe8fc354993682edc03c51203e2fc.
As a quick fix, add the corresponding frees on the successful path.
Ideally, we should refactor this function to avoid copying any freshly
allocated memory to begin with (and thus to avoid the need to free it).
Fixes: https://github.com/libass/libass/issues/699
|
| |
|
|
|
|
|
|
| |
This workaround was added in 44beae2ae57790ba592b8f0d20c0b51006f6b7c7
due to undefined behaviour in inline functions from MinGW headers.
A fix was sent upstream, merged and eventually released with version
11.0.0 in April 2023, obsoleting the workaround on our side.
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/7dcf65a7f26071c6aa26d5a5a8689089ae9a6740/
|
| | |
|
| |
|
|
| |
Architectures without access to precise clocks (MacOS) can profit from it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do not care about CPU arch and vendor when configuring NASM.
Comparing against the full host triplet anyway requires us to
either complicate checks or use more permissive patterns than necessary
introducing a dependency on the specific order of checks.
Notably GNU Hurd’s "gnu" name overlaps with the "-gnu" suffix
used for all glibc systems. This poses a problem for e.g.
kfreebsd-gnu which needs different settings than GNU Hurd.
By using just the actually relevant part, host_os, we can drop leading
globs (and hyphens) for all but *bsd*, avoiding this collision.
There are too many BSD variants to list all explicitly and a check
against canonical names used by config.guess suggest all matches to
*bsd* are actually BSD variants. In practice there are thus probably no
collisions to worry about, but to be extra cautious let’s put *bsd* at
the end.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an important, bug-fix-only release
consisting of 0.17.0 with two cherry-picked patches:
* c1daedea0e829a7e90389818d2bb662fd91d0be7
WHOLE_TEXT_LAYOUT bidi: fix buffer overread on soft-wrapped events
* a943ef542e72e849dc0c1047465e0506781374b5
configure: support x86 assembly on GNU Hurd
Users of 0.17.0 are advised to upgrade to 0.17.1 soon.
Nothing has changed besides fixing crash and build-stopper bugs,
so there are no side effects.
Users of 0.16.0 are also affected by the buffer overread bug and are
advised to upgrade or at least to backport the relevant fix themselves.
Cherry-picked from: e8ad72accd3a84268275a9385beb701c9284e5b3 (tag 0.17.1)
Co-authored-by: Oneric <oneric@oneric.stub>
|
| |
|
|
|
|
|
| |
This is also stored in the outline cache, but a reference from the bitmap cache
can keep an entry alive long after it would otherwise have been dropped.
This can lead to much higher-than-expected memory usage when rendering fonts
with very complex glyphs.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It and its autoconf macros used to be preinstalled by default,
but this is no longer the case, leading to a nonobvious error
during autoreconf in the latests macos CI runs.
|
| |
|
|
|
|
|
| |
brew no longer fails but merely warns if package
are already installed. Explicitly listing all
deps prevents future failures when the preinstalled
set changes (also see next commit).
|
| |
|
|
| |
GDI uses this same matrix.
|
| |
|
|
| |
GDI uses this lookup table to convert these values to the usual scale.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For \clip and Scroll effects, scaled coordinates may not be integers.
Round each coordinate to the nearest integer, not towards zero.
Use lround as opposed to lrint to ensure smoother animations
in case of e. g. a 1px animation step at a 1.5x scaling factor:
lround gives successive steps of 2px, 1px, 2, 1, 2, 1, 2, 1, 2...
whereas lrint would give 2, 1, 1, 2, 2, 1, 1, 2, 2...
(The same reasoning has previously been applied
to \kf coordinates in render_and_combine_glyphs.)
For what it's worth, for Scroll effects, this exactly matches all VSFilter
variants and setups except specific rare cases on MPC-HC's and MPC-BE's
internal subtitle renderers where PlayRes differs from display resolution
(or video storage resolution if the renderer is built as a standalone
DirectShow filter) and MPC ends up off by 1px after double-rounding scaled
Scroll boundaries.
However, for rectangular \clip, all VSFilters truncate the scaled coordinates,
and XySubFilter truncates them twice: at video-storage *and* display
resolution. Furthermore, they compute \clip\t(\clip) relative to the
truncated scaled starting coordinates, whereas libass currently computes it
relative to the truncated PlayRes starting coordinates.
Events that have \clip are additionally clipped to the video area,
but the old code used floating-point arithmetic and rounded the result
also towards zero. For practical values of PlayRes and display size
on practical machines with a 53-bit double-precision float mantissa,
this arithmetic is exact and no loss of precision occurs, although
with a theoretical huge resolution this could lead to the rightmost
pixel column or bottommost pixel row of the video area to be falsely
clipped off (if PlayRes * display res / PlayRes < display res).
But at any rate, this arithmetic isn't necessary at all:
just use the known corresponding integer values.
|
| | |
|
| |
|
|
| |
"Paragraph" can mean multiple things.
|
|
