libass is a portable subtitle renderer for the ASS/SSA (Advanced Substation Alpha/Substation Alpha) subtitle format.

Last update: Dec 28, 2022

Overview

libass

libass is a portable subtitle renderer for the ASS/SSA (Advanced Substation Alpha/Substation Alpha) subtitle format. It is mostly compatible with VSFilter.

Get it

See GitHub releases for the latest release 0.15.0 (released 2020-10-27). See the changelog for a detailed list of changes.

Source code is available from our GitHub repository.

Contact

Please use the issue tracker to report bugs or feature requests. We have an IRC channel, too. Talk to us on irc.freenode.net/#libass.

Information about the ASS format:

Other ASS/SSA implementations:

VSFilter:
- xy-VSFilter/XySubFilter
  - pfmod
- VSFilter in MPC-HC
- VSFilterMod (with custom format extensions)
  - sorayuki fork with some bugfixes
- Threaded VSFilter (defunct)
- VSFilter in Guliverkli2 (defunct, subsumed by all of the above)
- VSFilter in guliverkli (defunct, forked as Guliverkli2)
ffdshow (defunct)
Perian
asa (defunct)
libjass (defunct)
ASS.js

Comments

fonts_dir on Windows skips fonts with file names that don’t start with ASCII

I always use mpv as the default player which use libass to render the subtitle. Usually, any fonts those which are put in the directory of the mpv/fonts/ will be correctly used by libass. However, some fonts whose name's first world is CJK cannot be loaded by libass.

For example, the font 中chinese.tff will not be loaded. But if I change its name to chinese中.tff , everything is OK.

The original issue posted in mpv project. https://github.com/mpv-player/mpv/issues/8639
windows

opened by hooke007 117
BitmapEngine refactoring + new assembly

This is a part of my version of the checkasm branch. I decided to split it into several PRs for ease of reviewing. This part is mostly preliminary refactoring.
performance cosmetic

opened by MrSmile 59
Help with integrating libass into Kodi

I am working on Kodi to convert current subtitles rendering to use LibAss here we have an option to force the subtitles to stay positioned e.g. below the video but I don't know how best to manage it with LibAss, i explain,

The subtitles parsers now generate each ASS_Event or if loaded as ASS/SSA use selective style override to change style, currently if a user choose to set subtitles on top or below i change the ASS_Style Alignment property. This works good, but, if a subtitle have overrides tag's like {\a5} etc... of course the subtitle will be moved in the specified position

how i can force to ignore all positions tags like {\a5}? or force in some way the rendering to not change position?

i have tried also ass_set_line_position but is not useful in this case
question

opened by CastagnaIT 48
font: use iconv to handle non-unicode cmap microsoft fonts.

To resolve #531. In case of non-Unicode cmap fonts, convert unicode code point(a UCS-4 code unit) to corresponding multibyte charset bytes, then assemble those bytes into a uint32_t, assuming those bytes present a prefix-zero-bytes-omitted big-endian integer. Freetype can make use of the converted code point to find correct glyph by non-Unicode cmap.

It introduces a dependency of libiconv. On Windows, WideCharToMultiByte is available to avoid libiconv if needed.

And I have just tested this patch on samples from #531 and #575, which covers BIG5 and SHIFT-JIS. For other encodings, I think it should work but I can't confirm. So further testing is needed.

#531 testing screenshot:

#575 testing screenshot:
enhancement compatibility fonts

opened by Apache553 45
Bidi bracket matching is VSFilter-incompatibile

I opened this issue in the MPV repo and was told to ask here if anyone knows why this happens.

Using MPV, The line should show up like this:

But the line shows up like this:

Here is a test file: Test.zip

Can anyone help me identify the problem? Thank you.
compatibility bidi

opened by OmrSi 35
Subtitles suddenly stop now and then

There's an anime I'm watching with SMPlayer (which is using libass). Now and then (often after the first half of the video) the subtitles are simply gone. However, when I then restart SMPlayer and rewind a bit the subtitles are often displayed correctly.

What information would you need to fix that? (or figure out if it's libass' fault)

opened by CreamyCookie 32
complex shaper: avoid font warning for non-printable codepoints
This was performed in two steps (commits):

Separate the non-printable simple-shaper detection into a stand-alone function.

Reuse this function by the complex shaper.
opened by avih 31
U+2060 (Word Joiner) warns "fontselect: failed to find any fallback for font: (sans-serif, 400, 0)"
I don't know if this is a libass issue or mpv issue, but I'd appreciate your help to recognize the source of the issue and/or the best way to address it.

Platform: Windows 10 mpv: master libass: d82f999 (2021-05-01)

Whenever mpv tries to display backslash at the OSD, the backslash IS displayed, but mpv prints a warning.

Steps to reprodue:

run mpv --no-config --force-window --idle

press tilde/backtick at the window to open the internal console

