| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
They are not used
|
| |
|
|
|
| |
We already used aarch64 everywhere (am conditionals, macros, filepaths)
except for this one config-internal cpufamily variable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hurd too uses ELF and 16-byte stack alignment
just like Linux and many other Unix-likes.
Supposedly its host triplet can include a version number at the end.
Without getting more specific about how a version number is allowed to
look like, checking for *-gnu* overlaps with X32's -gnux32 suffix which
is present on non-Hurd systems.
Linux is the only X32 platform I know about and it uses an identical
configuration to GNU Hurd, so this shouldn't be a problem. Though to be
safe, let's move the case with *-gnu* at the end, to ensure if there's
a "-gnux32"-like suffix on any non-Linux, non-Hurd system it will match
the proper host regex before seeing Hurd's *-gnu* pattern.
Thanks to youpi1 for advice about Hurd and testing.
|
| | |
|
| |
|
|
| |
This will scale better with future assembly support.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This release’s major feature is the addition of a new ASS ScriptInfo
header pair: LayoutResX and LayoutResY. The introduction has been
coordinated with active VSFilters and will soon be available in
xy-VSFilter and XySubFilter as well.
Since the beginning, many features in ASS scale relative to or are
otherwise affected by the storage resolution of the video file the
subs are bundled with. Adjusting subs for different video resolutions
traditionally took non-trivial effort. Of course this behavior must be
kept by default to preserve compatibility with existing files. But now,
setting both of the new headers to a positive, non-zero value will
replace the video storage resolution with the specified resolution for
the whole file, allowing easy reuse across all encodes of the same
display aspect ratio. This includes PAR effects, so reuse across
anamorphic and non-anamorphic releases is possible too.
Apart from that, some notes for package maintainers:
* for ASS_FEATURE_WRAP_UNICODE to be usable at runtime, libass must be
linked against the new optional dependency libunibreak whose source
currently resides at https://github.com/adah1972/libunibreak
* switching to a non-recursive build means it is no longer possible to
invoke make in subdirectories. However this wasn’t really useful
anyway and everything else, including uninstalled binary locations,
was kept unchanged.
* reminder: as announced last release more keys are now authorized for
signing release tags and tarballs; a signature of any one of those
keys is sufficient. See the MAINTAINERS file in the last or this
release’s tarball for a complete list and more details.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Setting this feature allows breaking lines according to the Unicode
Line Breaking Algorithm and is incompatible with VSFilter.
This is useful for non-ASS renderers utilising libass, especially for
languages typically not using ASCII-spaces to separate words, but
also to correctly break on punctuation even in languages that do. It
does not allow breaking words apart, so line overflow might still occur.
For this to work a new optional dependency on libunibrak is added.
We assume FriBidi's and libunibreak's utf32/glyph type match.
This is based on an earlier patch by GitHub user siikamiika.
|
| |
|
|
|
|
|
|
|
|
| |
Use `-j 1` in CI for unmangled output.
In the future this could be improved by integrating with Automake's
test support to get better output with multiple jobs. Considering
the layour of the crash tests will likely change and that currently
the tests run in less 15 seconds even with just a single thread,
this should be good enough for now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parses its input and renders every event
at its start, middle and end.
By default it is built as a simple standalone program,
similar to profile to consume a single already existing input.
By setting ASS_FUZZMODE in FUZZ_CPPFLAGS alternative buildmodes offering
integration into AFL++ or LLVM's libFuzzer can be selected.
As libFuzzer links in its own main function, it cannot be used during
configure else the tests fail. Instead 'clang -fsanitize=fuzzer-no-link'
can be set together with FUZZ_LDFLAGS='-fsanitize=fuzzer' to only link
in the main function into the desired binary.
As an alternative to FUZZ_LDFLAGS, it is also possible to change
the compiler after configure via make CC=...
|
| |
|
|
|
|
|
|
|
| |
It was added in ce26c316751e7dbe844d5069731da9de32507ea3 together with
a C++ equivalent due to encountering unnecessary checks for a
Fortran compiler. The C++ version was removed since and today no Fortran
or C++ checks occur with the define override removed and probably
shouldn't have occured back then either.
Perhaps the shave scripts or some since fixed libtool bug was to blame.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Non-recursive Makefiles allow better and more robust automatic
dependency resolution and higher parallelism for shorter build-times.
This change keeps all locations of the non-installed targets unchanged
for minimal firction. Calling make from subdirectories no longer works,
but instead the specific build targets can be invoked directly from the
toplevel.
If we bumped the required Automake version to 1.13+, the library
fragment could use %reldir% or %D% to be unaffected by potential
future directory moves, but it is unlikely we'll ever change the
location or name of the libass directory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This release brings a new `ASS_FEATURE_WHOLE_TEXT_LAYOUT` API toggle,
brings an important API change on (only) Microsoft's Win32 platform to enable
arbirtrary paths to be used rather than only ANSI ones, fixes an incompatibility
with FreeType versions >= 2.11.1 on Win32 and brings many more bug and
compatibility fixes as well as other improvements.
API users are highly encouraged to pay special attention to the following points:
* The documentation has been expanded and multiple errors in it have been fixed.
It may be worthwhile to reread the documentation for all functions you are using
(or all of it). If you still have questions afterwards or spot an error,
please contact us so the docs can be further improved.
* For those on Win32 only (other platforms do not
require special handling of the path's encoding):
The new support for arbitrary paths via the new dual encoding used
in the majority of our API is mostly backward compatible, i.e. continuing
to use `fopen` ANSI paths works mostly as well (or bad) as before except
when there are actual on-disk name collisions. However, the other way around,
using the new encoding with older libass binaries, will in general fail
unless the paths happen to be pure 7bit US-ASCII.
If you want to make use of arbitrary paths but also wish to continue to support
older libass versions, you should continue to always use the `fopen`
encoding if `ass_library_version() < 0x01502002`.
Technically, this should be accompanied by an increase in the minor soname version,
but there is none because the change is Win32-specific and the minor soname version
is not even used by the dynamic linker in common MS Windows setups.
Signed-off-by: Oleg Oshmyan <chortos@inbox.lv>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively reverts c9c4fed39339ffde45123013a117e06d0bb9c488.
The mutation was originally removed because no one knew why it was done,
the spec suggests the fields should be independent of the static or
shared nature, the mutation bears risk of overlinking and no other
project I looked at did such a thing.
This works out well for full shared and full static builds. Mixed
builds with some libraries linked static and others shared were not
considered when removing the mutation and apparently pkg-config did
not consider this case either.
Using a custom static-only build of the desired libraries with a mutated
pc-file has become a common workaround for poor mixed build support of
pkg-config and many buildsystems. It's still very much an imperfect
workaround and doesn't do anything for mixed builds when both library
variants were built. Ideally pkg-config and buildsystems should be
improved to be able to handle this in the general case. Realistically
this won't happen in the foreseeable future though.
At least for the pkg-config side and when using a major (modern) linker
the effect can be emulated without mutating the pc-file by using
pkg-config's `--static` flag and telling the linker to only link
actually used libraries (`--as-needed` for GNU bfd, GNU gold, LLVM lld
and mold; `-z ignore` for illumos' linker).
In between the mutation being removed from libass and now being added
again, FriBidi and FreeType adopted this mutation workaround, FreeType
citing meson doing the same as a motivation. Indeed HarfBuzz's meson
build (but not the autotools build) will also mutate its pc-file.
meson itself started mutating pc files in 2018 (see meson commit
3f7c6cf3d6a204e9665faad3c05bb5049f08ac74). Going further back, FFmpeg
already mutates its pc-files since 2009 (see FFmpeg commit
12701f6e31f465377462c0fc2d5b34477c1c422b).
Reinstate the mutation (now with explaining comment) in libass to help
out affected builders and to foster consistency with other projects
while hoping no one runs into overlinking issues.
|
| |
|
|
| |
Omission in commit 6d4d51db96858f37570d169b18abc68f875c657e.
|
| |
|
|
|
|
|
|
|
|
|
| |
We detect x86 and enable building asm code in `configure`.
However, before this commit, we don't actually use that code
unless we detect x86 via the C compiler's predefined macros.
We could check more macros to support more C compilers,
but what we really want is to use the same trigger
for both building and using this code. To that end,
add ARCH_X86 to config.h iff x86 asm is being built.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we use `INTEL` to denote any supported x86 variant
and `X64` to denote specifically x86-64 (and previously used
`X86` to denote 32-bit x86).
`INTEL` is a subpar name for two reasons:
* Intel has produced notable non-x86 architectures (Itanium).
* x86-64 was designed and patented not by Intel but by AMD.
This is currently only used in configure.ac and Makefile.am,
so it does not matter much. However, the next commit will expose
a config.h macro flagging the whole x86 family, which non-Autotools
users will have to set manually, so this will cease being a purely
internal choice and will start confusing users.
Instead, the most generic name for the whole family that is in common
use and does not suffer from such problems is "x86", so use `X86`.
The switch is slightly complicated by the fact our configure.ac and
Makefile.am used to use `X86` as in Microsoft's naming scheme, where "x86"
means "32-bit x86". Ideally, we would use another equally good name for
the family that is free from this ambiguity; however, I know no such name.
(Indeed, `X86` as a name for 32-bit x86 is problematic even if one
disregards x86-64, because 16-bit x86 exists as well. This commit
technically leaves configure.ac to lie about 16-bit x86 by setting
`X86=false`, but we have no 16-bit assembler code, so the new use of
`X86` should be viewed as a name for "any *supported* variant of x86".)
To somewhat highlight that we're no longer using Microsoft's scheme,
also switch the name for the x86-64 architecture from `X64` to `X86_64`.
This should also make it more intuitively obvious that one (X86_64) is
a subset of the other (X86). This is also a more standard name with a
clearer etymology, and we already use this name in our `ASFLAGS`.
|
| |
|
|
|
|
|
|
|
| |
It was used when we had ASFLAGS logic in Makefile.am,
but all ASFLAGS logic has been consolidated in configure.ac
and we have not used this conditional ever since.
Unlike the conditional flagging x86-64, which can be used
for building x86-64-only assembler files, it does not seem
that the 32-bit conditional will ever be useful again.
|
| |
|
|
| |
--broken implies --dirty, but the former is only available since 2017
|
| |
|
|
|
|
| |
0.19.0 was not a proper release, but used during a development phase
from 2004-2008 and not all variants of 0.19.0 already contain all the
features we need.
|
| |
|
|
|
|
|
|
| |
We use FT_Face_GetCharVariantIndex which is only available since
external version 2.3.6 (== internal verion 9.17.3), which is higher
than the current previous minimum of internal 9.10.3 == external 2.2.1
This fixes an oversight in commit d7544850775344879dd3049046c5b7ce2d52d3b3
|
| |
|
|
|
| |
Old git versions do not understand --broken
or the git-environment may be broken
|
| | |
|
| |
|
|
|
| |
AC_INIT already defines a macro for the version
so there's no need to create our own.
|
| |
|
|
| |
Fixes https://github.com/libass/libass/issues/211.
|
| |
|
|
|
|
|
| |
For a top-level non-bare repository .git will be a directory,
but for submodules .git is a regular textfile containing the relative
path to the actual git-directory which will be subdir inside the
toplevel repositories git-directory.
|
| |
|
|
|
|
|
| |
And fix fontconfig's help string; 7a9b40bfe0ec240a7e74b36e2e2f284d00b1023c
made fontconfig required by default, but it was ommitted to change the
help string back to "check" when the default behaviour changed again in
928f7a3c7e53daee99b3a27a50199192393e224f.
|
| |
|
|
| |
This keeps the version info localised
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another bug fix release without API or ABI changes, mainly to
fix more known 0.15.0 and 0.15.1 regressions. But as a bonus,
it is now possible to build the DirectWrite system font provider
for Microsoft's Universal Windows Platform (UWP).
Two known minor 0.15.x DirectWrite system font regressions remain:
* when a font is attached/memory-loaded but a different (non-attached)
style of the same font is used by the subtitles
(only the attached style[s] will be used;
this also affects Core Text since 0.13.0 but not Fontconfig);
* in the unlikely case that the full name of a system font
equals the _family_ name of another system font
(only the family name matches will be found).
Also please note that our IRC channel #libass has moved from freenode.net
to Libera.Chat, and all presence on freenode.net has been fully retired.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CreateFontFromLOGFONT does not actually use GDI's font lookup logic
and fails to emulate it faithfully. In particular: it fails to find
CFF-outline fonts by PostScript name; it fails to find TrueType fonts
by full name on older versions of Windows; it fails to find at least
some fonts installed on demand by font managers.
When GDI is available, invoke GDI directly. This commit uses
EnumFontFamilies, which is almost perfect, except that if the user has
two different fonts such that one font's family name equals another's
full/PostScript name, this will find only the family name match.
To fix this case as well, we'd need to invoke CreateFontIndirect
separately for each font request, complete with its weight and slant.
This requires larger changes in our fontselect, which this commit
does not attempt yet.
GDI is not available in WinRT/UWP. On UWP (Windows 10), use the new
IDWriteFontSet API to emulate GDI's font lookup as well as we can.
In WinRT (Windows 8), we have no choice but to keep using
CreateFontFromLOGFONT (unless we go back to loading all fonts
eagerly, which we stopped doing for performance reasons).
It is the builder's responsibility to avoid linking in Gdi32.lib
in WinRT/UWP builds, just as it is to link in Dwrite.lib.
|
| |
|
|
|
| |
There's no point. We originally had extra code here that
adjusted linker flags before the test, but that's long gone.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, we delay loading Dwrite.dll until runtime to allow building
and running DirectWrite-enabled libass binaries on old Windows versions
that lack DirectWrite. However, this is forbidden in WinRT/UWP.
DirectWrite is present in all versions of Windows that support WinRT/UWP,
so we lose nothing by requiring it.
Older Windows SDKs (Microsoft and MinGW alike) lack <winapifamily.h>,
so include it only if we really need it.
Based on VLC patch for libass:
https://github.com/videolan/vlc/commit/eedb57aa96d2bc0046a6da2e081c75ae9edf8fd5
and on this autoconf code:
https://github.com/lu-zero/mfx_dispatch/commit/c51a54c15f51579804030c70592c0a26065f1242
Note: the VLC patch retained an unconditional call to FreeLibrary
in destroy_provider. However, FreeLibrary does not actually expect
NULL as argument, so this commit adds a guard to that call.
Perhaps FreeLibrary(NULL) simply fails cleanly and that's why
this has not caused VLC problems, but we should not rely on this.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This could help us in future bug reports and we already do so for
shapers and freetype. Also include a guess about the source code
version, which may not be entirely reliable. Eg if custom tarballs are
involved or if patches are added after configure was called, the value
will be wrong.
But hopefully it will be "good enough" for most cases.
|
| |
|
|
| |
This should fix the warnings introduced with nasm 2.15
|
| |
|
|
| |
AC_LANG_PROGRAMM only takes two parameters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
AC_CONFIG_HEADER has been replaced with AC_CONFIG_HEADERS for a long
time and recent version of autotools started complaining about it.
AC_HEADER_STDC has been deemed "obsolescent" and unneeded for
"new programs" since at least autotools 2.60, which was released 2006.
On top of it we're not even using its output variable anywhere to
check if the system headers do in fact conform to the C standard, so
remove this superfluous test.
AC_HEADER_STDBOOL is not obsolecent, but simalarly to AC_HEADER_STDC we
never use its output anywhere, so it can be removed as well.
|
| |
|
|
|
|
|
|
|
| |
This patch was adapted from FreeBSD:
https://svnweb.freebsd.org/ports/head/multimedia/libass/files/patch-configure.ac?view=markup
and was also applied in DragonFlyBSD (eventhough DragonFlyBSD dropped
32bit support in 2014)
closes https://github.com/libass/libass/issues/451
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This allows to eg supp |
