# 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.

The following projects/companies use libass:

# Other ASS/SSA implementations:

• #### 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)

• #### 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:

1. 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?
2. 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?)
3. 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?

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

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

0.16.0

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
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

No response

### Log

No response

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++) {
test_func(...);
test_func(...);
test_func(...);
test_func(...);
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++) {
for (int ti = 0; ti < INNER_RUNS; ti++) {
test_func(...);
test_func(...);
test_func(...);
test_func(...);
}
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

Guide to reviewing the commits:

1. 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.
2. 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.
3. 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:

1. 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.

2. 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

• 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.

• 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
• #### 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
• 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.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.
• 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.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 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.0(Feb 18, 2014)

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)
###### libelf as part of elfutils has been a major pain in the ass.

libelf in zig libelf as part of elfutils has been a major pain in the ass. All I want to do is make statically compiled programs that use eBPF (libbpf

13 Jul 21, 2021
###### ASS: Audio Stupidly Simple

A single header library for audio decoding and playback

32 Nov 13, 2022
###### A real-time DirectX 11 renderer. The renderer is named by my girlfriend's english name.

sophia Sophia is a real-time DirectX 11 renderer. It is not quite a rich graphics engine, only packages some low-level DirectX functions and contains

6 Dec 11, 2021
###### An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support

Vita-Media-Player An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support 1080i output supported on the PSTV natively and on the

50 Nov 25, 2022
###### Alpha Plot is a free application for Scientific Data Analysis and Visualization for Windows, Linux and Mac OS X

Alpha Plot is a free application for Scientific Data Analysis and Visualization for Windows, Linux and Mac OS X (probably BSD also). Web Link Website

171 Dec 26, 2022
###### The OpenEXR project provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.

OpenEXR OpenEXR provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the mot

1.3k Jan 6, 2023
###### (Simple String Format) is an syntax of format and a library for parse this.

SSFMT (Simple String Format) is an syntax of format and a library for parse this. SSFMT != {fmt} SSFMT is NOT an API/library for parse {fmt} syntax !

2 Jan 30, 2022
###### LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code.

LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code.

1.2k Jan 5, 2023
###### 2D and 3D map renderer using OpenGL ES

Tangram ES Tangram ES is a C++ library for rendering 2D and 3D maps from vector data using OpenGL ES. It is a counterpart to Tangram. This repository

750 Jan 1, 2023
###### Niagara UI Renderer | Free Plugin for Unreal Engine 4

Niagara UI Renderer | Free Plugin for Unreal Engine 4 Niagara UI Plugin adds Niagara Particle System Widget that allows you to render Niagara particle

156 Dec 19, 2022
###### Markdown renderer for Dear ImGui using MD4C parser

imgui_md Markdown renderer for Dear ImGui using MD4C parser. C++11 or above imgui_md currently supports the following markdown functionality: Wrapped

74 Dec 27, 2022
###### Ultra-lightweight web browser based on Qt Ultralight webview, powered by Ultralight HTML renderer

Qt Ultralight Browser This is an ultra-lightweight web browser powered by the Ultralight web engine embedded in Qt 5 app as a custom webview widget -

43 Jan 7, 2023
###### DOOM BSP renderer for ZenithOS.

Zenith DOOM This project ports the DOOM BSP renderer to Zenith for use in custom games. It includes a zos/ directory in src/ which has includes that e

3 Jun 10, 2021
###### Fegeya Freud, CLI FPaper renderer, based on Totem (less-like tool without --help)

Fegeya Freud, CLI FPaper renderer, based on Totem (less-like tool without --help`)

3 Jun 11, 2021
###### A toy renderer written in C using Vulkan to perform real-time ray tracing research.

This is a toy renderer written in C using Vulkan. It is intentionally minimalist. It has been developed and used for the papers "BRDF Importance Sampl

290 Dec 19, 2022
###### refterm is a reference renderer for monospace terminal displays.

refterm v2 refterm is a reference renderer for monospace terminal displays. It was designed to demonstrate that even in the worst-case scenario - extr

1.3k Jan 1, 2023
###### physically based renderer written in DX12 with image-based lighting, classic deffered and tiled lighting approaches

Features Classical Deferred Renderer Physically Based shading Image Based Lighting BRDF Disney model (Burley + GGX) Tangent space normal mapping Reinh

35 Dec 13, 2022
###### 2D GPU renderer for dynamic UIs

vger vger is a vector graphics renderer which renders a limited set of primitives, but does so almost entirely on the GPU. Works on iOS and macOS. API

172 Dec 30, 2022
###### PainterEngine is a application/game engine with software renderer,PainterEngine can be transplanted to any platform that supports C

PainterEngine is a application/game engine with software renderer,PainterEngine can be transplanted to any platform that supports C

1.6k Jan 4, 2023
###### Engine-3D is a 3D-Graphics Renderer built from scratch in C++

Engine3D Engine-3D is a 3D-Graphics Renderer built from scratch in C++, as an Undergraduate Computer Engineering Project for 5th Semester, assigned by

3 Oct 24, 2022