| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If static libass is linked into a binary defining functions
of the same name there will be issues. To avoid this use an
ass_ prefix for namespacing.
Before this commit we already did this for most but not yet
all internal API.
read_file is renamed to ass_load_file as ass_read_file
already exists as a public API function. All other functions
are simply prefixed with ass_.
Fixes: https://github.com/libass/libass/issues/222
Fixes: https://github.com/libass/libass/issues/654
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Discovered by OSS-Fuzz.
This is a longstanding bug (since 0.13.0 released in 2015, when
the new fontselect was first introduced), but it should be rare:
it only manifests when Fontconfig has no substitutions configured
(which is unusual) or when font name strdups fail.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=39257.
|
| |
|
|
|
|
|
|
|
|
| |
Another fix for commit 729e48a1eb90bd56b4bb670ee9c8c3821ef12c45:
Paths larger than SIZE_MAX - 256 were significantly truncated and
subsequently tried to be opened in truncated form.
This was likely harmless in practice, but now all theoretically
possible paths should be processed correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The preceding commit 729e48a1eb90bd56b4bb670ee9c8c3821ef12c45
introduced the possibility of UB, when one of the following is true:
- the namelen calculation of the first path overflows to exactly zero
resulting in a NULL namebuf being passed to ass_msg and read_file
- size_t gets promoted to int and the namelen calculation
results in a signed integer overflow
To fix the former we check the namelen calculation for
wrap-arounds and skip such overly long paths.
To fix the latter we specify the constant as an unsigned integer
ensuring type promotion will be done to the larger type between
size_t and unsigned, but never to signed int.
Thanks to Oleg Oshmyan for noticing and helping to fix this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This will be needed for the next commit.
|
|
|
|
| |
...instead of passing them as arguments everywhere.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently implemented only for coretext,
but other providers may/should add this later.
This improves fallback font choice by considering the whole extended family.
This also fixes remaining cases of Core Text fallback failure caused by
differences among the names recognized by Core Text, the name we choose
to return from get_fallback, and the names we seek in find_font.
This partly reverts commit 152d0484e98f118d01987138695cf40579c9e297.
This fixes https://github.com/libass/libass/issues/512.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit be0d1613f79a95073d18d96a60e1394abf9316a2,
get_fallback can return a name from Core Text that is different
from all names that match_fonts registers for the same font.
This causes font fallback to fail as find_fonts fails to
find any font having the name received from get_fallback.
(Moreover, libass will keep retrying fallback for other glyphs,
and the coretext match_fonts will keep readding the same fonts
over and over again.)
Commit 152d0484e98f118d01987138695cf40579c9e297 attempted
to fix font fallback by getting a full name from Core Text
instead of a family name when it was noticed that Core Text's
family name can come from TT_NAME_ID_TYPOGRAPHIC_FAMILY
in addition to TT_NAME_ID_FONT_FAMILY, which we fetch in
get_font_info, but the problem goes deeper: Core Text can return
Macintosh-platform names that don't match Microsoft-platform
names, or the font might have no Microsoft-platform names at all.
Furthermore, returning a full name breaks style matching:
get_fallback does not know about weight, slant etc. and is
expected to return a whole family of fonts that will be
lazy-loaded in its entirety (if applicable) and searched
through for the best stylistic match by find_fonts.
To fix fallback while preserving maximum name portability
in the spirit of be0d1613f79a95073d18d96a60e1394abf9316a2,
use the same API in get_fallback as is used in match_fonts
to look up a family name.
Note: this could be more efficient if ass_get_font_info
could be told to return just an arbitrary family name.
This fixes https://github.com/libass/libass/issues/457.
|
|
|
|
|
|
|
|
| |
If a font contains no recognized Microsoft-platform family names,
use the family name reported by Core Text.
Skip FreeType's face->family_name because it is an ASCII
bastardization of a family name and may not exist at all.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously only both only worked when ass_set_fonts was called after all
embedded and memory fonts were already added. Especially for embedded
fonts this meant it won't work for most users, except mpv, including our
own utilities, even if extract_fonts was set.
Now that it works, enable extract_fonts in our utilities.
GitHub: fixes #266
|
|
|
|
|
|
| |
The latter has overflow protections for size_t indexation and element
size > 1, the former none whatsoever. Change all related vars to size_t.
Additionally, switch to exponential buffer growth.
|
|
|
|
| |
That eliminates most uses of strdup() in the rendering process.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 6c2120a7cb4a6fd648ef37ad8f0d961cbd60f500.
This turned out never to actually be necessary, wasn't actually consistent
with vsfilter, and could result in script authors relying on
accidentally-introduced deviations from vsfilter font matching.
|
| |
|
|
|
|
| |
This fixes a double-free in be0d1613f79a95073d18d96a60e1394abf9316a2
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes a possible NULL pointer dereference, reported by Coverity.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DirectWrite's FontFileStream does not actually use the data of a specific
font in a collection, which was an expectation of the existing code. It
simply returns a stream to the underlying file, collection or not. So we
need to get the index of the font. This needs to be done lazily as this
information is only available in a FontFace, which is expensive to
initialize.
Add a new optional font provider function for lazy initialization of the
index and use it. This is similar to the check_postscript callback.
Fixes libass#275.
v2: fix type of returned value.
|
|
|
|
|
|
|
|
| |
This is a normal course of action and should not generate a warning,
especially for applications which use libass and might notify the user
on such "warnings", while in fact it should be info or even verbose.
Fixes #231
|
| |
|
|
|
|
|
|
|
| |
Return true on success and false on failure.
get_font_info was actually inconsistent, returning false both
on success and on failure due to the face not being scalable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DirectWrite does not provide fast access to the is_postscript flag,
requiring each font to be loaded before its format can be determined.
Eagerly doing this for every installed font can be quite slow,
on the order of seconds.
To improve performance, ask the font provider for this information
only when it is actually needed, i.e. when one of the font's full
names or its PostScript name matches a requested font name and we
need to know whether to accept this match.
The return value of check_postscript is not cached in this commit.
This makes repeated calls slower than accessing is_postscript was.
This should not be a problem, but if it is, the value can be cached
(or precomputed) by font providers in their font private data.
This commit also potentially increases the memory usage of some
font providers by retaining data structures needed to implement
check_postscript in their font private data. This should not be
a problem either, but if it is, the value of check_postscript
can be precomputed by all providers other than DirectWrite.
|
|
|
|
|
|
|
|
| |
Fixing this properly involves constifying ASS_FontProviderMetaData
and refactoring code that allocates and frees strings stored in it.
This seems easy on the surface but turns out to be nontrivial when
you actually try to do it. This may still be done at a later date,
but for now, just add explicit casts.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This matches the behavior of GDI and hence VSFilter.
Note that \fn arguments are trimmed during parsing.
However, none of the names inside fonts should be trimmed,
and @-prefixed fonts should keep whitespace following the @,
both of which this commit addresses.
Remove strdup_trimmed because it is no longer used. Also remove
the declaration of a function that was deleted a few months ago.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Related to commit e00691e8096cc69e5651480155ebc61d9e079290:
it turns out that GDI (and hence VSFilter) does not check full names of
fonts that have PostScript outlines when searching for a font by name.
To summarize the resulting behavior:
* Fonts with PostScript outlines can be found by family name
and by PostScript name.
* Fonts without PostScript outlines can be found by family name
and by full name.
|
| |
|
|
|
|
|
|
|
| |
Fonts without PostScript outlines (such as TrueType fonts) are unaffected,
and their PostScript names continue to be ignored when searching for fonts.
This matches the behavior of GDI and hence VSFilter.
|
|
|
|
|
|
| |
Currently this affects only the verbose output in
ass_font_select, but it will become more useful when we
start matching against PostScript names in the future.
|
| |
|
|
|
|
| |
index is signed, and psname only overrides it iff index < 0.
|
|\
| |
| | |
MSVC/ICL and general header fixes
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As before, this does not add any build system support:
a config.h file and a project must still be manually created
(or the compiler can be run manually instead of using a project).
Signed-off-by: Grigori Goronzy <greg@kinoho.net>
Signed-off-by: Oleg Oshmyan <chortos@inbox.lv>
|
|/
|
|
| |
It was needed for UTF16BE -> UTF8 only, which is trivial to implement.
|
|
|
|
|
| |
This seems to cause issues on MSVC. Considering that even most Unix OSes
hate PATH_MAX and don't really honour it, using 4096 is just as good.
|
|
|
|
|
|
|
|
| |
OS or platform-specific locale independent functions are painful to
use and/or not available, so roll our own. Not great but the least
painful and least intrusive.
v2: fix indexing, use static inline
|
|
|
|
|
|
| |
Passing NULL as argument to %s format specifiers when using the printf
fasmily of functions is not allowed. While some libcs handle it, other
libcs will simply crash.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also fixes the build on OSX under some circumstances (weird and
inconsistent rules for the inline keyword in C).
|
| |
|
|
|
|
| |
Introduced by commit d6bb9af6. Found by coverity scan.
|
|
|
|
|
| |
The name is always pulled from the font info, which is static, so
there is no need to strdup.
|
| |
|
|
|
|
|
| |
fontselect is an internal only API for now. That said, it also seems
much more sane to let library users deal with this resource management.
|
|
|
|
| |
In case a font provider actually uses more than one substitution.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We don't want to add fonts multiple times, so call match_fonts lazily,
i.e. only after selecting a font with a certain name failed. Since
font matching interacts with glyph coverage checks, add a simple
mechanism to determine whether matching failed because of name or
glyph coverage. Additionally make sure to handle substitutions before
any calls to match_fonts; this only correctly deals with single-name
substitutions, though.
|
| |
|
| |
|
|
|
|
|
| |
The default font provider needs to provide a GetFallbackFunc callback
instead.
|