Bug 502725

UPDATE:

The last version to work without this bug was *22.12.03*

Hi. Can you try using a different style/font?

I could reproduce the issue given your instructions using the default subtitle style/font (Arial).

When creating a new style with an Arabic font (I choose "Noto Sans Arabic") and using it for the subtitle style I did not get this square box anymore.

The old version you mentioned 22.12.03 didn't start on my system. As it runs on your system maybe you can check what font you chose there / what the default font is if you haven't changed it.

You are right I can observe the same behaviour. I tried using "Noto Sans Arabic", "Noto Naskh Arabic" fonts and they are fine.

But it seems like it happens on countless other fonts like: "Arabic Typesetting", "Arial", "Al Nile", "Al Bayan", "Al Tarikh", "Noto Sans Mono", "Times"..

Kdenlive is using ffmpeg subtitles filter for this AFAIK. So I tried to reproduce it via ffmpeg command line.

Create a minimal subtitle file `arabic_sub.srt` with the following content:

```
1
00:00:00,000 --> 00:00:05,000
الأسد
```

Then use a random sample video file and burn in these subs via ffmpeg subtitles filter.

The following command gives me the same result (square box visible) as when rendering via Kdenlive/MLT.

ffmpeg -i sample_video.mp4 -vf subtitles=arabic_sub.srt:force_style='FontName=Arial' burned_in_subs.mp4

When using `Noto Sans Arabic` instead it works (same as it does in Kdenlive)

ffmpeg -i sample_video.mp4 -vf subtitles=arabic_sub.srt:force_style='FontName=Noto Sans Arabic' burned_in_subs.mp4

I don't know Arabic nor do I have these other Arabic fonts you mentioned. I'm not really sure if this is a bug or just expected in case the specified font does not support whatever feature is needed to correctly display these characters. So maybe you can try some other Applications how they behave using different fonts and compare it to what Kdenlive or ffmpeg outputs?

Oh and did you check which font was used in the version you reported as last working?

(In reply to balooii from comment #5)
> Oh and did you check which font was used in the version you reported as last
> working?

Well, Arial works in version 22.12.03.

And thanks for trying it out. This issue could be possibly related to ffmpeg. It's possible that an older working version of ffmpeg was integrated in v 22.12.03, hence it works there.

I created https://trac.ffmpeg.org/ticket/11566#ticket

(In reply to ellat from comment #6)
> (In reply to balooii from comment #5)
> > Oh and did you check which font was used in the version you reported as last
> > working?
> 
> Well, Arial works in version 22.12.03.

If you're on Linux, there generally is no Arial font unless you've gone well out of your
way to install it manually.  It's not a freely licenced font, so distros generally can't
ship it by default.  It will get mapped to some other "similar" font that you do have
installed on your system.  (and even 'genuine Arial' may not provide the glyphs
you need for this either).

The "empty square box" is the normal fallback behaviour of most font rendering code
when some font does not have a glyph defined for a codepoint.

So the key point here is you need to find a font that contains all the glyphs you need
and configure your system to use it when you need those glyphs.  That means you may
want to select some font other than Arial, if you are supplying subtitle files and not burning
them in at render time, and you'll need to find a font that is available and provides the
needed glyphs on all the platforms you want to play this on.

There really is nothing that kdenlive (or any higher level library or tool) can do to 'fix' this
if you're using a font with missing glyphs.  The best we could do is share a user-created
list of fonts that people have tested to work portably for certain locales.

What would have changed to 'break' this for you is the default font that either your system
libraries provided, or that was suggested by something embedded in whichever packaged
version of kdenlive you used.  It won't have been a change in kdenlive itself that caused this.

So, I'd be inclined to close this bug as something "we can't fix", and perhaps open a thread
on the discuss forum for making font suggestions for various locales.

Sorry this bubbled away for so long without any clarification.  I'm currently working on
improving the subtitle handling, and only just now saw this report for the first time.