[CastagnaIT]

 @scott967 I think I found a problem with RTL rendering.  I created a subrip srt subtitle with a long text string in Hebrew.  When rendered the text was split into 2 line.  The punctuation (periods) were correctly placed on the first line, but wrong on the second.

i have tested your subtitle, although you have shared not a physical file, sharing subtitle content as plain text on webpages i think could lose the embedded unicode characters for text orientation
i have noticed that your subtitle creates strange behaviour in other players as well, some example:

VLC:


Kodi 19:



i have tested also MPV, but in this case the displayed text is clearly incorrect...

i am not an RTL expert, but know that there are unicode characters that can be inserted for the purpose of correctly orienting parts of the text.
from what i understand we have the best results compared to other players

however the RTL/LTR is managed internally by LibAss and his dependencies not Kodi anymore
if it is not a problem with your file, this you will have to try to report it to LibAss github by providing the original subtitle file
(but of course you must also provide evidence that your file works correctly with at least one video player)

[CastagnaIT]

@CastagnaIT Ok sorry, the text is just a little confusing, because it talks about "font border size".

Does this mean the size of the thin black line around the characters (what is this called anyway? Outline size or something?) will be configurable in a later version?

This thread aims to understand if subtitles are displayed correctly compared to the regular version of Kodi 19 or if other problems occur.

All improvements concerning the style/effects of displayed subtitles are in a different PR, mentioned before,
that PR is ready but not yet approved, for now it is not clear when it will be merged, then you cannot test it otherwise you have to build your own Kodi,
all new features added by that PR are written as list in first lines of PR text description

[MrMagic]

@CastagnaIT Ok sorry, the text is just a little confusing, because it talks about "font border size".

Does this mean the size of the thin black line around the characters (what is this called anyway? Outline size or something?) will be configurable in a later version?

This thread aims to understand if subtitles are displayed correctly compared to the regular version of Kodi 19 or if other problems occur.

Which is why I responded with the fact that subtitles have become a lot harder to read when they are displayed on a bright background. Or is that not the kind of feedback you are looking for?

All improvements concerning the style/effects of displayed subtitles are in a different PR, mentioned before,
that PR is ready but not yet approved, for now it is not clear when it will be merged, then you cannot test it otherwise you have to build your own Kodi,
all new features added by that PR are written as list in first lines of PR text description

I understand, but I was just asking for clarification. From that PR it is not clear to me that it will fix the issue that I described.

If you look at my photos, you can clearly see that in the old rendering method, each character has a pretty thick black outline of maybe 3 or 4 pixels.

In the new method it looks like this has been reduced to just 1 pixel.

I get the feeling that you don't want this issue to be discussed in this thread, even though you are asking for feedback on your changes, which feels a little strange to me.

[CastagnaIT]

I get the feeling that you don't want this issue to be discussed in this thread, even though you are asking for feedback on your changes, which feels a little strange to me.

we keep telling you that the feature you are looking for is already listed in the PR, but you don't seem to understand what is written there
so from PR https://github.com/xbmc/xbmc/pull/20169:
the second point:

Code:

Border size

I hope it is more understandable for you now

[MrMagic]

@CastagnaIT Thanks for the clarification. I will test again once that PR makes it into a nightly.

[scott967]

 @scott967 I think I found a problem with RTL rendering.  I created a subrip srt subtitle with a long text string in Hebrew.  When rendered the text was split into 2 line.  The punctuation (periods) were correctly placed on the first line, but wrong on the second.

i have tested your subtitle, although you have shared not a physical file, sharing subtitle content as plain text on webpages i think could lose the embedded unicode characters for text orientation
i have noticed that your subtitle creates strange behaviour in other players as well, some example:

VLC:


Kodi 19:



i have tested also MPV, but in this case the displayed text is clearly incorrect...

i am not an RTL expert, but know that there are unicode characters that can be inserted for the purpose of correctly orienting parts of the text.
from what i understand we have the best results compared to other players

however the RTL/LTR is managed internally by LibAss and his dependencies not Kodi anymore
if it is not a problem with your file, this you will have to try to report it to LibAss github by providing the original subtitle file
(but of course you must also provide evidence that your file works correctly with at least one video player)

