| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Basic symmetry considerations require that
clip_func(src, clip) = iclip_func(src, 255 - clip),
but we use unrelated expressions for them:
clip_func(src, clip) = (src * clip + 255) / 256 !=
iclip_func(src, iclip) = max(src - iclip, 0) = max(src + clip - 255, 0).
Version with multiplication is more correct (albeit slower) as it gives
results closer to the infinite resolution reference (per compare -s 8)
in case of half-transparency. So I've picked better function
(clip variant) and derived another from it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fonts don't need to contain any glyphs for these code points.
Their special effect on layout (if any) will be handled by FriBidi
and/or HarfBuzz, and they will be replaced by zero-width glyphs
regardless of whether any font glyph was provided.
By trying hard to find a glyph as we currently do, we end up
mistakenly splitting shape runs on control characters that lack font
glyphs and therefore ruining shaping, as well as logging unnecessary
warnings about the missing glyphs.
There are some quirks and exceptions. In particular, font glyphs
for normally-invisible characters may be retained by recent HarfBuzz
if OpenType substitutions are involved (which sometimes matches
and sometimes doesn't match Uniscribe). This commit happens to retain
this behavior for visible glyphs contained in the main font (as opposed
to any arbitrarily-chosen fallback fonts) by virtue of defaulting
run-leading invisibles to face_index 0, where HarfBuzz will find
the glyphs on its own. Meanwhile, the case of _fallback_ fonts inserting
visible glyphs doesn't even seem to be desirable to begin with.
Preliminary testing shows this commit's logic matches Uniscribe in some
common cases, but tests with musical symbols show strange results.
More research is needed to match Uniscribe and hence VSFilter even better.
On the other hand, this logic is likely not sophisticated enough
for "optimal" typesetting without regard to Uniscribe compatibility.
For example, Blink does not look up glyphs and split font-fallback runs
prior to running HarfBuzz at all, and instead runs HarfBuzz on the whole
higher-level run at once and then reruns it with the next fallback font
on just those substrings that HarfBuzz failed to shape. In any case,
some Default_Ignorable glyphs are more appropriately viewed as logical
prefixes than suffixes and should be grouped with the following,
not preceding, character in case of doubt. Furthermore, when a fallback
font is used for a sequence of text, it may be desirable to use the same
font for intervening or surrounding whitespace or punctuation even if
the main font (or another fallback font) also contains glyphs for them;
and whitespace characters can be synthesized in lieu of import from
another font, and indeed HarfBuzz does synthesize them, but this is not
always desirable. Additionally, the glyph HarfBuzz uses for zero-width
substitutes may actually be visible as it defaults to the font's basic
space glyph: if we were to forget about Uniscribe, we should define
a custom, fake glyph index and translate it into `skip`.
Finally, our higher-level shape run splitting is not perfect either:
bidi splitting after script splitting can create awkward short runs,
and in general, script splitting seems problematic in itself.
Fixes https://github.com/libass/libass/issues/507 (log messages).
Supersedes and closes https://github.com/libass/libass/pull/508.
Fixes misshaping such as in the sample in
https://github.com/libass/libass/issues/71#issuecomment-48186912,
https://github.com/libass/libass/issues/71#issuecomment-61705139.
However, this particular sample was actually a combined result of
unnecessary font fallback (which this commit fixes) with another bug
that was fixed in commit 80ce6378d572c230923bfc239f679e8604b8448a:
it already renders correctly since that commit,
but the current commit alone would also have fixed it.
|
| | |
|
| |
|
|
|
|
| |
ass_font_get_index is _always_ called with *face_index == 0,
and even then it's only a fallback default rather than a request:
it should be treated as an output-only parameter.
|
| |
|
|
|
|
|
| |
Currently, this move does not affect functionality, as both shapers
ignore `skip` on input, and the complex shaper resets `skip` on output.
Later commits will use this `skip` flag to guide shaping run splitting
and font fallback before shaping happens.
|
| |
|
|
|
|
| |
Currently, this assignment affects nothing, as every subsequent `symbol`
check is paired with a `skip` check. However, the next commit will move
this code to an earlier pipeline stage where we need the original `symbol`.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
Bug in commit a7f67df5f96f03fab6661d90d716c16e0fab4a21, which introduced
the alloc check. Before that, alloc failure would result in illegal
memory access, so at least this was an improvement.
Fixes CID 350862 found by Coverity Scan.
|
| |
|
|
| |
Reuse the desktop build for this, as UCRT32 doesn't exist.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This avoids an extra trip to FreeType.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use %zu format specifiers to log size_t values.
However, __attribute__((format(printf, ...))) in modern GCC means
"system's default" printf, which on MinGW means MSVCRT.DLL printf,
which does not support the z length modifier (even on Windows 10),
so GCC warns that our format strings are invalid.
Older GCC is unable to check Microsoft's format strings at all and
has only format(printf), which is equivalent to the newer gnu_printf.
Clang also lacks gnu_printf, but it is covered by the same macro
check because its __GNUC...__ macros always report version 4.2.1.
On non-Microsoft platforms, printf and gnu_printf are currently
aliases, so the __MINGW32__ check is redundant. However, with some
luck, GCC may start to check other platforms' printf formats more
carefully in the future; and we would like to receive warnings
if our format strings don't work on some platform, although we
intend to stick to standard C99 format strings. Indeed, if we use
an extension by accident, this might help us catch it. And even if
we make no mistake but there is another platform that fails to
support C99 format strings, this might warn some poor soul building
on that platform that their system printf doesn't understand our
log format strings, so they will know they need to work around it
in their log callback or to patch libass.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
This will be needed for the next commit.
|
| |
|
|
| |
...instead of passing them as arguments everywhere.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This allowed writes to one past the end of `families` and `fullnames`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
To use Microsoft's _mkdir one must include direct.h, not sys/stat.h as
for POSIX's mkdir. This is still true with modern MinGW headers used.
The sys/stat.h include remains required for stat.
|
| |
|
|
|
|
|
|
|
|
|
| |
Since GHA only has native support for glibc-linux use Alpine via Docker.
Even though GHA does have native Docker support, its
`job.<name>.container` option cannot be used here, as there appears to
be no way to set a noop image name atm (empty string causes an error).
Using `tail -f /dev/null` to keep the image running (while ignoring
zombie processes) was taken from GHA's native Docker setup procedure.
Relies on /home/runner/work being the default for checked out repos.
|
| |
|
|
| |
travis-ci.org ceased building on the 15th June 2021
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
We ask Core Text to match multiple name fields, and a single font may
match several at once. In this case, by default, Core Text duly returns
the font multiple times, and we add it to fontselect multiple times.
This does not break anything, but it is a waste, so ask Core Text
to deduplicate the returned list.
This is supposedly available since Mac OS X 10.5.
We support Core Text on 10.6+.
|
| |
|
|
| |
Allows compilers to print warnings when the args we pass don't match the string
|
| |
|
|
|
| |
- ass_drawing was logging size_t as %d
- ass_font was logging ASS_StringView as %s (could crash!)
|
| | |
|
| |
|
|
|
|
|
| |
match_fonts is supposed to add all the fonts with the same family name
for fontselect. Commit d325c633f4ac32fcb4c76a3fb5926737a45c38d0 adds
only one font, which leads to inability to select (using family name)
correct fonts from families with multiple styles.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Update SubtitlesOctopus' link and clarify Crunchyroll's relation to
SubtitlesOctopus/libass.
Perian is considered abandoned by the Maintainer, see
https://github.com/MaddTheSane/perian/issues/16#issuecomment-752262482
Add AssRender AviSynth(+) filter. AviSynth-wiki contains link to a
somewhat active repo by pinterf.
closes https://github.com/libass/libass/issues/482
|
| | |
|
| |
|
|
|
| |
Replace missing strndup() with its standard C equivalent
and circumvent unimplemented second argument of mkdir().
|
| |
|
|
| |
It's technically more correct.
|
| | |
|
| |
|
|
|
|
|
|
| |
get_bitmap_glyph copies this struct via assignment. But to allow
safe assignment-copy, it seems the whole struct must be initialized,
rather than merely each of its members.
Fixes CID 314186 found by Coverity Scan.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
scan_fonts can be very slow when many fonts were installed in
the system. Use IDWriteGdiInterop to create a font by its name
when needed instead of scanning all installed fonts during the
initializing stage to get better performance. In case of a
non-existent font, the fallback mechanism should do its work.
Fixes https://github.com/libass/libass/issues/334.
Signed-off-by: Oleg Oshmyan <chortos@inbox.lv>
|
| |
|
|
|
| |
GCC and MSVC (at least) warn about this cast as the function types
appear to be incompatible. This is correct with GetProcAddress.
|
| |
|
|
|
|
|
|
| |
Second argument of cglobal macro for fill_halfplane in 64-bit mode
should always be 6 to preload all function arguments into registers.
It doesn't matter under *nix as the first 6 arguments are already
in registers according to calling conventions, but under WIN64
it's only the first 4.
|
| |
|
|
|
|
| |
All Create and Copy functions create new objects, so all of them may fail.
Keep using SAFE_CFRelease only in shared cleanup clauses.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
