| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
We don't even use sudo since commit fb7731c85daccc635bf67608d3f8e45d9b61d578.
|
| |
|
| |
|
|
|
|
|
|
| |
There is a small typo in libass/ass_outline.h.
Should read `outline` rather than `ouline`.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This should make this a bit easier to understand and more readable.
Apart from comments nothing was removed or added, just reodered.
|
| |
|
|
|
|
|
|
| |
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)
|
|
|
|
|
| |
Both parameters are copied and are immutable. Make it clear through the
function prototype
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Found by Coverity Scan.
Fixes CID 303760.
Fixes CID 303761.
|
|
|
|
| |
This mainly affects trimmed trailing whitespace.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This matches VSFilter.
|
|
|
|
|
| |
This allows decisions based on the angle values to be
slightly more accurate and might save us a few flops.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Both ways make sense, but traditional VSFilter does it this way.
|
| |
|
|
|
|
| |
Fixes \k and \ko in https://github.com/libass/libass/issues/357.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Unused since commit c80f332798238731e1ddf1b541748f3d5c8030f3.
|
|
|
|
|
| |
ass_msg's callback will most likely use vprintf. Passing NULL as %s to
a _printf function is undefined behaviour.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
In case of strdup-failure track->event_format can be assigned NULL in
event_format_fallback or in process_events_line
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
That triggers undefined behavior.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
This removes duplicated code (and a not-fully-correct comment).
This also ensures shaping has breaks whenever the rest
of the pipeline breaks runs (e. g. for bitmap combining).
In particular, this adds missing breaks on karaoke changes,
which the old code didn't actually honor despite the comment.
|
|
|
|
|
|
|
|
|
| |
U+FFFC can not only come from drawings but also be actually contained
in the source text. In that case, handle it like any other character.
This doesn't distinguish source-text U+FFFC from drawings
whose strdup failed. But the whole rest of the pipeline
treats those drawings as plain U+FFFC characters, too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "bitmap runs" that are currently used only when combining bitmaps
are also relevant at other stages, mainly for VSFilter compatibility.
They are not currently used because this information is not available
until bitmap combining (except during shaping, which has its own "shape
runs" that duplicate a good chunk of the "bitmap run" logic).
Move some code around to compute run boundaries as early as possible.
This lays the f |