Created attachment 137854 [details] Video output of test project SUMMARY When enabling “Typewriter effect” for a text element in a title clip, some non-ASCII characters get displayed in multiple steps, where the first one shows a different character. Maybe it’s splitting the character’s UTF-8 encoding mid-byte? STEPS TO REPRODUCE 1. Add a title clip 2. Add a text element to it 3. Add the character “—” (— U+2014 EM DASH) to it 4. Enable “Typewriter effect” 5. Render the project OBSERVED RESULT For a brief moment, what looks like “��” (twice U+FFFD REPLACEMENT CHARACTER is displayed in the video file. EXPECTED RESULT “—” is displayed. SOFTWARE/OS VERSIONS Pop!_OS 20.10 Installed via Flatpak
Thanks for your report! Does it work right without typewriter effect?
Yes, the character shows up correctly when not using the typewriter effect. When it’s disabled, the result is the same as the last part of the uploaded sample video, but for the entirety of the title.clips duration, as expected. The typewriter effect seems to split the string on a byte that’s in the middle of a UTF-8 code for one character. The UTF-8 for “—” is E2 80 94.
Hi, sorry, it took me a long to find time time to fix it. The fix was relatively easy to do, so sorry again - I could do it much earlier. The bugfix was send to mlt: https://github.com/mltframework/mlt/pull/739 After it is accepted you can remove typewriter from effect blacklist.
*** Bug 440217 has been marked as a duplicate of this bug. ***
Hi Rafal, nice to hear from you again and thanks for the fix!!!
The fix was merged, and it is add to MLT 7.2.0 milestone.
This fix will then probably be in Kdenlive 21.08.3 (at least for the packages that are maintained by the Kdenlive team directly). You can already test it with the nightly builds. I am going to close this now. Thanks again to all of you for report and fix.
(In reply to Julius Künzel from comment #7) > This fix will then probably be in Kdenlive 21.08.3 (at least for the > packages that are maintained by the Kdenlive team directly). You can already > test it with the nightly builds. I am going to close this now. Thanks again > to all of you for report and fix. Was it put back in 21.08.3? I am getting messages from other users that it was not. I see it the git https://invent.kde.org/multimedia/kdenlive/-/blob/v21.08.3/data/blacklisted_effects.txt#L34 that it wasn't whitelisted. Any plans about that?
(In reply to Rafal Lalik from comment #8) > (In reply to Julius Künzel from comment #7) > > This fix will then probably be in Kdenlive 21.08.3 (at least for the > > packages that are maintained by the Kdenlive team directly). You can already > > test it with the nightly builds. I am going to close this now. Thanks again > > to all of you for report and fix. > > Was it put back in 21.08.3? I am getting messages from other users that it > was not. I see it the git > https://invent.kde.org/multimedia/kdenlive/-/blob/v21.08.3/data/ > blacklisted_effects.txt#L34 that it wasn't whitelisted. > > Any plans about that? I think Massimo blacklisted it because it is also implemented within the titler UI. Do you see any cases where the normal effect is better than the build in one of the titler? If so we can re-enable it otherwise I would prefer to keep it blacklisted and use the build in effect instead.
I can imagine a situation where the same clip can be used with and without the effect. Then you add the effect on top of the clip in the timeline.
Git commit 7e1a2251e42f59ccdd29f45a3b28a96e81360697 by Julius Künzel. Committed on 15/11/2021 at 23:31. Pushed by jlskuz into branch 'release/21.12'. Typewriter effect should not be blacklisted! Related: bug 445232 M +1 -1 data/blacklisted_effects.txt https://invent.kde.org/multimedia/kdenlive/commit/7e1a2251e42f59ccdd29f45a3b28a96e81360697