OK, will do some more digging.  The file is UTF-8 encoded, and I did check it in a hex editor and it seemed like it was correctly encoded, but will look into it some more.  So you are saying that libass does the line-splitting?  I was thinking maybe the text was split externally and each line fed to libass. I will also check some numbers for bidi operation.

I also tried it in ass, same problem, but in ass I could experiment with the "WrapStyle:" parameter and I found how periods got placed changed depending on if Wrapstyle 0 (smart wrap) or 2 (wrap at "\n" in the dialog text string) was set.  So I am guessing this is a libass issue and I opened new issue 565 on that project.

As an aside, some searching reveals this is a common issue in video players and an Arabic subber suggested reversing the placement of periods in the text string (i.e., first byte in the string is 0x2E).

scott s.
.

[scott967]

I d @scott967 I think I found a problem with RTL rendering.  I created a subrip srt subtitle with a long text string in Hebrew.  When rendered the text was split into 2 line.  The punctuation (periods) were correctly placed on the first line, but wrong on the second.

i have tested your subtitle, although you have shared not a physical file, sharing subtitle content as plain text on webpages i think could lose the embedded unicode characters for text orientation
i have noticed that your subtitle creates strange behaviour in other players as well, some example:

VLC:


Kodi 19:



i have tested also MPV, but in this case the displayed text is clearly incorrect...

i am not an RTL expert, but know that there are unicode characters that can be inserted for the purpose of correctly orienting parts of the text.
from what i understand we have the best results compared to other players

however the RTL/LTR is managed internally by LibAss and his dependencies not Kodi anymore
if it is not a problem with your file, this you will have to try to report it to LibAss github by providing the original subtitle file
(but of course you must also provide evidence that your file works correctly with at least one video player)

