Wrong display of arabic character in unicode subtitles

While displaying arabic subtitles regularly appears a character 'square'. Attached is a test video in which this can be seen. The second file is an image, the location of the faults are marked with red dots. Note that the preceding arabic character is always the same. The error has not to do with Windows-type line breaks in the subtitle file, it also occurs with Unix line endings.

Red dots mark the locations of unicode display errors

Added attachment:

• red dots mark the locations of unicode subtitle display faults.png

arabic subtitle track to test the unicode display error

Added attachment:

• sample.arabic.utf.srt

Timesaving test video could not be transfered, raise upload limit for better working conditions..

Added attachment:

• disturbance.png

freetype renderer cannot always handle CTL (complex text layout) properly. So, Arabic ligatures like Lam-Aleph لا are not displayed properly.

I know two workarounds:

• Convert srt to ass (using Aegisub) and play the video with subtitles using VLC-2.1.0 nightly.
• Use Mac OS X and coretext renderer.

converted ASS subtitles sample

Added attachment:

• sample.ass

assigned to @jbk

Is it so that VLC misuses !Fribidi/FreeType, or is it a limitation of the libraries? In the latter case, I'm afraid the only option is to close this as notvlc.

A bug could be opened to switch to CoreText on MacOS, but that's a different problem.

added Component::Subtitles + 1 deleted label

Added attachment:

• 2013-02-08 arab subtitle chars display normal in Aegisub.png

Added attachment:

• 2013-02-08 arab ass subtitles does not display proper in todays nightly.png

Added attachment:

• 2013-02-08 correct arab chars in Abiword.png

@ Nkonyama

The Lam-Alef character displays properly. But with each occasion, a redundant square is added. By converting the subtitle source with Aegisub, in todays nightly the problem persists.

The 500 KB upload size limit makes transfer of a high color still image a costly waste of time, I attached a 256 color screen dump.

@ courmisch

Attached is an image from a project that also uses Fribidi. In Abiword the display of characters is correct.

@ Jb

Origin of the problem might be an UTF8 code mistakenly processed. Sure thing is that UTF16 works not, but that is a negligible problem since UTF16 is completely into disuse because of confusions between big-endian and little-endian.

commit 9be4f7e0 Author: Salah-Eddin Shaban salshaaban@gmail.com Date: Mon Jan 5 14:52:33 2015 +0000

freetype: fix extra squares in Arabic subtitles (fixes [#6152](https://code.videolan.org/videolan/vlc/-/issues/6152) [#8117](https://code.videolan.org/videolan/vlc/-/issues/8117))

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Original author: salshaaban@gmail.com

added Status::fixed label

closed

changed milestone to %3.0.0

Milestone renamed

changed milestone to %3.0 FF

Milestone renamed