File name text overflows off window due to limited wrappable characters

[alystair]

mpv version and platform

2017-02-12 Windows

Reproduction steps

Open video with a long file name with no spaces

Expected behavior

File info text fits/wraps width of window

Actual behavior

Name outsizes and overflows off screen

Log file

Not necessary for repro

Sample files

Not necessary for repro

[wiiaboo]

What's a file info? What do you consider a portrait display? Log, sample, or screenshot would've answered these questions. Don't ignore the issue template.

[Hrxn]

Maybe add a screenshot?

[alystair]

Ok looks like I was wrong - this isn't actually caused by portrait mode but due to filename not having spaces and lack of other allowed wrap characters. Here's a screenshot.

[alystair]

I think this is easily remedied by allowing all periods in filename other than the last one before the extension to wrap the text like the space character does. See concept below:

[wiiaboo]

But the problem is libass doesn't support linebreaking with zero-width spaces. You'd have to replace every [.-_] by {\\fscx0.1} {\\fscx100}$1 which could lead to huge ASS strings.

[astiob]

Frankly, I don’t think long ASS strings would be a problem, not in the case of file names at least.

You can also shave off a few bytes by using {\fscx0}␣␣{\fsc} (with two spaces to work around libass/libass#185) (assuming libass/libass@fc13f53, libass 0.11.0 or newer) and even more by declaring a custom ASS style “X” that has ScaleX=0 and using {\rX}␣␣{\r} (if mpv has a separate libass pipeline for the OSD such that this won’t interfere with the rendering of any subtitles).

[Et0h]

I tested {\fscx0} {\fscx100} (with double space) through the Syncplay mpv lua script and it seemed to work okay, I just had to remember to ensure the character insertion was done in a Unicode-compatible way.

[Argon-]

For proper wrapping, you also want to make sure that there are no superfluous space characters.
I've encountered this once. Default wrapping:

With \q2:

The culprit was a bunch of spaces in front of the wrapped line that were not rendered but somehow taken into account for line wrapping calculations, so this could be easily fixed: 76ae38a

[alystair]

Just following up, was this ever added? Please close it if it was done.

[wiiaboo]

It wasn't.

[Akemi]

duplicate of #2203.