I did some more research on this.  This is what I think is happening: Libass assumes the text direction is LTR.  So the text is being properly handled per the unicode bidi algorithm.  The fix can be done in the sub text strings by using the unicode RTM control character following (logically) the terminal punctuation in the string.  That results in the bidi algorithm properly placing the punctuation.  An alternative would be if there is some way to pass a style parameter to libass to treat sub text strings as default RTL (a look at the source I didn't see an obvious way to do that).

But I haven't done a lot of checking, I have a feeling subbers are aware of this issue and work around by placing the punctuation characters at the logical beginning of the string.  If that's the case then it's probably not worth trying to make it more "correct" and just leave it to the subbers to add the unicode control chars where needed or use the work around.

scott s.
.

[CastagnaIT]

An alternative would be if there is some way to pass a style parameter to libass to treat sub text strings as default RTL (a look at the source I didn't see an obvious way to do that).

i remember to have done a kind of test by set to libass:

Code:

style->Encoding = -1;

where it made no difference with RTL

if you are able you can build kodi by adding the mentioned code near here:
https://github.com/xbmc/xbmc/blob/master...s.cpp#L320
but this will works only with adapted subtitles (like SRT) or for ASS case only when styles overrides settings are enabled

[Boilerplate4U]

@CastagnaIT Thanks for the clarification. I will test again once that PR makes it into a nightly.

1. Does "KodiSetup-20211018-258fe34f-master-x64.exe" include the necessary changes to start testing? 
2. I haven't checked the src for it yet but does the new renderer fix the relative positioning for all the options ie fixed, bottom, top, above? The current renderer does only allow to reposition using option "fixed".

[CastagnaIT]

@CastagnaIT Thanks for the clarification. I will test again once that PR makes it into a nightly.

1. Does "KodiSetup-20211018-258fe34f-master-x64.exe" include the necessary changes to start testing? 
2. I haven't checked the src for it yet but does the new renderer fix the relative positioning for all the options ie fixed, bottom, top, above? The current renderer does only allow to reposition using option "fixed".

1. In the first post there is your answer, so yes
2. I do not understand in full your question,
the subtitle Position setting have the same behaviour of Kodi 19,
the only thing changed is that "Fixed" (of Kodi 19) is now renamed as "Manual", this is to try make it clearer that it must be used with Video calibration settings,

but if you mean to ask for something different please elaborate again your question

[Boilerplate4U]

Thanks. 

Regarding the subtitle position I was thinking of the Action ID SubtitleShiftUp/SubtitleShiftDown (ACTION_SUBTITLE_VSHIFT_UP/DOWN) which moves the subtitles relative position up or down. It's the same when using the Calibration window. Last time I checked it was only working in "Fixed" mode but should IMHO work for all modes especially when you have altered font types and sizes.

I'll look at it a bit little later but if I remember it correctly then ACTION_SUBTITLE_VSHIFT_UP / DOWN was implemented in PlayerController.cpp

Settings -> Player -> Language -> Subtitle position on screen: 



Settings -> System -> Display -> Video calibration..

[CastagnaIT]

> Last time I checked it was only working in "Fixed" mode but should IMHO work for all modes especially when you have altered font types and sizes.

ah ok so basically this action is fired by CTRL+UP/DOWN
with this new system, it was not intended to leave the user free to force the subtitles to be moved vertically manually with the exception of "Manual" case
(where ofc is currently broken CTRL+UP/DOWN tested now with "manual" works)
this because completely invalidates the usefulness of all others "Subtitle position on screen" settings cases

if needed to force change the vertical margin, there is the possibility to set a custom vertical margin by using the advanced setting xml (see wiki: subtitleverticalmargin)

However i do not understand how the font size/type can affect the subtitle position
the subtitle position is automatically adjusted according to the size and orientation
please provide an example with the last kodi 20 nightly to show how font size/type affect the subtitle position

[Boilerplate4U]

if needed to force change the vertical margin, there is the possibility to set a custom vertical margin by using the advanced setting xml (see wiki: subtitleverticalmargin)

Ok, I'll check that out regarding v20. But in general I prefer change the position using the GUI (ie WYSIWYG) than having it set by a static value. That's why I think ACTION_SUBTITLE_VSHIFT_UP/DOWN should be usable for all modes.

Anyhow, I plan to have deeper look at ACTION_SUBTITLE_* implementation logic in PlayerController.cpp but since I currently don't have a working dev-environment for Kodi it will take a while. (This time I'll put everything in a virtual machine so I can move it around when needed)

[MrMagic]

@CastagnaIT Thanks for the clarification. I will test again once that PR makes it into a nightly.

So I've been playing around with @Maven 's latest Android test build for v20 (https://www.dropbox.com/sh/5fjkqnuvwa7z3...k3A8a?dl=0) which includes this PR now.

Subtitles look a lot better now with the increased border size, so thanks for that! I also really like the new color picker.

If there is one thing that I would like to see added it is the option to have two different color settings: one for HDR/Dolby Vision content and one for SDR content.

If I choose one of the darker grey colors to make subtitles less bright on HDR content, the subtitles look too dark on SDR content. And vice versa if I choose a brighter color that looks good in SDR, the subtitles kind of hurt your eyes with HDR content

[CastagnaIT]

if needed to force change the vertical margin, there is the possibility to set a custom vertical margin by using the advanced setting xml (see wiki: subtitleverticalmargin)

Ok, I'll check that out regarding v20. But in general I prefer change the position using the GUI (ie WYSIWYG) than having it set by a static value. That's why I think ACTION_SUBTITLE_VSHIFT_UP/DOWN should be usable for all modes.

Anyhow, I plan to have deeper look at ACTION_SUBTITLE_* implementation logic in PlayerController.cpp but since I currently don't have a working dev-environment for Kodi it will take a while. (This time I'll put everything in a virtual machine so I can move it around when needed)

i already know the source code without go in deep,
if you want us to consider this change you should provide a valid reason,
that's why i asked to provide an example for the problem that you have mentioned

if you need to set the position manually every time why you do not use the "Manual" position setting (where you can use the actions shorcuts)?
 

@CastagnaIT Thanks for the clarification. I will test again once that PR makes it into a nightly.

So I've been playing around with @Maven 's latest Android test build for v20 (https://www.dropbox.com/sh/5fjkqnuvwa7z3...k3A8a?dl=0) which includes this PR now.

Subtitles look a lot better now with the increased border size, so thanks for that! I also really like the new color picker.

If there is one thing that I would like to see added it is the option to have two different color settings: one for HDR/Dolby Vision content and one for SDR content.

If I choose one of the darker grey colors to make subtitles less bright on HDR content, the subtitles look too dark on SDR content. And vice versa if I choose a brighter color that looks good in SDR, the subtitles kind of hurt your eyes with HDR content

yes other people have mentioned this request for HDR content,
i am not sure if it is currently possible to implement something to change the colour automatically according to the type of video content
but we will take note of this