summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Verbose Coveritycoverity_verbose_testOneric2020-11-142-2/+14
| | | | | | | | | | | | | | | | | | Try to figure out why coverity is partially failing on gcc builds. Last known working build: commit 66dba8dd21bbf81b25b26e2556c404006f80a43c Disable bidi bracket matching unless enabled via ASS_Feature travis Job 545 https://travis-ci.org/github/libass/libass/jobs/725186827 First known faulty build: commit 42aa6ee392a25a5f699c44bca329fd6363879779 ass.h: Mark deprecated declarations as deprecated travis Job 557 https://travis-ci.org/github/libass/libass/jobs/709309420 In between were some builds/commits coverity didn't run on.
* configure: Fix --enable-large-tilesOneric2020-11-141-2/+2
| | | | | | Due to a misplaced comma this config switch was broken. A follow-up commit will change our autoconf-style in a way, that should make it harder for errors like this one to slip in.
* configure: use AC_SEARCH_LIBS instead of AC_CHECK_LIBOneric2020-11-141-1/+6
| | | | | | | | | | | This avoids unneccessary -lm flags on some platforms integrating libm into libc and allows us to detect systems that do not provide implementations of math functions in either libc or libm. The caveat is, that some systems, like FreeBSD split their math functions between libc and libm. By checking for C99 lrint instead of C89 fabs, this check correctly includes libm in FreeBSD; let's hope this also holds for other systems splitting up their math.h implementations.
* configure: remove unnecessary CXXFLAGSOneric2020-11-141-1/+0
| | | | | | | Those were added in commit 29fd129671bb66a2e54717ca666b6ccd7f7ee941 together with the initial DirectWrite implementation, which was in C++. As of 1c55ca966f356030a863479459055c48e98ed1e5 our DirectWrite implementation is C, so CXXFLAGS are no longer needed.
* configure: Explain iconv-check logicOneric2020-11-141-0/+4
| | | | | | | | | | Commit 8bebabe4a62a6d54cdfecace59c382efa80a8e47 apparently added the libiconv_open check to support libraries like GNU libiconv defining their iconv-functions as a macro expanding to lib*. As this i not immediately obvious, add an explaining comment. Additionally AC_SEARCH_LIBS will first try to link the ptrogramm with only the current $LIBS and not add anything to $LIBS if that already succeeds, thus avoiding adding '-liconv' twice.
* configure: Don't add iconv to pkg_libs a second timeOneric2020-11-141-8/+4
| | | | | | | | | This seems to have erronously slipped in again with commit 5ab9950816ffcac46afec4ad327640ab28a49109. It was previously addded in commmit e572a26d29ddff883880ef7b1c295acaa62a8a2f when all libs were still added manually and shortly after removed again in commit 4b6a81eb4fd79198ceef813418aaa938190624ba, which switched to generating pkg_libs from LIBS.
* configure: Reoder configuration logicOneric2020-11-141-137/+150
| | | | | This should make this a bit easier to understand and more readable. Apart from comments nothing was removed or added, just reodered.
* autotools: Set automake flavour on AM_INITOneric2020-11-142-2/+1
|
* configure: add Haiku NASM supportOneric2020-11-141-2/+13
| | | | | | And print an error on attempts to use ASM on an unrecognized system as NASM would very likely produce borked files anyway. (erroring out can still be avoided with --disable-asm)
* Travis CI: encrypt notification channel name to avoid fork spamOleg Oshmyan2020-11-131-1/+2
|
* Travis CI: run Coverity Scan only in one job per buildOleg Oshmyan2020-11-131-7/+5
| | | | Specifically, this is (currently) the GCC job.
* Travis CI: don't run ./configure twiceOleg Oshmyan2020-11-131-1/+0
|
* Travis CI: use make -j2Oleg Oshmyan2020-11-131-2/+2
| | | | | | https://docs.travis-ci.com/user/speeding-up-the-build/#makefile-optimization and https://docs.travis-ci.com/user/reference/overview/#virtualisation-environment-vs-operating-system suggest -j2 should be optimal on all VMs.
* Travis CI: use before_script and split commandsOleg Oshmyan2020-11-131-2/+3
| | | | | | | | | | The sequence is before_install -> install -> before_script -> script. `install` is supposed to be the one where dependencies are installed, but apparently the apt and homebrew plugins do it earlier. I'm not sure why the docs suggest putting `apt-get install` in `before_install`, but we no longer even do that. It definitely seems like the wrong stage for `./autogen.sh` and `./configure`, even if it currently affects nothing in practice.
* Travis CI: rename old `matrix` key to current `jobs`Oleg Oshmyan2020-11-131-1/+1
|
* Travis CI: remove obsolete `sudo` keyOleg Oshmyan2020-11-131-1/+0
| | | | We don't even use sudo since commit fb7731c85daccc635bf67608d3f8e45d9b61d578.
* Travis CI: use official syntax for env varsOleg Oshmyan2020-11-131-1/+1
|
* ass_library: Constify ass_add_fontHugo Beauzée-Luyssen2020-11-013-3/+3
| | | | | Both parameters are copied and are immutable. Make it clear through the function prototype
* Treat zero-area events as explicitly positionedOneric2020-10-311-2/+4
| | | | | | | | | | | | | | | | | | | VSFilter does collision by calculating the intersection of two events rectangles and treating events as colliding iff their intersection has a non-zero area. As a consequence zero-area events cannot collide with anything. https://github.com/Cyberbeing/xy-VSFilter/blob/xy_sub_filter_rc4@%7B2020-05-17%7D/src/subtitles/RTS.cpp#L1627 libass does not do collision by intersection area, but because we ignore edge-edge intersections results are identical to VSFilter for non-zero-area events. To reconcile the results for zero-area events, treat them as explicitly positioned as they effectively are in VSFilter. This allows us to keep our (probably) faster collision code and saves us from unnecessary collsion checks for zero-area events. Fixes https://github.com/libass/libass/issues/444
* Don't carry xbord width across eventsOneric2020-10-311-0/+1
| | | | | | Since text_info is not re-initialised before every event, border_x could carry over to following events with a smaller \xbord value. This was broken in commmit 236bc18d39c080853d1145c7b978fb8f47e31deb
* ass_utils: round double_to_d* properlyOleg Oshmyan2020-10-291-3/+3
|
* shape_harfbuzz_process_run: round scaled positions properlyOleg Oshmyan2020-10-291-4/+4
|
* Match more types and format specifiers to size_t fontdata_usedOleg Oshmyan2020-10-281-2/+2
| | | | | | | | Omissions in commit 910211f1c0078e37546f73e95306724358b89be2. Microsoft's C library does not support %zu until Universal CRT (Visual Studio 2015). At worst, this verbose-level message will look wrong and be useless.
* decode_font: fix subtraction broken by change to unsigned typeOleg Oshmyan2020-10-271-2/+2
| | | | | | | | | | | This caused a one-byte buffer overwrite and an assertion failure. Regression in commit 910211f1c0078e37546f73e95306724358b89be2. Discovered by OSS-Fuzz. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26674. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26678.
* Release 0.15.00.15.0Oleg Oshmyan2020-10-275-6/+46
|
* Add missing file to MakefileOleg Oshmyan2020-10-271-1/+1
|
* Work around broken Travis CI macOS buildOleg Oshmyan2020-10-271-0/+1
| | | | | | Sigh. The Homebrew addon is broken with update: false (the default!). It has been fixed for osx_image: xcode11 and newer, but the default image is older.
* Fix \kf speed in anamorphic videoOleg Oshmyan2020-10-271-1/+2
|
* Speed up macOS Travis CI buildsOleg Oshmyan2020-10-271-1/+1
| | | | | | | | | Updating Homebrew takes more than 5 minutes. Upgrading other things that depend on FreeType takes more than 6 minutes. Together, that's 11+ minutes of build time gone to waste. It seems Homebrew in the current default osx image has all the dependencies we need without needing to update.
* Fix two freshly introduced memory leaks upon alloc failureOleg Oshmyan2020-10-271-7/+10
| | | | | | | Found by Coverity Scan. Fixes CID 303760. Fixes CID 303761.
* process_karaoke_effects: honor info->skip in \kf calculationsOleg Oshmyan2020-10-271-2/+8
| | | | This mainly affects trimmed trailing whitespace.
* Improve \kf position roundingOleg Oshmyan2020-10-273-9/+9
|
* Fix shifted \kf position with rectangular \iclipOleg Oshmyan2020-10-271-0/+1
|
* Fix \kf fill positioningOleg Oshmyan2020-10-274-6/+41
| | | | | | | | | | | | | | | | | | Our effect_timing is currently used as a coordinate relative to a weird origin: take each glyph's center within the run, apply 3D transforms, pick the leftmost one, and round it down a little. This makes no sense and is the result of an unrelated code change. But if I recall correctly, \kf positioning was already incorrect before that last change (but in a different manner). To fix this and hopefully to prevent this kind of error from occurring again, convert effect_timing to absolute screen coordinate. Start the fill at the glyph run's leftmost post-transform control point. This matches VSFilter and allows karaoke to work in vertical text (unlike, for example, starting the fill at the first glyph's pre-transform origin). Fixes https://github.com/libass/libass/issues/216. Fixes https://github.com/libass/libass/issues/357.
* process_karaoke_effects: fill from right to left if rotatedOleg Oshmyan2020-10-271-0/+10
| | | | This matches VSFilter.
* Delay angle conversion to radians until the last momentOleg Oshmyan2020-10-272-8/+9
| | | | | This allows decisions based on the angle values to be slightly more accurate and might save us a few flops.
* Handle \k0 \ko0 \kf0 \K0 like VSFilterOleg Oshmyan2020-10-272-4/+16
| | | | | | | | | | | | | Don't break runs when zero-duration karaoke starts unless the karaoke *type* differs. The zero-duration karaoke block ends up glued to the previous block (if any). In case of subsequent karaoke override tags, like {\k100\k0}, the intervening tags will advance the next karaoke block's start time, but not this combined block's start or end time. Of course, runs may still be broken in the same place if there's another reason for a run break besides karaoke, so zero-duration karaoke blocks can still occur. Run breaks that have no karaoke tags at all also still produce zero-duration karaoke blocks (if there is karaoke at all).
* process_karaoke_effects: use long long for timestampsOleg Oshmyan2020-10-271-3/+3
| | | | | | | | Our frame timestamps are long long. Don't truncate them to int here. This also avoids overflow in (tm_end - tm_start) if \k... tag arguments are big, although, of course, parse_tags still reads them in as doubles to begin with and their conversion from double may still be undefined.
* process_karaoke_effects: compute \kf from glyph advances, not boundsOleg Oshmyan2020-10-271-6/+2
| | | | Both ways make sense, but traditional VSFilter does it this way.
* Drop the now-useless, previously-broken first_pos_xOleg Oshmyan2020-10-272-5/+2
|
* process_karaoke_effects: place line at infinity except during \kfOleg Oshmyan2020-10-271-9/+8
| | | | Fixes \k and \ko in https://github.com/libass/libass/issues/357.
* process_karaoke_effects: reuse \kf logic for \k and \koOleg Oshmyan2020-10-271-15/+10
|
* process_karaoke_effects: explicitly handle edge cases for \kfOleg Oshmyan2020-10-271-2/+8
| | | | | | | In particular, don't divide by zero given \kf0. This fixes https://github.com/libass/libass/issues/124. The order is important: \kf accepts negative values.
* process_karaoke_effects: honor starts_new_runOleg Oshmyan2020-10-272-7/+13
| | | | | | | | | | | This matches VSFilter. In particular, compared to what we did before, karaoke blocks additionally end when an override tag changes something, as well as on any line break (after the trimmed leading whitespace on the new line) and after any trimmed leading whitespace on the first line. The text that follows the break has a zero karaoke duration, and its karaoke effect starts immediately after the karaoke effect ends for the block before the break.
* process_karaoke_effects: give the code a facelistOleg Oshmyan2020-10-271-50/+38
|
* Remove unused rot_key functionOleg Oshmyan2020-10-271-6/+0
| | | | Unused since commit c80f332798238731e1ddf1b541748f3d5c8030f3.
* Avoid passing NULL as a %s parameterOneric2020-10-271-1/+7
| | | | | ass_msg's callback will most likely use vprintf. Passing NULL as %s to a _printf function is undefined behaviour.
* Handle strdup-fails regardinging FontFamilyOneric2020-10-272-9/+19
| | | | | | | We already ensure at creation that all styles have a non-null FontName. However font family strings are strduped at various places and NULLs cannot be fully avoided, since already the very first font strdup may fail, so additional checks are required.
* Check for strdup_failures in process_styleOneric2020-10-271-3/+12
| | | | | | | We can't parse the style without a valid style_format. If strdup for FontName or Name or there fallback values fails, the style is of no use, so discard it. As the removal happens before any other styles are added, just decreasing n_styles is safe here.
* Check for strdup failures in process_event_tailOneric2020-10-271-3/+5
| | | | | | | | | strdup failures for event->Text and event->Effect are already guarded against in ass_render.c and ass_parse.c. event->Name is never used, thus also safe. At this point event_format is guaranteed to be valid, so it doesn't need to be checked.
* Ensure track->event_format is valid before parsingOneric2020-10-271-4/+7
| | | | | In case of strdup-failure track->event_format can be assigned NULL in event_format_fallback or in process_events_line
* Make STRVAL macros strdup-fail safeOneric2020-10-271-4/+10
| | | | | | | | | | | Strictly speaking this is not neccessary in regular processing as the event and font fields are intialised with zeroes anyway and there's no old value to fallback too. However when processing style overrides, this can prevent a non-null value being replaced by NULL. This commit also gets rid of the unneccessary '!= NULL' check. Passing NULL to free is well defined and safe.
* Allocate and set default style directly at track creationOneric2020-10-271-21/+20
| | | | | | | | This way we can ensure that there's always one style in the track (which some parts of the code already assume) and that this style is actually valid. If the style alloc fails, the whole track alloc will fail and we're likely seriously short on memory anyway
* Handle realloc fail in process_fonts_lineOneric2020-10-271-13/+26
| | | | | | | | | | In case of files whose size is close to or exceeds SIZE_MAX it was possible to trigger an overflow while calculating new_size. Although ASS_REALLOC_ARRAY already deals with the most problematic case of an overflow yielding new_size == 0, continuing will only yield garbage fontdata at the end, so we might as well abort right away. Unrelated: correct return code for mangled lines
* parser_priv: Change type of fontdata_{size,used} to size_tOneric2020-10-272-7/+7
| | | | | | | | | | | | size_t is a more sensible type for as it is unsigned and accurately represents the theoretical limits of object size. int may be larger or smaller than size_t, which both would lead to problems and potential UB with signed overflow. There was no usage of negative values as error flags or similar and those two fields are not part of the public API, so this change should be safe. To stay consistent, also adjust types of related variables in functions.
* ass.c: handle style alloc failureOneric2020-10-271-2/+5
|
* ass.c: handle event alloc failsOneric2020-10-271-0/+4
|
* API: make ass_alloc_{style,event} alloc-fail safeOneric2020-10-272-14/+16
| | | | | | Also deal with potential overflows of style and event count. Since these fields are ints part ofthe public API, but will be cast to size_t in ASS_REALLOC_ARRAY use the smaller of both limits.
* Handle track alloc failure in parse_memory safelyOneric2020-10-271-0/+2
|
* doc: clarify docs regarding track creation and freeingOneric2020-10-272-4/+7
|
* coretext: return full/PostScript name on fallbackOleg Oshmyan2020-10-231-9/+16
| | | | | | | | | CoreText's "family name" can use TT_NAME_ID_TYPOGRAPHIC_FAMILY names, which we ignore for compatibility with VSFilter. As a result, fallback returns a family name that we then fail to find, and fallback fails. Return a fuller name (fullname or postscriptname as appropriate) instead, which should be more reliable.
* ass_render: Replace Segment with RectOneric2020-10-222-39/+34
| | | | | | | | | Contrary to what the comments suggest Segment does not use one absolute reference point and relative offsets, but two absolute points, making it practically identical to the previously defined Rect with a <-> y0, b <-> y1, ha <-> x0, hb <-> x1 For simplicity replace Segment with Rect.
* ass_shaper: remove dependency on hb-ftrcombs2020-10-221-3/+40
|
* ass_shaper: handle harfbuzz allocation failuresrcombs2020-10-221-14/+22
| | | | | | | | | Edit by Oleg Oshmyan <chortos@inbox.lv>: Move the final ass_shaper_shape returns inside the switch. Add a default case in ass_shaper_shape to proactively placate static analysers that might decide the switch is not exhaustive and we therefore don't return a value. We know it is actually exhaustive as we validate the shaper selection in ass_set_shaper.
* Return bool from ass_shaper_shapeOleg Oshmyan2020-10-223-6/+6
|
* Make harfbuzz a hard dependency; closes #199rcombs2020-10-225-59/+3
|
* ass_shaper_find_runs: don't decrement pointer beyond array startOleg Oshmyan2020-10-191-3/+5
| | | | That triggers undefined behavior.
* shape_harfbuzz: don't attempt to shape drawingsOleg Oshmyan2020-10-191-0/+5
|
* shaper: ensure drawings are in separate shape runs from textOleg Oshmyan2020-10-191-6/+5
| | | | | | | Previously, drawings would get shape_run_id = 0 from calloc. Most of the time, this separated them from text shape runs, but drawings immediately following the very first shape run would get appended to it. Make sure this cannot happen.
* shaper: don't mingle run ID and bidi embedding levelOleg Oshmyan2020-10-191-9/+6
| | | | | | | | | | | | | | | | | | | A libass-chosen shaping run boundary can coincide with a bidi embedding level boundary such that the differences in shaper_run_id and emblevel cancel out. For example: English עבריתEnglish again (with parentheses) (with no space after the Hebrew) has ass_shaper_find_runs split runs after the Hebrew, adding 1 to shape_run_id, while the RTL embed also ends in the same place, removing 1 from emblevel. As a result, two shape runs that should be separate merge together. In this example, this leads to HarfBuzz thinking that "English again (with parentheses)" is still right-to-left, so it flips the parenthesis glyphs. To avoid this, don't attempt to add these numbers together. Just require explicitly that both numbers stay constant, rather than their sum.
*