summaryrefslogtreecommitdiffstats
path: root/libass
Commit message (Collapse)AuthorAgeFilesLines
* fontselect: automatically read metadata from font file if neededOleg Oshmyan2021-07-104-77/+76
|
* fontselect: reorder function definitionsOleg Oshmyan2021-07-101-150/+150
| | | | This will be needed for the next commit.
* fontselect: save library and ftlibrary in ASS_FontSelectorOleg Oshmyan2021-07-104-40/+42
| | | | ...instead of passing them as arguments everywhere.
* dwrite_c: fix incorrect macro parameter namesOleg Oshmyan2021-07-101-1/+1
|
* Pass last-resort-fallback family name directly to get_font_infoOleg Oshmyan2021-07-103-49/+32
|
* font, fontselect: factor out common code for creating FT_FaceOleg Oshmyan2021-07-104-82/+84
|
* fontconfig: fix misplaced overflow checkOleg Oshmyan2021-07-101-6/+6
| | | | This allowed writes to one past the end of `families` and `fullnames`.
* directwrite: support WinRT/UWP, which forbid LoadLibraryOleg Oshmyan2021-07-102-7/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Normally, we delay loading Dwrite.dll until runtime to allow building and running DirectWrite-enabled libass binaries on old Windows versions that lack DirectWrite. However, this is forbidden in WinRT/UWP. DirectWrite is present in all versions of Windows that support WinRT/UWP, so we lose nothing by requiring it. Older Windows SDKs (Microsoft and MinGW alike) lack <winapifamily.h>, so include it only if we really need it. Based on VLC patch for libass: https://github.com/videolan/vlc/commit/eedb57aa96d2bc0046a6da2e081c75ae9edf8fd5 and on this autoconf code: https://github.com/lu-zero/mfx_dispatch/commit/c51a54c15f51579804030c70592c0a26065f1242 Note: the VLC patch retained an unconditional call to FreeLibrary in destroy_provider. However, FreeLibrary does not actually expect NULL as argument, so this commit adds a guard to that call. Perhaps FreeLibrary(NULL) simply fails cleanly and that's why this has not caused VLC problems, but we should not rely on this.
* directwrite: remove unused #includesOleg Oshmyan2021-07-101-2/+0
|
* directwrite: remove arbitrary 256-char name length limitOleg Oshmyan2021-07-102-11/+32
|
* directwrite: reorder code to avoid possible unneeded allocationOleg Oshmyan2021-07-101-12/+11
|
* directwrite: factor out conversion to UTF-8Oleg Oshmyan2021-07-101-58/+26
|
* directwrite: don't use wrong family names on errorOleg Oshmyan2021-07-101-1/+1
|
* fontselect, coretext: match whole extended family on fallbackOleg Oshmyan2021-06-074-51/+71
| | | | | | | | | | | | | | Currently implemented only for coretext, but other providers may/should add this later. This improves fallback font choice by considering the whole extended family. This also fixes remaining cases of Core Text fallback failure caused by differences among the names recognized by Core Text, the name we choose to return from get_fallback, and the names we seek in find_font. This partly reverts commit 152d0484e98f118d01987138695cf40579c9e297. This fixes https://github.com/libass/libass/issues/512.
* coretext: deduplicate found fonts in match_fontsOleg Oshmyan2021-06-071-1/+15
| | | | | | | | | | | We ask Core Text to match multiple name fields, and a single font may match several at once. In this case, by default, Core Text duly returns the font multiple times, and we add it to fontselect multiple times. This does not break anything, but it is a waste, so ask Core Text to deduplicate the returned list. This is supposedly available since Mac OS X 10.5. We support Core Text on 10.6+.
* ass_utils: add format-string attr to ass_msgrcombs2021-05-311-0/+3
| | | | Allows compilers to print warnings when the args we pass don't match the string
* Fix some format string bugsrcombs2021-05-302-4/+4
| | | | | - ass_drawing was logging size_t as %d - ass_font was logging ASS_StringView as %s (could crash!)
* directwrite: add whole font family from `match_fonts`Apache5532021-05-121-9/+16
| | | | | | | match_fonts is supposed to add all the fonts with the same family name for fontselect. Commit d325c633f4ac32fcb4c76a3fb5926737a45c38d0 adds only one font, which leads to inability to select (using family name) correct fonts from families with multiple styles.
* Release 0.15.10.15.1Oleg Oshmyan2021-05-022-2/+2
|
* quantize_transform: set whole *pos struct to enable assignment-copyOleg Oshmyan2021-05-021-2/+4
| | | | | | | | get_bitmap_glyph copies this struct via assignment. But to allow safe assignment-copy, it seems the whole struct must be initialized, rather than merely each of its members. Fixes CID 314186 found by Coverity Scan.
* directwrite: request font on demandApache5532021-05-012-35/+77
| | | | | | | | | | | | scan_fonts can be very slow when many fonts were installed in the system. Use IDWriteGdiInterop to create a font by its name when needed instead of scanning all installed fonts during the initializing stage to get better performance. In case of a non-existent font, the fallback mechanism should do its work. Fixes https://github.com/libass/libass/issues/334. Signed-off-by: Oleg Oshmyan <chortos@inbox.lv>
* directwrite: cast function pointer through void* to quelch warningOleg Oshmyan2021-05-011-2/+3
| | | | | GCC and MSVC (at least) warn about this cast as the function types appear to be incompatible. This is correct with GetProcAddress.
* rasterizer: fix assembly for WIN64Dr.Smile2021-04-301-1/+3
| | | | | | | | Second argument of cglobal macro for fill_halfplane in 64-bit mode should always be 6 to preload all function arguments into registers. It doesn't matter under *nix as the first 6 arguments are already in registers according to calling conventions, but under WIN64 it's only the first 4.
* coretext: check all allocation failures and release soonerOleg Oshmyan2021-04-291-32/+66
| | | | | | All Create and Copy functions create new objects, so all of them may fail. Keep using SAFE_CFRelease only in shared cleanup clauses.
* fontselect: coretext: get fallback font family name via FreeTypeOleg Oshmyan2021-04-295-10/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit be0d1613f79a95073d18d96a60e1394abf9316a2, get_fallback can return a name from Core Text that is different from all names that match_fonts registers for the same font. This causes font fallback to fail as find_fonts fails to find any font having the name received from get_fallback. (Moreover, libass will keep retrying fallback for other glyphs, and the coretext match_fonts will keep readding the same fonts over and over again.) Commit 152d0484e98f118d01987138695cf40579c9e297 attempted to fix font fallback by getting a full name from Core Text instead of a family name when it was noticed that Core Text's family name can come from TT_NAME_ID_TYPOGRAPHIC_FAMILY in addition to TT_NAME_ID_FONT_FAMILY, which we fetch in get_font_info, but the problem goes deeper: Core Text can return Macintosh-platform names that don't match Microsoft-platform names, or the font might have no Microsoft-platform names at all. Furthermore, returning a full name breaks style matching: get_fallback does not know about weight, slant etc. and is expected to return a whole family of fonts that will be lazy-loaded in its entirety (if applicable) and searched through for the best stylistic match by find_fonts. To fix fallback while preserving maximum name portability in the spirit of be0d1613f79a95073d18d96a60e1394abf9316a2, use the same API in get_fallback as is used in match_fonts to look up a family name. Note: this could be more efficient if ass_get_font_info could be told to return just an arbitrary family name. This fixes https://github.com/libass/libass/issues/457.
* fontselect: coretext: ask Core Text for family name as last resortOleg Oshmyan2021-04-293-28/+70
| | | | | | | | If a font contains no recognized Microsoft-platform family names, use the family name reported by Core Text. Skip FreeType's face->family_name because it is an ASCII bastardization of a family name and may not exist at all.
* fontselect: coretext: reuse main FT_LibraryOleg Oshmyan2021-04-298-23/+22
|
* coretext: don't call strcmp to check for empty stringOleg Oshmyan2021-04-291-1/+1
|
* Skip glyphs with \fscx0 or \fscy0 after layoutOleg Oshmyan2021-04-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These glyphs are effectively invisible. VSFilter draws no border around them, either (because for BorderStyle 1 it finds no pixels to draw a border around, while BorderStyle 3 gets scaled a second time by the same \fscx or \fscy), except current MPC-HC (which doesn't double-scale BorderStyle 3). Since nothing is to be seen on screen, skip the rest of the pipeline altogether. They still affect the layout of other glyphs that may have nonzero scales, so we can only do this after text layout is done. This avoids subsequent divisions by zero when sheared pre-scale coordinates are computed from post-scale coordinates at scale zero. (We eagerly scale all coordinates before shearing because it makes text layout easier.) In apply_baseline_shear itself, the shear displacement for an \fscy0 glyph is always zero, so skipping its calculation is safe. For an \fscx0 glyph, we currently divide 0 by 0, which we want to avoid. Logically, this is supposed to take the cluster's pre-\fscx advance and compute shear from that, but this commit does not do this. When in VSFilter-compatible mode, we're actually supposed to reset the baseline when \fscx becomes nonzero, so this won't matter. Meanwhile, when we're trying to do a "sensible" thing, it's not clear whether shear-before-scale makes sense in the first place. At any rate, this improves upon the current behavior by avoiding the zero division, and at least on x86 this actually happens to match our current layouts in situations where the current code produces visible output at all. Fixes https://github.com/libass/libass/issues/185. Fixes https://github.com/libass/libass/issues/413. Fixes https://github.com/libass/libass/issues/428. Fixes https://github.com/libass/libass/issues/443.
* Delay \fay baseline shear until last text layout stepOleg Oshmyan2021-04-293-12/+28
| | | | | | | | | | | | | | | | | | | | | | | | | The current code calculates the effect of \fay on advances early in retrieve_glyph, only to ignore it until reorder_text, which then partially undoes these calculations. Instead, just calculate it once, when all the necessary properties have been fully determined. The earliest point to do this would be within reorder_text, but to simplify future logic changes, delay this until all other text layout steps are done. This matches VSFilter, which applies shear after alignment. This would also have neutralized the bug that the previous commit fixed, because glyphs[0].pos.y really is always 0 until shear is applied. This also opens the door for another commit to skip glyphs that are invisible but affect layout. In addition to simplifying code and calculations, this commit fixes a bug: the current code for undoing shear assumes constant scale_x/y from the last \fay change or line break point to the next such point, producing strange, wrong positions when scale_x/y do change. This fixes https://github.com/libass/libass/issues/465.
* reorder_text: tweak code styleOleg Oshmyan2021-04-291-4/+4
| | | | | Put continue on its own line. Don't mutate & reset info.
* Ignore glyphs[0].pos.y in compute_string_bboxOleg Oshmyan2021-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In most cases, text_info->glyphs[0].pos.y is 0. This makes the bbox in compute_string_bbox have bbox.y_min = -text_info->lines[0].asc. Thus, during event positioning, we refer to the text's top and bottom edge coordinates in two equivalent ways: \an4-6, \pos, \move and Scroll effects use bbox.y_min and bbox.y_max, while \an1-3 and \an7-9 use -text_info->lines[0].asc and text_info->height - text_info->lines[0].asc. However, text->glyphs[0].pos.y is not *actually always* 0. Specifically, it is nonzero for events that begin with right-to-left text with nonzero \fay (at least two visible glyphs with the same \fay). In this case, the anchoring point we use for vertical positioning is different between \an1-3,7-9 and the other cases. For \an1-3,7-9, it is the middle point of the text's left edge, which makes sense. But for \an4-6, \pos, \move and Scroll effects, it is shifted up. It is easiest to describe for a single-line event: the anchor is the middle point of the *left edge of the rightmost glyph*. That is, the anchor point is not the middle of *either* edge of the full text, and it is hard to understand intuitively, more so in a multiline event. VSFilter in the same situation places the anchor in the middle of the whole event's left edge, just as we do for \an1-3 and \an7-9. This also affects the position of rotation origin, which is likewise unintuitive and VSFilter-incompatible. Fix this by making compute_string_bbox ignore text->glyphs[0].pos.y even in the rare case that it is nonzero. This makes our behavior obvious and VSFilter-compatible, and our code easier to understand (as the reader no longer has to wonder whether there is a difference between the various alignments, wonder *why* there seems to be no difference after testing common cases, and make the wrong conclusion that glyphs[0].pos.y is always 0).
* Fix embedded and memory fontsOneric2021-04-225-9/+32
| | | | | | | | | | | Previously only both only worked when ass_set_fonts was called after all embedded and memory fonts were already added. Especially for embedded fonts this meant it won't work for most users, except mpv, including our own utilities, even if extract_fonts was set. Now that it works, enable extract_fonts in our utilities. GitHub: fixes #266
* ass.h: fix ass_clear_fonts documentationOneric2021-04-221-0/+2
| | | | | | | | As the function only takes a library handle it is imposssible to adjust it to be safe to call otherwise. FT_Done_Face needs to be called before the font data can be freed. Luckily it seems barely anyone even used this (mpv, ffmpeg, VLC and Aegisub don't)
* library: replace grow_array with ASS_REALLOC_ARRAYOneric2021-04-223-19/+6
| | | | | | The latter has overflow protections for size_t indexation and element size > 1, the former none whatsoever. Change all related vars to size_t. Additionally, switch to exponential buffer growth.
* Make assembly position-independentDr.Smile2021-04-214-29/+188
|
* rasterizer: improve assemblyDr.Smile2021-04-211-187/+149
|
* rasterizer: make C and assembly functions bitwise identicalDr.Smile2021-04-212-12/+15
| | | | Fixes https://github.com/libass/libass/issues/475
* blur: slightly improve assemblyDr.Smile2021-04-211-34/+28
|
* Make argument order uniform between bitmap functionsDr.Smile2021-04-217-74/+71
|
* Rewrite be_blur() assemblyDr.Smile2021-04-213-231/+203
| | | | | | | | | | | | | Change list: - Fixed differences from C version introduced in f23b9ed64bd4ccf249c686616dd3f51a69d285dc. - Common macro for SSE2 and AVX2 versions. - Reduced register usage and efficient 32-bit version. - Full width memory operations instead of half-register. - Vectorized handling of width tails instead of byte/word loops. - Vectorized initial population of temporary buffer and final line fill. - Interleaved layout of temporary buffer. - Great speedup overall.
* ass_bitmap: remove redundant memsetsDr.Smile2021-04-211-3/+0
|
* Rewrite mul_bitmaps() assemblyDr.Smile2021-04-212-124/+64
| | | | | | | | | | Change list: - No special handling of unaligned case. - Common macro for SSE2 and AVX2 versions, AVX2 has got significantly faster. - Reduced register usage and efficient 32-bit version. - Full width memory operations instead of half-register. - Vectorized handling of width tails instead of byte loops.
* Rewrite add/sub_bitmaps() assemblyDr.Smile2021-04-212-138/+52
| | | | | | | | | | Change list: - No special handling of unaligned case (removed in previous commit). - Common macro for both add_bitmaps() and sub_bitmaps(). - Reduced register usage and efficient 32-bit version. - add_bitmaps() no longer rely on zero padding. - Vectorized handling of width tails (instead of byte loop in sub_bitmaps(), great speedup for non-empty tails).
* Make alignment and padding of all bitmaps consistentDr.Smile2021-04-212-6/+7
|
* quantize_transform: Reword explanatory commentOneric2021-03-281-18/+21
|
* Eliminate accidental trigraphsOneric2021-03-281-3/+3
| | | | | | | Those particular instances were harmless, but in general trigraphs can cause unintended behaviour changes. Not having any trigraphs in the code makes it easier to catch unintended ones via a simple regex. (In GNU-C trigraphs are disabled by default, but enabled in ISO-C)
* Replace M_PIOneric2021-03-283-4/+6
| | | | | | M_PI is not part of ISO C and also not part of base POSIX, but an XSI extension. For simplicity, just always use our own macro for PI. The value is identical to the one used in glibc and musl.
* Add strdup fallbackOneric2021-03-283-6/+24
| | | | | | | | And move fallback declarations to ass_compat.h As ass_compat.h is already included in every source file we no longer need to include _both_ string.h and ass_utils.h to use str(n)dup. Definitions are still in ass_utils.c since a separate source file just for two functions seemed overkill.
* Print libass versionOneric2021-03-261-0/+4
| | | | | | | | | This could help us in future bug reports and we already do so for shapers and freetype. Also include a guess about the source code version, which may not be entirely reliable. Eg if custom tarballs are involved or if patches are added after configure was called, the value will be wrong. But hopefully it will be "good enough" for most cases.
* Do not apply \fsp to vector drawingsOleg Oshmyan2021-03-251-3/+5
| | | | | | This matches VSFilter. Fixes https://github.com/libass/libass/issues/487.
* be_padding: pad enough for intermediate states, not only resultOleg Oshmyan2021-03-051-3/+1
|
* Fix crash on empty stringsDr.Smile2021-02-241-0/+3
| | | | | | Our hash function doesn't handle zero-length buffers, but it was not a problem until 82b225b3d6653091d028b39d561d185ed76a7be5. Found by OSS-Fuzz.
* x86: update x86incRyan Lucia2021-02-232-263/+538
| | | | This should fix the warnings introduced with nasm 2.15
* cache: replace memcpy() in key move functions with assignmentDr.Smile2021-02-221-20/+23
|
* parsing: use string references for font family and drawing textDr.Smile2021-02-229-76/+77
| | | | That eliminates most uses of strdup() in the rendering process.
* Move ASS_FontDesc to generic cache infrastructureDr.Smile2021-02-223-33/+7
|
* ass_render: fix aliasing when 1a=0 but 3a>0rcombs2021-02-132-1/+3
|
* fontselect: warn when no fallback can be foundrcombs2021-01-161-0/+3
|
* docs: fix simple typo, ouline -> outlineTim Gates2020-12-181-1/+1
| | | | | | There is a small typo in libass/ass_outline.h. Should read `outline` rather than `ouline`.
* ass_library: Constify ass_add_fontHugo Beauzée-Luyssen2020-11-012-2/+2
| | | | | Both parameters are copied and are immutable. Make it clear through the function prototype
* Treat zero-area events as explicitly positionedOneric2020-10-311-2/+4
| | | | | | | | | | | | | | | | | | | VSFilter does collision by calculating the intersection of two events rectangles and treating events as colliding iff their intersection has a non-zero area. As a consequence zero-area events cannot collide with anything. https://github.com/Cyberbeing/xy-VSFilter/blob/xy_sub_filter_rc4@%7B2020-05-17%7D/src/subtitles/RTS.cpp#L1627 libass does not do collision by intersection area, but because we ignore edge-edge intersections results are identical to VSFilter for non-zero-area events. To reconcile the results for zero-area events, treat them as explicitly positioned as they effectively are in VSFilter. This allows us to keep our (probably) faster collision code and saves us from unnecessary collsion checks for zero-area events. Fixes https://github.com/libass/libass/issues/444
* Don't carry xbord width across eventsOneric2020-10-311-0/+1
| | | | | | Since text_info is not re-initialised before every event, border_x could carry over to following events with a smaller \xbord value. This was broken in commmit 236bc18d39c080853d1145c7b978fb8f47e31deb
* ass_utils: round double_to_d* properlyOleg Oshmyan2020-10-291-3/+3
|
* shape_harfbuzz_process_run: round scaled positions properlyOleg Oshmyan2020-10-291-4/+4
|
* Match more types and format specifiers to size_t fontdata_usedOleg Oshmyan2020-10-281-2/+2
| | | | | | | | Omissions in commit 910211f1c0078e37546f73e95306724358b89be2. Microsoft's C library does not support %zu until Universal CRT (Visual Studio 2015). At worst, this verbose-level message will look wrong and be useless.