[FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Oneric
> Sent: Friday, February 4, 2022 10:19 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
> 
> On Fri, Feb 04, 2022 at 06:48:40 +0000, Soft Works wrote:
> > > [two-part message removed for brevity]
> >
> > I've found out where the \{ and \} escaping has come from: libass
> 
> As already written in the commit-message of the first patch..
> 
> 
> You already noticed your proposal only works with VSFilters,
> but even without this it's a terrible approach. Consider:
>  - fullwidth characters have different metrics then the "regular" ones
>  - fullwidth and small characters have a different visual appearance
>  - support for fullwidth and small characters in fonts is much rarer
>    than support for plain {}
>  - fullwidth characters are commonly used _as fullwidth characters_
>    e.g. in text using one of the CJK writing systems.
>    Replacing them with non-fullwidth variants when transforming
>    away from ASS is guaranteed to be disastrous.
>  - Not sure if applies, but something to keep in mind:
>    {\r} is not a noop if the source-format had any sort of per-event
>    styling which got prepended to the ASS event text before
>    using the plain-text conversion for the rest of the event.

     No, this doesn't apply from what I've seen, but {} might
     still be preferable.

> As noted in the discussion of the libass issue you linked,
> it’s not unusual for ASS subtitle authors to employ
> fullwidth curly braces for displaying curly braces
> in all ASS-renderers. However, they have tight control over the
> fonts used and can carefully select them to match the visual
> appearance and compensate differing metrics with bespoke
> local adjustments to \fs and negative \fsp.
> ffmpeg does not have tight control over the fonts and it'd be silly
> to require users to pass in special fonts just to render curly braces.

I basically agree to everything you say - except that there's a 
little misunderstanding. Maybe I haven't explained well enough.

We use ASS as the internal format to which all text subtitles are 
decoded and from which all text subtitles are encoded for output
and for the upcoming subtitle filtering it's also the one and only
format for text subtitles.

BUT: That does not necessarily mean that the internally used
ASS must be exactly the same that we're outputting when encoding
to ASS. And that's why we need to consider this as two separate
steps. It would also be possible to have options at the ass encoder
to control the compatibility of the encoded ASS output.

That internal ASS format already has some quirks that some had 
introduced in order to achieve certain things when other subtitle
formats are involved at the input and at the output. That's why
we should not continue adding one workaround on top of another
but try to clean those things up instead.

With your submission, you are actually pointing at a core point
of evil: the escaping of braces in combination with the backslash
logic introduces an unresolvable ambiguity. And when we don't
clean that up, it won't be possible to get on a sane path.


> If you want to make the rendering in VSFilters not complettly broken,
> try to do what the libass-wiki recommends and add an empty command
> block after an escaped opening curly brace. This way VSFilters
> will display a lone backslash instead of a opening curly brace
> but otherwise work fine without swallowing up text.
> If done consistently closing curly braces won't need to be
> escaped at all anymore.
> However, such a VSFilter-compatibility change is unrelated to
> fixing the broken \\ escape which doesn't work anywhere.

see above, I'm not into changing ffmpeg's ass output, it's all
about the internally used ass format and the escaping is  
a central problem there.

> (Note that the wordjoiner doesn't have font or spacing issues as
>  it’s defined to be invisible and zero-width.

Yes, and the use of this has already created issues, even in libass:
https://github.com/libass/libass/issues/507

So it's very likely to cause issues in other implementations 
as well, and not many are developed as actively as libass.
(and even that doesn't help when you don't get an update 
for your device/software).

I wouldn't want to close like that, but I'm getting distracted
right now. Will get back later.

softworkz