Oleg Oshmyan

> A font collector’s task is to gather fonts that will be sufficient and necessary for playback in stable/future renderers, not in a particular bugged version of libass. Ideally, of...

> VSFilter running on not up-to-date Windows cannot deal with any non-bitmap colour emojis Colour emoji? Even on up-to-date Windows, what can VSFilter possibly do with colour emoji? It's still...

[fansubBlock.ttf.zip](https://github.com/libass/libass/files/4940285/fansubBlock.ttf.zip) #316/#327 fixed a thing where we were bolding some fonts that shouldn’t be bolded, but it didn’t fix this font. As far as I can tell, this font claims...

> Do not scale delay parameter of legacy effects > VSFilter explicitly unscales those parameters, to make it relative to storage rather than Play* resolution This wording doesn’t make sense...

> I agree that the title could be clearer and am open to suggestions. > I got to the “unscaled”/“non-scaled” naming, because for ASS, storage resolution is basically the native...

> If I take the smae video file and the same ASS file except for a changed `PlayResX`, then the Banner effect still moves the same amount of _storage pixels_...

And speaking of this: > Your samples seem to all use delay 0, that is 1 due to the `max(., 1)`, and that 1 is indeed 1 ms per storage...

> I checked all instances of `m_scalex` in xy-VSFilter (not `m_scaley`). Sounds good enough. Thanks! > Huh.. a simple grep actually only shows one remaining use Great! Sounds like we...

And if we lack storage size but have `font_scale_x`, shouldn’t we calculate border/delay scales as if by estimating `storage_width` as `PlayResX / font_scale_x` rather than (as we currently do) `PlayResX`?

Ah, no, never mind. Not only did I make a mistake in the text (scratch the `scr_h /` part), but we don’t even know which width PlayResX actually corresponded to...