type show-text foo\bar and press enter (the backslash is correctly taken literally - that's how mpv parsing works)

Result: foo\bar is displayed at the OSD, and the terminal displays

[osd/libass] fontselect: failed to find any fallback for font: (sans-serif, 400, 0)

I tried other fonts by adding to the mpv command line e.g. --osd-font=Arial or --osd-font="Comic Sans MS" - with same warning except the different font name at the message (the display font does change visibly).

mpv does escape \ internally by default for any OSD text by appending U+2060 right after it so that libass doesn't recognize it as a begining of an ass sequence, via this code: https://github.com/mpv-player/mpv/blob/dd4d239bcb151b08eb81b38486515a3e1222e1f5/sub/osd_libass.c#L223-L225

If I change 0x2060 (Word Joiner) to 0x200B (Zero Width Space) then it seems to behave the same but without the warning - i.e. this seem to fix the issue.

So I have few questions:

It seems to me that libass tries to find the glyph for U+2060 and fails. Is this a correct behavior? Are fonts expected to have a glyph for this codepoint?

For escaping \ in strings, which should be more correct to use between U+2060 and U+200B ? (i.e. should we change mpv to use U+200B?)

If we do change mpv to use U+200B, could any issue arrise with older versions of libass which would be avoided with U+2060?

Thanks in advance.
shaper
opened by avih 31
Fix wrong font name used when searching in-memory fonts
use font->desc.family to search in-memory fonts, otherwise the font will never be found

pass 0 for face_index to FT_New_Memory_Face, otherwise the call may fail with Invalid Argument error in FreeType

invalid fonts
opened by pkoshevoy 31
directwrite: fix `match_fonts`

match_fonts is supposed to add all the fonts with the same family name for fontselect. The previous PR adds only one font, which leads to font with multiple styles cannot be correctly selected.
fonts regression windows

opened by Apache553 29

Building ASM on OpenBSD and NetBSD errors on -fPIC being passed to NASM

I have had the ASM disabled in the OpenBSD port for quite awhile as I couldn't get it to build. I tried again with 0.15.1, but it is still not building Ok.

I am looking around with libtool trying to figure out where the -fPIC -DPIC was added. It's the -fPIC that is causing the error.

/usr/local/bin/libtool  --tag=CC --mode=compile nasm -DARCH_X86_64=1 -f elf64 -Dprivate_prefix=ass -I./ -o x86/rasterizer.lo x86/rasterizer.asm -prefer-non-pic
libtool: compile:  nasm -DARCH_X86_64=1 -f elf64 -Dprivate_prefix=ass -I./ x86/rasterizer.asm  -fPIC -DPIC -o x86/.libs/rasterizer.o
nasm: fatal: unrecognised output format `PIC' - use -hf for a list
Type nasm -h for help.

build

opened by brad0 28

Style names should preserve trailing spaces

Screenshots

VSFilter

Libass

Description of the issue

Libass use the style ***Example, but VSFilter use the style Default.

Warning, if you open the file with Aegisub, you won't see any issue, because it seems that it automatically trim space of the style name when you open an .ass file. So you will need to edit the style ***Example and add space at the end of it.

I am not sure, but I think VSFilter parse the stylename like that: https://sourceforge.net/p/guliverkli2/code/HEAD/tree/src/subtitles/STS.cpp#l1447

libass version

0.16.0

Is it a regression?

No response

ASS Sample

[Script Info]
; Script generated by Aegisub 9513-feature-042b7e1be
; http://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 0
ScaledBorderAndShadow: yes
YCbCr Matrix: None
PlayResX: 720
PlayResY: 480

[Aegisub Project Garbage]
Last Style Storage: Default
Video File: ?dummy:23.976000:10000:720:480:16:145:190:
Video AR Value: 1.500000
Video Zoom Percent: 1.500000

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,35,&H0011FF00,&H000000FF,&H002C2C2C,&H00000000,-1,0,0,0,100,100,0,0,1,2.5,0,2,0,0,72,1
Style: ***Example     ,Arial,48,&H000000FF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,2,2,10,10,10,1

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:05.00,Default,,0,0,0,,{\rExample}Example

Special Fonts

The issue doesn't depend on a specific font

System Information

No response

Log

No response

Additional info

No response

compatibility

opened by moi15moi 2

Checkasm v2
Leftover from my checkasm branch. Changes from my previous version:

updated to current dav1d source (readtime for macos is already there, so one less thing to worry);

simplified rasterizer check (no copy-paste from actual rasterizer code).

As for BENCH_RUNS count, I feel that it's not enough: even with (1 << 16) and rdtsc from x86 there's quite large variation in results. I think the whole timing logic should be modified. Currently it's

uint64_t tsum = 0; int tcount = 0; for (int ti = 0; ti < BENCH_RUNS; ti++) { uint64_t t = readtime(); test_func(...); test_func(...); test_func(...); test_func(...); t = readtime() - t; if (some_black_magic) { tsum += t; tcount++; } }

Basically, it's 4 inner timed iterations plus BENCH_RUNS outer iterations with "clever" averaging of the results (skipping of some partial timings). I think the following would be more stable, but I've not checked it yet:

uint64_t tmin = -1; for (int to = 0; to < OUTER_RUNS; to++) { uint64_t t = readtime(); for (int ti = 0; ti < INNER_RUNS; ti++) { test_func(...); test_func(...); test_func(...); test_func(...); } t = readtime() - t; if (t < tmin) tmin = t; }

Another point of concern is ABI check for aarch64[_be] (checkasm_stack_clobber(), checked_call(), etc.). It's explicitly disabled for macos and it's crashing under aarch64_be NetBSD from earlier. It's quite useful to disable completely, so I think I should look into it and try to understand what's going on there.
opened by MrSmile 3
Support Banner/Scroll effects’ fadeawaywidth/height gradient
Guide to reviewing the commits:

The first commit lays down some foundation and implements an integer-only gradient. If you’re not interested in the integer-only gradient specifically, feel free to skip the gradient arithmetic in your initial review.

The third commit implements a mathematically sound floating-point gradient, the “sanest” variant. This can/will be squashed into the first commit if we settle on a floating-point variant, completely replacing the integer-only code.

The fourth commit is a small but icky patch to get us closer to DirectShow VSFilter if we think that’s useful. We can decide to drop this.

There are several bikesheds to be coloured here:

Should the gradient be implemented as the splitting of ASS_Images with tweaked ASS_Image alphas (as the proposed code does) or by pre-multiplying the backing bitmap(s)?

VSFilter does the latter. But this is a scrolling event, so (unless it’s scrolling reaaaally slowly, which may be used to emulate a stationary gradient) this can’t be cached and the whole bitmap needs to be redone on each frame. Plus, we’d need either to allocate and fill a separate bitmap for the gradient to use mul_bitmaps on it (VSFilter does this) or introduce a special-purpose multiplier routine for this, which we’d probably like to have an assembler-language implementation for (which someone would have to create).

Splitting ASS_Images lets us forego any bitmap multiplications and allows bitmap reuse (though reuse can still be limited due to subpixel shifts during the scrolling), but it requires more ASS_Image allocations and breaks those API consumers that use ASS_Images to estimate event bounding boxes.

How stable should the output be on changing display resolution, and how close should it be to VSFilter’s?

I initially offer three variants in this PR. One is a stupid simple implementation, much of the same kind of stupid as in VSFilter and matching it somewhat but not fully, and technically moving by sub-pixel amounts as display resolution is changed. Another is a mathematically ideal variant that to me is the most intuitive thing an author would expect from fadeawayheight/width without knowing how any implementation actually does it. The third is a mathematically exact replica of traditional VSFilter’s gradient position, but I didn’t replicate the bad rounding of values (which in some sense shifts the gradient further), so I’m not entirely sure how this even helps. I can add that if desired, though.

I haven’t had much luck imagining situations where a carefully crafted script might be significantly affected by these differences. But I haven’t tried looking for real examples, either. Theoretically, a script might use these effects to achieve a colour gradient.

For reference, VSFilter’s rounding errors on values:

It computes the gradient step as floor(2¹⁴ / gradientWidthOrHeightInDisplayPixels) and repeatedly adds this (starting from fully transparent) for the leading gradient or subtracts this (starting from fully opaque) for the trailing gradient, accumulating/multiplying the error caused by the floor. As a result, the leading gradient never quite smoothly reaches 1, and the trailing gradient never quite smoothly reaches 0; and the higher the resolution, the worse it may get.

It computes the final opacity as floor(opacity × gradient / 2¹⁴). And the opacities are in the range 0–64, so even this floor alone is worth up to ¹⁄₆₄ ≈ ⁴⁄₂₅₅. The leading gradient in particular might thus appear to originate another few pixels beyond the designated point.

I’ve noticed the rounding of \clip(,,,) coordinates is different among the various renderers. Do we or do we not want to align this to any particular VSFilter flavour, or perhaps independently improve our own?

enhancement compatibility
opened by astiob 5
Support Core Text on Mac OS X 10.5 and prerelease 10.6

This should fix #595 and further make the Core Text system font provider usable on Mac OS X 10.5 “Leopard”—because why not?

@TheOneric Do we have any tests on PostScript-name vs full-name font selection? Looks like not? I don’t think it’s in any way urgent or a blocker for this, but at some point we probably should add some. And it would be great to have some tests targeting specifically system font providers, although I’m not quite sure how we could do that.
fonts macos

opened by astiob 3
$Support \fe aka font Encoding in Style$
Support \fe aka font Encoding in Style
This would fix https://github.com/libass/libass/issues/233.

This would fix the sample in https://github.com/libass/libass/issues/618#issuecomment-1114100911 as soon as that issue itself is also fixed.

This would break the more modern sample in https://github.com/clsid2/mpc-hc/issues/1799.

This would break all FFmpeg-generated ASS naming fonts that lack Western European coverage (or rather, don’t declare it), because FFmpeg sets Encoding=0. And depending on how far we take this, it might lessen the prettiness of those FFmpeg-generated files that do name Western European fonts but use characters that require font fallback.

This may or may not break some Crunchyroll-sourced samples. Reportedly, some use Encoding=1 but some do use Encoding=0, including at least one in Arabic, but the font in that particular known sample continues to work fine even if the Encoding=0 is enforced.

\fe and the Style Encoding field sounds scary but is actually very simple in concept:

Each font declares what legacy Windows code pages it has adequate glyph coverage for. All \feX means is: “If X≠1, avoid selecting fonts that lack the coverage for code page X.” When X isn’t a valid enum value, no font matches, so a system-default fallback seems to be used.

No input byte transcoding. No font transcoding. No relation to cmaps or font name encodings. Just check a flag and ignore the font if it’s unset.

It’s not immediately clear if we actually can do this: if the named font doesn’t exist or lacks the specified code page, the very point is to select a fallback that has it. But that means either we’d need to be able to ask the system font provider to do this kind of filtering for us, or we’d need to load all of the system’s fonts, which we generally want to avoid for performance reasons. Maybe we need built-in, hard-coded fallback lists for each code page. (Having them could also fix #42.)

The valid values are best described here. The structure that VSFilter puts this value into is described here.

Of special note, the value is a BYTE and 255 is a valid value (OEM_CHARSET). And libass uses Encoding=-1 as an extension. I haven’t verified, but I’m fairly sure this means our Encoding=-1 is getting interpreted by VSFilter as OEM_CHARSET and limiting the font choice to only those that support OEM charsets. Which, for instance, the Arabic font in that MPC-HC issue doesn’t support, whereas Encoding=-1 is mainly used for right-to-left languages like Arabic. We’d need to special-case -1 and treat is like +1 (no charset-based filtering).

TrueType fonts typically contain an OS/2 table, which we already use to determine things like the font size in a VSFilter-compatible manner. That same table also contains a “Code Page Character Range” bitmap field that declares what legacy Windows code pages (character sets, encodings) the font promises to have comfortable glyph coverage for. For example, a font that has Arabic glyphs sets the Arabic code-page bit. You can easily view and edit these bits in FontForge (Element → Font Info... → OS/2 → Charsets → MS Code Pages). I believe this is the main source of information that GDI converts via some conversion lookup table to the FOO_CHARSET enum.

Except it seems like GDI may synthesize charsets for some fonts that have some particular glyphs. And have special handling for broken Japanese fonts. But maybe current-millenium fonts declare the right charsets anyway and we can live happily without these special cases.

I’m not sure whether PostScript-outline OpenType fonts use any different logic.

For font fallback, we might want to convert \fe into a language/locale (see also: https://github.com/libass/libass/issues/550), especially if GDI limits glyph-substitution fonts to the requested charsets (to be confirmed).

When we fail to find any font with the requested charset, presumably we want to just ask for fallback and accept anything that we get back. Indeed, this is what seems to happen in VSFilter when I try the invalid \fe123.

Regardless of \fe, we may have another reason to read the OS/2 code page bitmap: it may be what GDI uses to decide which TrueType fonts are allowed to be @-prefixed. More research needed.

See also:

https://github.com/clsid2/mpc-hc/issues/1799 (mentioned above)

https://github.com/Aleksoid1978/MPC-BE/issues/28

where MPC-HC’s and MPC-BE’s internal subtitle renderers were changed to ignore \fe because libass did so. MPC-HC’s was later changed to only ignore \fe0 but honour other values. Ideally, this change might be coordinated so that we don’t end up with libass now applying it but the MPCs continuing to ignore it.
compatibility fonts
opened by astiob 1
Rerun shaping & bidi after/during line wrapping
Just noting this in a new issue so this isn’t completely forgotten. Originally mentioned in https://github.com/libass/libass/pull/372#issuecomment-586600123 and in https://github.com/libass/libass/pull/441.

We run the Unicode bidirectional algorithm and perform shaping before wrapping lines. This is inevitable, because we can’t measure line width before we shape and we can’t shape without knowing where direction changes occur.

But when we do wrap a long line, the line break can be (and most often is) in the middle of a shaping run, and the glyph shapes before and after the line break may no longer be correct. For example, if Unicode-based line breaking is enabled and the source text contains f <zero-width space> i i or f <soft hyphen> i i set in a font with ligatures, we detect the break opportunity at the ZWSP or SHY, but because the fi have fused into a ﬁ ligature, we end up displaying ﬁ <line break> i rather than the expected f <line break> i i.

Meanwhile in VSFilter-compatible mode, we only wrap on plain spaces so shaping is less likely to be affected per se, but then each line needs to have the bidirectional algorithm run on it in isolation (with all embedding reset, etc.) whereas we keep the pre-wrapping directional information. (And rerunning bidi means we may also need to reshape.)

The difficulty is that

after reshaping the split lines, we may find that their widths have changed so much that we want to change our choice of break points;

and rerunning bidi and shaping too many times seems like it could be slow.

shaper
opened by astiob 0

Releases(0.17.0)

0.17.0(Nov 30, 2022)
This release’s major feature is the addition of a new ASS ScriptInfo header pair: LayoutResX and LayoutResY. The introduction has been coordinated with active VSFilters and will soon be available in xy-VSFilter and XySubFilter as well. Since the beginning, many features in ASS scale relative to or are otherwise affected by the storage resolution of the video file the subs are bundled with. Adjusting subs for different video resolutions traditionally took non-trivial effort. Of course this behavior must be kept by default to preserve compatibility with existing files. But now, setting both of the new headers to a positive, non-zero value will replace the video storage resolution with the specified resolution for the whole file, allowing easy reuse across all encodes of the same display aspect ratio. This includes PAR effects, so reuse across anamorphic and non-anamorphic releases is possible too.

Apart from that, some notes for package maintainers:

for ASS_FEATURE_WRAP_UNICODE to be usable at runtime, libass must be linked against the new optional dependency libunibreak whose source currently resides at https://github.com/adah1972/libunibreak

switching to a non-recursive build means it is no longer possible to invoke make in subdirectories. However this wasn’t really useful anyway and everything else, including uninstalled binary locations, was kept unchanged.

reminder: as announced last release more keys are now authorized for signing release tags and tarballs; a signature of any one of those keys is sufficient. See the MAINTAINERS file in the last or this release’s tarball for a complete list and more details.

Detailed Changes:

Fix various parts relating to automatic linebreaking

Fix rendering when hinting was enabled and fontsizes or scales are zero

Switch build to a non-recursive setup for improved parallelism

Improve quality of SSA Effects movement

Further documentation improvements

Completely invalid Events are now discarded during parsing

Introduction of LayoutRes{X,Y} script headers

New AlphaLevel style override to set all alpha values while keeping the color

Add ASS_FEATURE_WRAP_UNICODE to allow automatic linebreaks in accordance with the Unicode line breaking algorithm instead of ASS' much stricter breaking rules. For the feature to be available at runtime, libass must be linked against the new optional dependency libunibreak.

Improve VSFilter compatibility:

Fix premature truncation of animated alphas (was a 0.15.0 regression)

Fix handling of small delay parameters for legacy SSA Effects

Fix x-scaling with PlayResX

Fix x-scaling for anamorphic video (except for \be whose scaling remains buggy in general)

Support SSA's AlphaLevel style field

Support the \kt override tag from VSFilter's v4++ set

Parse ScriptType headers

Parse integer header, style and event field values like VSFilter

Ignore trailing whitespace in an event's text

Source code(tar.gz)
Source code(zip)
libass-0.17.0.tar.gz(559.13 KB)
libass-0.17.0.tar.gz.asc(833 bytes)
libass-0.17.0.tar.xz(394.31 KB)
libass-0.17.0.tar.xz.asc(833 bytes)
0.16.0(May 12, 2022)
This release brings a new ASS_FEATURE_WHOLE_TEXT_LAYOUT API toggle, brings an important API change on (only) Microsoft’s Win32 platform to enable arbirtrary paths to be used rather than only ANSI ones, fixes an incompatibility with FreeType versions >= 2.11.1 on Win32 and brings many more bug and compatibility fixes as well as other improvements.

API users are highly encouraged to pay special attention to the following points:

The documentation has been expanded and multiple errors in it have been fixed. It may be worthwhile to reread the documentation for all functions you are using (or all of it). If you still have questions afterwards or spot an error, please contact us so the docs can be further improved.

For those on Win32 only (other platforms do not require special handling of the path’s encoding):

The new support for arbitrary paths via the new dual encoding used in the majority of our API is mostly backward compatible, i.e. continuing to use fopen ANSI paths works mostly as well (or bad) as before except when there are actual on-disk name collisions. However, the other way around, using the new encoding with older libass binaries, will in general fail unless the paths happen to be pure 7-bit US-ASCII.

If you want to make use of arbitrary paths but also wish to continue to support older libass versions, you should continue to always use the fopen encoding if ass_library_version() < 0x01502002.

Technically, this should be accompanied by an increase in the minor soname version, but there is none because the change is Win32-specific and the minor soname version is not even used by the dynamic linker in common MS Windows setups.

Detailed changes:

Fix missing -framework options in libass.pc on macOS

Fix missing GDI or DirectWrite options in libass.pc on Win32

Fix crashes with fonts missing Postscript names and without one being synthesised by the font provider

Fix crashes on negative fontsizes and some overflows

Fix a rare memory leak introduced in 0.13.0

Fix minimum dependency versions in configure and our pc-file

Fix our public headers for use with GCC versions between 3.1.0 and 4.5.0 (was a regression introduced in 0.15.0)

x86: Fix potential buffer over-read by 16 bytes with AVX2 assembly when large tiles are not enabled (the default)

x86: Fix PIC flags not being interpreted by the assembler, breaking the asm-enabled build setup on NetBSD and OpenBSD. On 32-bit x86, if the toolchain requires PIC objects and relies on compiler defaults to get PIC implicitly, you need to pass --with-pic to configure to ensure NASM always produces PIC objects

x86: Fix AVX support not being detected on non-Intel CPUs and some VMs

x86: Fix CPUID being used on CPUs not supporting the instruction (<= i486) and the way it is used for CPUs with less than 7 CPUID-leafs which could lead to crashes due to illegal instructions

MS Windows-only issue: Fix crashes with FreeType >= 2.11.1 on Win32 when rendering strikethrough or underline

Improve \iclip quality

Improve quality of very small outlines

Switch to wyhash for much better cache performance

Propagate ZWJ/ZWNJ effects across glyph run boundaries

Do not depend on compiler-specific defines to actually use built assembly

Expand documentation and fix mistakes in it

configure now errors out if an explicitly requested feature is unavailable

MS Windows-only issue: ease linking against static/shared GNU FriBidi

Add ASS_FEATURE_WHOLE_TEXT_LAYOUT to apply bidi, shaping and \fay to the entire unsplit event text. The non-portable Encoding=-1 mode always behaves as if the feature were enabled

MS Windows-only issue: add support for arbitrary Unicode paths; see documentation of related functions for details

Improve VSFilter compatibility

Do not treat format lines using Actor in place of Name as custom format lines. The former is used by VSFilter itself, the latter by Aegisub

Run bidi and shaping on each glyph run separately by default

Match VSFilter’s \fsp effects on bidi and shaping

Match VSFilter’s \fay behaviour

Support non-Unicode font cmaps when Win32 API or iconv is available and can convert to the relevant encoding

Treat empty clip outlines as if everything was outside the clip not inside (was a 0.14.0 regression)

Parse integer parameters of override tags more like VSFilter

This release is signed by the same OpenPGP key as the 0.15.x series of releases. Future releases may be signed with other keys listed in the new MAINTAINERS file.
Source code(tar.gz)
Source code(zip)
libass-0.16.0.tar.gz(538.08 KB)
libass-0.16.0.tar.gz.asc(228 bytes)
libass-0.16.0.tar.xz(387.01 KB)
libass-0.16.0.tar.xz.asc(228 bytes)
0.15.2(Sep 12, 2021)
This is a 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.

Changes:

Fix some known 0.15.x regressions:

Fix Core Text font fallback failing on some fonts with multiple names

Fix DirectWrite failing to look up any but the first loaded variant of system fonts

Fix some format string bugs, which could lead to garbled log messages or on some platforms crashes

Fix ass_set_fonts_dir failing to load long paths

Better handling of control characters that have no associated font glyphs

DirectWrite: font lookup is now closer to VSFilter

DirectWrite: this font provider can now be built for UWP

Source code(tar.gz)
Source code(zip)
libass-0.15.2.tar.gz(519.06 KB)
libass-0.15.2.tar.xz(373.08 KB)
0.15.1(May 2, 2021)
This is purely a bug fix and polish release, with no significant API or ABI changes.

The only API change is that ass_add_font is now declared to accept const char *. Previously it took only char *, but const has worked in practice since the very first standalone libass release.

Fix currently known 0.15.0 regressions:

Fix crashing on some ASS files with embedded fonts

Fix total font fallback failure with some fonts on Core Text

Fix embedded and memory fonts not actually being used unless ass_set_fonts was called after they have been added

Fix events assuming the largest xbord-value of a preceding event of the same frame during collision handling

Fix \fscx0 and \fscy0 making more text disappear than they should

Fix shift in vertical positioning of some right-to-left events with \an4-6, \pos, \move or Scroll effects

Fix imprecise output for \be with huge argument

Fix the --enable-large-tiles configure switch doing nothing

Fix output of ASM-enabled builds deviating from non-ASM builds

Fix ASM-builds on Haiku and 32-bit *BSDs

Overhaul x86 assembly for better performance and to allow ASM-enabled PIC-builds on 32-bit

Reduce temporary allocation in rendering

DirectWrite: request fonts on demand for better performance and improved compatibility with external on-demand font activation

Log libass version numbers upon renderer startup

Accept pointers to const as arguments to ass_add_font

Improve VSFilter compatibility:

Disregard zero area events in collision handling

Do not apply \fsp to vector drawings

Fix bug preventing cutting out glyphs from border & shadow with abnormal \fad values (or causing aliasing artifacts in some cases with normal values)

Source code(tar.gz)
Source code(zip)
libass-0.15.1.tar.gz(525.23 KB)
libass-0.15.1.tar.xz(361.21 KB)
0.15.0(Oct 27, 2020)
Boo! Three long years in the making due to large internal changes, this long-awaited release brings bug fixes, speed, and a new mechanism for opting into VSFilter-incompatible features:

Fix backwards/VSFilter-incompatible font sizes with FreeType 2.10+

Improve speed via better caching

Require HarfBuzz unconditionally to ensure good shaping for complex scripts

ass_set_use_margins(true) now simply places text on the whole screen instead of attempting to tie it to video positioning (set by the margin values) and failing in various ways when margins are used to implement pan & scan in a video player

Add ass_track_set_feature() & catch-all ASS_FEATURE_INCOMPATIBLE_EXTENSIONS

Add ASS_FEATURE_BIDI_BRACKETS to enable Unicode 6.3+ bracket matching when applying the Unicode Bidirectional Algorithm (incompatible with VSFilter; requires libass built with FriBidi 1.0+)

Fix stack overflow on deeply nested \t tags

Fix positioning of events with leading line breaks

Fix small but nonzero \bord becoming \bord0 (regression in 0.14.0)

Measure BorderStyle=4 box padding from glyph border, not from glyph fill

Scale everything from script resolution if storage size is not set (including borders and shadows regardless of ScaledBorderAndShadow)

Fix the default aspect ratio calculation when neither ass_set_pixel_aspect() nor ass_set_aspect_ratio() is called

Multiple fixes for karaoke override tags

Handle memory allocation failures better: avoid some crashes and produce images closer to truth

Avoid some integer overflows

Add internal infrastructure for regression testing

Improve VSFilter compatibility:

Treat invalid nested \t tags like VSFilter

Make \t(T,T,...) at time exactly T use the post-transition values

Make lines stack more like they do in VSFilter

Default ScaledBorderAndShadow to 0 (like VSFilter), except for subtitles that were produced by old FFmpeg/Libav

Make shadow positioning with 3D transforms match VSFilter’s

Cut out glyphs from border & shadow in all the same cases as VSFilter

Match VSFilter on animated color tags with negative acceleration

Fix parsing of some files that VSFilter accepts but libass didn’t by ignoring leading whitespace in each line of an ASS file or CodecPrivate

Improve font selection with CoreText

Stop faux-bolding fonts that are too bold to get faux bold in VSFilter

Ignore leading/trailing spaces when calculating height of nonblank lines

Match VSFilter on \fade with large alpha value arguments

Stop splitting bitmaps on font substitution

Multiple fixes for Banner and Scroll effects

Multiple fixes for karaoke override tags

Source code(tar.gz)
Source code(zip)
libass-0.15.0.tar.gz(525.12 KB)
libass-0.15.0.tar.xz(359.22 KB)
0.14.0(Oct 31, 2017)
Brand new, faster and better outline stroker (replaces FreeType stroker)

Remove option to use the FreeType rasterizer

Fix spots of missing border around self-intersecting shapes

Switch from Yasm to NASM for building hand-written assembler code

Support Core Text font provider on Mac OS X 10.6 and 10.7

Clear font cache in ass_set_fonts(). This fixes potentially incorrect font choices and an occasional crash if this function is called midway through rendering a file.

Source code(tar.gz)
Source code(zip)
libass-0.14.0.tar.gz(485.69 KB)
libass-0.14.0.tar.xz(347.90 KB)
0.13.7(Jun 3, 2017)
Fix invalid memory accesses with BorderStyle=4

Fix change detection bug on frame resizes

Fix cache bugs with border size

Reduce precision of border width in font outline caching

Don't treat :;<=>? as hexadecimal digits in color headers

Fix parsing of unusual Alignment values in ASS style definitions

Fix potential truncation in timestamp parsing

Treat negative PlayResX/PlayResY like VSFilter

Fixes to parsing of embedded fonts

Remove arbitrary bitmap limit (fixes issues with subtitle rendering at 4K)

Allow using shadow offset to adjust size of background with BorderStyle=4

Fix TrueType/OpenType font collection handling with the DirectWrite backend

Source code(tar.gz)
Source code(zip)
libass-0.13.7.tar.gz(505.76 KB)
libass-0.13.7.tar.xz(344.48 KB)
0.13.6(Jan 3, 2017)
Add Justify style override that changes text justification (left/right/center) without affecting event positioning. This breaks ABI compatibility with prior releases.

Fix ass_set_cache_limits() to affect total bitmap cache size including composite bitmap cache.

Number parsing fixes

Fix illegal read when parsing some numbers in scientific notation with huge exponents.

Correctly evaluate numbers in scientific notation with large exponents.

Correctly evaluate numbers with many leading zeros.

Bug fixes found with fuzzing

Fix a small memory leak in the parser.

Fix illegal read in the parser on specially crafted input with \t tags.

Note: this is functionally equivalent to release 0.13.5, but the libtool version number has been increased to account for the ABI break.
Source code(tar.gz)
Source code(zip)
libass-0.13.6.tar.gz(477.17 KB)
libass-0.13.6.tar.xz(341.93 KB)
0.13.5(Jan 3, 2017)

Do not use this release. Use 0.13.6.

This release breaks ABI compatibility, but the libtool version number does not reflect this. Instead, use 0.13.6, which bumps the libtool version number. If you rather need ABI compatibility with releases 0.10.2 to 0.13.4, use 0.13.4.

See the change log for release 0.13.6.
Source code(tar.gz)
Source code(zip)
0.13.4(Oct 4, 2016)
Bug fixes found with fuzzing

Fix memory reallocation in the shaper. (CVE-2016-7972)

Fix two small memory leaks in the parser and test program.

Fix illegal read in Gaussian blur coefficient calculations. (CVE-2016-7970)

Fix mode 0/3 line wrapping equalization in specific cases which could result in illegal reads while laying out and shaping text. (CVE-2016-7969)

Source code(tar.gz)
Source code(zip)
libass-0.13.4.tar.gz(508.24 KB)
libass-0.13.4.tar.xz(342.61 KB)
0.13.3(Sep 24, 2016)
Improve compatibility/portablility of build system, should fix e.g. compilation on Solaris.

Fix memory leak in DirectWrite font provider.

Fix the rasterizer when rendering some large outlines.

Remove hack that forced RTL base direction depending on font encoding.

Greatly improve the internal caches with refcounting and gradual clearing.

Source code(tar.gz)
Source code(zip)
libass-0.13.3.tar.gz(503.50 KB)
libass-0.13.3.tar.xz(342.78 KB)
0.13.2(Feb 20, 2016)
Add ass_set_check_readorder() API function to disable use of the ReadOrder field for duplicate checking in ass_process_chunk().

ass_step_sub(track, now, 0) now finds the start of the subtitle at now.

Bug fixes:

Fix an issue with the new duplicate checking, which could lead to missing subtitles after seeking.

Fix a crash with Core Text under specific circumstances.

Source code(tar.gz)
Source code(zip)
libass-0.13.2.tar.gz(474.04 KB)
libass-0.13.2.tar.xz(340.27 KB)
0.13.1(Dec 1, 2015)
Much faster duplicate event check in ass_process_chunk. This can bring a large speedup for embedded subtitles with lots of events. To make this possible, it is now forbidden to combine calls to ass_process_chunk with any other method of manipulating the event list, namely, manual manipulation and calls to ass_process_data, ass_read_memory and ass_read_file.

Interpret negative timestamp components as actual negative numbers. This change increases compatibility with VSFilter.

Font matching changes for VSFilter compatibility

Look up fonts that contain PostScript outlines by their PostScript name instead of their full names. Family names continue to be used for all fonts.

Keep spaces in font names

Drop support for Fontconfig < 2.10.92 to ensure correct font matching

Bug fixes

Fix building the assembler code for the x32 ABI (GH #200)

Fix static linking against libass through pkg-config when libass uses libiconv

Fix some small memory leaks, potential crashes and bad data uses

In this release only, an old version of GNU Libtool is used in the release tarball, leading to problems building shared libraries for Windows. This is fixed in 0.13.2. This does not affect building from Git.
Source code(tar.gz)
Source code(zip)
libass-0.13.1.tar.gz(431.67 KB)
libass-0.13.1.tar.xz(311.36 KB)
0.13.0(Oct 3, 2015)
Add native font selection backends for OSX (CoreText) and Windows (DirectWrite). You can now run libass without fontconfig on these platforms. This fixes problems with fontconfig behaving badly on these platforms (it could take minutes to scan all system fonts). Even on Linux, this speeds up loading of embedded fonts (such as provided by ass_add_font()). The DirectWrite backend only works on Windows Vista and later. On XP, fontconfig is still needed. libass can be compiled with both DirectWrite and fontconfig, and then it will fallback to fontconfig automatically if DirectWrite is not available at runtime.

Add ass_get_available_font_providers() API function.

Change the 4th parameter of ass_set_fonts(). This now selects the font provider. This is somewhat backwards compatible with the old behavior, but if you ever passed values other than 0 or 1, your application might break with this libass release.

The ass_fonts_update() function now does nothing. It's kept for backward compatibility only.

Much faster gaussian blur. This can bring a large speedup with big blurred signs and such.

Drop ENCA support

Bug fixes

Fix compilation of the freetype rasterizer (disabled by default)

Fix rendering with some cases of consecutive line breaks (\N\N).

Fix some memory allocation failure checks

Avoid system locale dependent behavior by reinventing some standard C functions

Fix rendering errors with strikes (GH #193)

MSVC compilation fixes

Source code(tar.gz)
Source code(zip)
libass-0.13.0.tar.gz(476.63 KB)
libass-0.13.0.tar.xz(328.25 KB)
0.12.3(Jun 30, 2015)
VSFilter blur compatibility changes

VSFilter color/alpha parsing compatibility changes

Bugfixes

Fix some potential memory leaks and crashes

Fix large timestamps (larger than about 600 hours)

Fix a potential crash with the new rasterizer and complex fonts

Do not apply user-configured line position to non-dialog events

Strictly clip non-dialog events to the video rectangle

Source code(tar.gz)
Source code(zip)
libass-0.12.3.tar.gz(445.06 KB)
libass-0.12.3.tar.xz(306.49 KB)
0.12.2(May 7, 2015)
Add extern "C" guards to the public headers for C++ compatibility

Improvements to style override API and implementation

Bugfixes

Fix some rasterizer bugs of unknown severity

Fix a broken memset() of unknown severity

Make timestamp parsing more lenient, which makes libass accept invalid files accepted by most other ASS parsers

Increase compatibility with broken ASS drawings accepted by VSFilter

Source code(tar.gz)
Source code(zip)
libass-0.12.2.tar.gz(443.43 KB)
libass-0.12.2.tar.xz(305.86 KB)
0.12.1(Jan 7, 2015)
Make ASS drawings with an extremely high number of control points work
This change increases compatibility with VSFilter.

Bugfixes

Fix a crash when using newer harfbuzz versions (GH #155)

Load embedded memory fonts correctly

Large shadow offsets rendered incorrectly (GH #142)

Fix incorrect closing of last drawing contour

Fix issues with undefined behavior in shifts

Lots of of malloc() error checking

Source code(tar.gz)
Source code(zip)
libass-0.12.1.tar.gz(424.83 KB)
libass-0.12.1.tar.xz(304.70 KB)
0.12.0(Oct 22, 2014)
Implement fast quad-tree rasterizer in C and SSE2/AVX2 assembly

Make \be animatable

Add BorderStyle=4 (GH #105)

Add selective style override functionality

ass_set_selective_style_override()

ass_set_selective_style_override_enabled()

Support for assembly on DragonFly BSD

Bugfixes

Various parser fixes

Fix premature parser exit on }{ in drawing mode (GH #75)

Reset clipping mode on every rectangle clip

Improved error handling for FriBidi and FreeType (GH #131)

Fix bitmap combining cache

Source code(tar.gz)
Source code(zip)
libass-0.12.0.tar.gz(447.93 KB)
libass-0.12.0.tar.xz(303.13 KB)
0.11.2(Apr 25, 2014)
Improve yasm version check

Fix \fscx0 crashes

Actually export ass_library_version

Fix change detection with vector clips

SIMD assembly bugfixes

Parse drawing numbers as floats (GH #63)

Fix shaper sign bug (GH #68)

Initialize \pbo correctly (GH #74)

Source code(tar.gz)
Source code(zip)
libass-0.11.2.tar.gz(424.98 KB)
libass-0.11.2.tar.xz(290.20 KB)
0.11.1(Feb 19, 2014)
Fix distfile generation

No functional changes

Source code(tar.gz)
Source code(zip)
libass-0.11.1.tar.gz(424.69 KB)
libass-0.11.1.tar.xz(290.05 KB)
0.11.0(Feb 18, 2014)
Add bitmap run combining/compositing
This changes the text rendering model and increases compatibility with VSFilter. It may make rendering faster or slower in certain cases.

Add AVX/SSE2 implementations for \be and compositing
This adds yasm as (optional) build dependency.

Add ass_library_version() API funcion (GC #113)

Add 'profile' program for benchmarks

Improve gaussian blur

Fix compilation with MSVC 2013

Speed up HarfBuzz shaper

Speed up cache

Notable compatibility bugfixes

Reset origin on \fay changes (GC #88)

Tons of parser fixes

Fix ascender/descender metrics (GH #8)

Fix \pbo sign and scaling

Don't reset wrap style on \r (GC #116, GH #45)

Notable bugfixes:

Correctly handle @font advance (GC #94)

Disable ligatures for non-zero \fsp

Make sure to release vector clip (GH #22)

Source code(tar.gz)
Source code(zip)
libass-0.11.0.tar.gz(414.33 KB)
libass-0.11.0.tar.xz(282.07 KB)