\h fallback messes up positioning

[libass]

\h fallback messes up positioning

[astiob]

Sign-SaberWork is right- or middle-aligned? Duplicate of (the remaining sub-issue of) #16.

[rcombs]

Style: Sign-SaberWork,Embryonic Inside-Mod,160,&H00FFFFFF,&H000000FF,&H00FFFFFF,&H00000000,-1,0,0,0,100,100,0,0,1,0,0,5,10,10,10,1
Style: Sign-SaberWork2,Embryonic Inside,160,&H00FFFFFF,&H000000FF,&H00FFFFFF,&H00000000,-1,0,0,0,100,100,0,0,1,0,0,5,10,10,10,1

[astiob]

Yeah, I’d just compared the \pos to the screenshot and deduced it was \an5 when you replied. You haven’t copied enough “Saber” lines to be completely sure, but it must be #16.

[rcombs]

those are the only lines with the SaberWork styles in the script.

[astiob]

Yeah, that was a derp.

I’m struggling to understand which line produces which part of the image. What I can say for sure is that the first line definitely has \fsp and thus definitely is misplaced as in #16.

[astiob]

What happens in VSFilter:

1. VSFilter translates the \h used in the script to U+00A0.
2. VSFilter selects the font specified in the script, Embryonic Inside.
3. VSFilter calls GDI’s TextOut function to get the outline for the glyph run containing the U+00A0.
4. GDI does not find U+00A0 in the currently selected font.
5. ??? Another font is selected.
6. GDI uses the U+00A0 outline from the other font.

What currently happens in libass:

1. ass_parse selects the font specified in the script, Embryonic Inside.
2. ass_parse translates the \h used in the script to U+00A0.
3. ass_font translates U+00A0 to U+0020 “to avoid problems”.
4. ass_font happily finds U+0020 in the currently selected font.
5. libass uses the U+0020 outline from Embryonic Inside.

Two things need to be done:

• The U+00A0-to-U+0020 substitution needs to be removed. This is easy. Ironically, this will also resolve #2, as I will explain there in a moment.
• The fall-back font needs to match GDI’s. I am investigating; it seems this may be more complicated than I thought initially.

[grigorig]

Interesting. I added this substitution not for fun though, but to avoid rendering issues with various scripts. But that was back in 2009, libass has changed a whole lot since then.

[astiob]

The \h issue is also very visible in JoJo’s (and probably Commie’s) JoJo episode 20 at 12:44.

Also, sorry for the “referenced this issue from a commit” spam! ._. GitHub adds one every single time I push a rebased or reworded or very slightly modified commit. I wish it would just delete the previous “referenced” line when it does that.

[rcombs]

This looks to be fixed by @astiob's 2014 commit, or at least the sign looks pretty sensible now and I vaguely recall it being a fine mess:

[astiob]

That commit never landed in master. (Maybe I was afraid to suggest we seriously make master always fall back on Arial. Maybe I was worried about glyphs not supported by Arial.)

This is what the Carnival Phantasm sample looks like in VSFilter:

[astiob]

And the JoJo sample:

[astiob]

So what? Ffmpeg looks like is affected https://trac.ffmpeg.org/ticket/5851#comment:4

I don’t see anything in that ticket relevant to this bug.

But in general, FFmpeg is, of course, affected because it uses libass.

[astiob]

As tracked in #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 we ever start getting language information from demuxers).