summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* renderer: consolidate processing of glyph decoration flagsDr.Smile2021-10-055-134/+147
| | | | | | Processing of DECO_ROTATE has moved after ASS_Outline conversion too. All relevant outline processing functions have moved into ass_outline.c. outline_convert() now expects preallocated outline to reduce reallocations.
* rasterizer: use correct memory alignment instead of magic numberDr.Smile2021-09-263-5/+6
|
* rasterizer: use max-blending for outline pair mergeDr.Smile2021-09-265-2/+74
| | | | | | | | | Max-blending is more correct than previous addition-blending in case of small (less than pixel) outline offsets. Fixes buffer overrun (up to 16 bytes read past rst->tile) in add_bitmaps() in case of engine->tile_order < engine->align_order (AVX2 assembly with LARGE_TILES disabled) due to insufficient padding.
* fontselect: don't leak substitution fullname array if it's emptyOleg Oshmyan2021-09-251-0/+1
| | | | | | | | | | | 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.
* ass_face_open: if only one face exists, use it without name checkOleg Oshmyan2021-09-241-3/+11
| | | | | | | | | | | At worst, even if this face isn't actually the desired one, this will just waste memory but won't break font selection. At best, this enables use of some broken TrueType fonts that lack valid PostScript names, as in https://github.com/libass/libass/issues/554. Core Text synthesizes a PostScript name, but FreeType doesn't, so every face has a NULL face_psname. Potentially, a font might also have a non-NULL face_psname that differs from Core Text's.
* ass_face_open: don't return garbage if PostScript name not foundOleg Oshmyan2021-09-241-4/+12
| | | | Fixes https://github.com/libass/libass/issues/554.
* Add strikeout/underline to ASS_Outline, not FreeType-owned memoryOleg Oshmyan2021-09-223-32/+32
| | | | | | | | | | | | | | | ass_strike_outline_glyph was realloc()ing memory that was allocated by FreeType, not us. This isn't generally safe. Indeed, FreeType recently switched to a different allocator on Windows, so this code started crashing. To avoid this, move the ass_strike_outline_glyph call after the FT_Outline -> ASS_Outline conversion. It's safer (less chance to exceed outline size limits) and easier to work with ASS_Outline, anyway. Fixes the crash in https://github.com/mpv-player/mpv/issues/9227.
* configure: add Core Text and DirectWrite to Libs.privateOleg Oshmyan2021-09-181-0/+4
| | | | Fixes https://github.com/libass/libass/issues/211.
* configure: relax check for .gitOneric2021-09-181-1/+1
| | | | | | | 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.
* configure: error if requested feature unavailableOneric2021-09-181-4/+17
| | | | | | | 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.
* configure: Set pkg_requires when foundOneric2021-09-181-9/+6
| | | | This keeps the version info localised
* Use a wrapper script for NASMOneric2021-09-153-2/+30
| | | | | | | | | | libtool assumes NASM accepts the same flags as the C-compiler, which is not actually the case. Previously we used -prefer-no-pic to avoid any additional flags being appended by libtool, which worked well for all tested platforms, but as it turns out it doesn't for NetBSD and OpenBSD. Using this wrapper-script also enables us to automatically define the PIC macro as needed, which became relevant when we started supporting 32-bit x86 PIC-assembly in 026d65e707637b0f90902bca48654871e33575f3.
* ass: treat 'Name' and 'Actor' as synonyms in format linesOneric2021-09-141-0/+13
| | | | | | | | | | | | | | | | | | | | | Commit b3339152db5b80991966911fe2efc8a6174b0071 explicitly defaulted ScaledBorderAndShadow to "yes" for files with custom format lines to allow a subsequent commit to change the global default to "no" to match VSFilter, while trying to avoid breaking files expecting libass' prior default. This commit also changed the fallback ASS event format line to use 'Name' instead of 'Actor' to match what we are actually parsing, what Aegisub is emitting and what is used in the "specification". However, as it turns out, PopSub and files _converted_ by VSFilter actually do use 'Actor', but are expecting the VSFilter-compatible default "no". Thus, treat both variants as synonyms in event parsing and format line comparison. There is a slight inconsistency here, that _Style_ format lines which use _Actor_ instead of _Name_ are not recognised as a custom format line — but a Style Format without a 'Name' won't be able to be used in rendering anyway. fixes https://github.com/libass/libass/issues/516
* renderer: use complementary equations for \clip and \iclipDr.Smile2021-09-145-27/+103
| | | | | | | | | | | | 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.
* Release 0.15.20.15.2Oleg Oshmyan2021-09-125-4/+16
| | | | | | | | | | | | | | | | | | | | | 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.
* fontselect: show codepoint in "failed to find any fallback" warningOleg Oshmyan2021-09-091-2/+2
|
* shaper: don't try to look up glyphs for invisible charactersOleg Oshmyan2021-09-091-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* shaper: update invisible codepoint list to match HarfBuzzOleg Oshmyan2021-09-091-11/+25
|
* font: remove misleading no-op codeOleg Oshmyan2021-09-091-7/+0
| | | | | | 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.
* shaper: skip invisible characters earlierOleg Oshmyan2021-09-091-27/+23
| | | | | | | 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.
* shaper: drop no-op symbol = 0 assignmentOleg Oshmyan2021-09-091-1/+0
| | | | | | 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`.
* Fix load_fonts_from_dir truncating pathsOneric2021-08-151-1/+1
| | | | | | | | 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.
* Fix UB introduced in the previous commitOneric2021-08-091-1/+3
| | | | | | | | | | | | | | | | | 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.
* fontselect: remove path length limitOneric2021-07-101-4/+15
|
* ass_face_stream: don't leak first struct if second alloc failsOleg Oshmyan2021-07-101-1/+3
| | | | | | | | 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.
* ci/gha: do one build for 32-bit WindowsOleg Oshmyan2021-07-101-2/+2
| | | | Reuse the desktop build for this, as UCRT32 doesn't exist.
* ci/gha: remove "tests" from workflow nameOleg Oshmyan2021-07-101-1/+1
|
* ci/gha: make steps natively conditional where possibleOleg Oshmyan2021-07-101-73/+74
|
* ci/gha: add UWP buildOleg Oshmyan2021-07-101-5/+28
|
* directwrite: read metadata from IDWriteFontFace3 if possibleOleg Oshmyan2021-07-104-77/+237
| | | | This avoids an extra trip to FreeType.
* Use gnu_printf format attribute to avoid warnings on MinGWOleg Oshmyan2021-07-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* directwrite: better match_fonts via GDI or IDWriteFontSetOleg Oshmyan2021-07-104-38/+603
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* configure: don't link to check for Windows/DirectWriteOleg Oshmyan2021-07-101-1/+1
| | | | | There's no point. We originally had extra code here that adjusted linker flags before the test, but that's long gone.
* dwrite_c: remove unused GUIDOleg Oshmyan2021-07-101-1/+0
|
* fontselect: automatically read metadata from font file if neededOleg Oshmyan2021-07-104-77/+76
|
* fontselect: reorder function definitionsOleg Oshmyan2021-07-101-150/+150
| | | | This will be needed for the next commit.
* fontselect: save library and ftlibrary in ASS_FontSelectorOleg Oshmyan2021-07-104-40/+42
| | | | ...instead of passing them as arguments everywhere.
* dwrite_c: fix incorrect macro parameter namesOleg Oshmyan2021-07-101-1/+1
|
* Pass last-resort-fallback family name directly to get_font_infoOleg Oshmyan2021-07-103-49/+32
|
* font, fontselect: factor out common code for creating FT_FaceOleg Oshmyan2021-07-104-82/+84
|
* fontconfig: fix misplaced overflow checkOleg Oshmyan2021-07-101-6/+6
| | | | This allowed writes to one past the end of `families` and `fullnames`.
* directwrite: support WinRT/UWP, which forbid LoadLibraryOleg Oshmyan2021-07-103-9/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* directwrite: remove unused #includesOleg Oshmyan2021-07-101-2/+0
|
* directwrite: remove arbitrary 256-char name length limitOleg Oshmyan2021-07-102-11/+32
|
* directwrite: reorder code to avoid possible unneeded allocationOleg Oshmyan2021-07-101-12/+11
|
* directwrite: factor out conversion to UTF-8Oleg Oshmyan2021-07-101-58/+26
|
* directwrite: don't use wrong family names on errorOleg Oshmyan2021-07-101-1/+1
|
* compare: fix _mkdir include on WindowsOneric2021-07-091-0/+1
| | | | | | 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.
* ci/gha: add musl buildOneric2021-07-031-1/+30
| | | | | | | | | | | 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.
* ci: remove TravisOneric2021-06-192-66/+1
| | | | travis-ci.org ceased building on the 15th June 2021
* compare: move libass log to stderrDr.Smile2021-06-101-3/+3
|
* compare: introduce customizable threshold to pass testDr.Smile2021-06-102-24/+71
|
* compare: use case-insensitive comparisons for file extensionsDr.Smile2021-06-101-17/+43
|
* compare: add support for multiple input directoriesDr.Smile2021-06-102-32/+44
|
* compare: reorganize codeDr.Smile2021-06-101-105/+100
|
* fontselect, coretext: match whole extended family on fallbackOleg Oshmyan2021-06-074-51/+71
| | | | | | | | | | | | | | 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.
* coretext: deduplicate found fonts in match_fontsOleg Oshmyan2021-06-071-1/+15
| | | | | | | | | | | 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+.
* ass_utils: add format-string attr to ass_msgrcombs2021-05-311-0/+3
| | | | Allows compilers to print warnings when the args we pass don't match the string
* Fix some format string bugsrcombs2021-05-302-4/+4
| | | | | - ass_drawing was logging size_t as %d - ass_font was logging ASS_StringView as %s (could crash!)
* readme: IRC channel moved to liberaOneric2021-05-261-1/+1
|
* directwrite: add whole font family from `match_fonts`Apache5532021-05-121-9/+16
| | | | | | | 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