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.
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.
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.
(Note that the wordjoiner doesn't have font or spacing issues as
it’s defined to be invisible and zero-width.
If a user supplies a special font like FontoXMLWhitespace¹
showing the word-joiner that's not a problem anymore but a
deliberate choice)
[1]:
https://documentation.fontoxml.com/latest/whitespace-visualization-5b5c6b154c78#id-18b2211e-79cb-4b85-8390-1e54d0f45466
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
