SUMMARY This is a reappearance of issues https://invent.kde.org/multimedia/kdenlive/-/issues/1225 (2021-2022) and https://invent.kde.org/multimedia/kdenlive/-/issues/1635 (2023). Any word beginning with: الأ Or: الا Such as: الأسد الأسقف الانسان They get a glitch: A box gets rendered between the first two characters. See image here: https://invent.kde.org/-/project/19/uploads/1fcc483f909f20539836dc25b857dd24/image.png STEPS TO REPRODUCE 1. Write الأسقف as subtitle (from the subtitles button) 2. It will get rendered on the frame with a square in the middle This issue does not happen on version 22.08.3 (I just tested it on this old version), so it could not be related to some shared library I have on my system, it must be some recurring bug inside Kdenlive. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
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.