Oleg Oshmyan

As tracked in https://github.com/libass/libass/issues/550, this probably depends on the `\fe` and/or the user’s locale (or more pertinently, the subtitle author’s locale, which might be estimated using the track’s language if...

@madshi I just want to point out that wm4 is also a video renderer developer and tries to look at the issue from both points of view at the same...

Oh, and while I remember, here’s a use case for overlapping bitmaps: a long vertical strip of subtitles (I dunno, some karaoke or a sign perhaps) and a long horizontal...

@wm4 Well, that was in reply to your > > The ISubRenderFrame logic expects the subtitle renderer to group small subtitle elements which are near to each other together into...

Not sure what you mean. None of this has been implemented yet.

I don’t think this is related to UCRT, and FWIW I don’t think I’ve ever seen UCRT builds of VSFilter. (Just checked the latest pfmod builds: `msvcrt.dll`.) Deep down, for...

Related: https://code.google.com/archive/p/libass/issues/95 Thanks for filing this report. I’m not fully sure about the visible gaps and overlaps in the screenshots, but in any case this happens because libass doesn’t actually...

I see you’ve replaced some `intptr_t` by `ptrdiff_t` in the prototype of `be_blur`. I’ve asked about `intptr_t` before, and the answer was that it’s intentionally used as even though it’s...

TL;DR: Hopefully this doesn’t currently matter. I do prefer `size_t` in C. But technically `uintptr_t` seems safer for our x86 asm code and for likely future non-x86 code; and x264...

Thanks for the research! > We rely on platform ABI for assembly interop and sizes of `ptrdiff_t`/`size_t` are a part of ABI too This is a very good point! But...