Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[YonathanZ]

Hi,

Are there plans to add proper support for Hebrew subtitles?
I'm aware of the method that is often suggested around here, which is to convert subtitle files to UTF-8 encoding using Notepad++, but the problem with this method is two fold:

1. It requires manually modifying a file for every single movie / TV show.
2. The result is far from perfect, with punctuation marks appears at the wrong side, and lines containing both letters and numbers appearing as, well, a mess.

Freeware software such as MPC-HC perfectly support Hebrew subs, but I prefer JRiver for its Theater Mode functionality (and audio playback capabilities), which is very useful when using a big screen.

[Hendrik]

Our entire internal text handling and processing is designed around Unicode text, so I'm afraid we will not be able to support ANSI encoded subtitles.
If you are having problems with Unicode/UTF-8 subtitles, then we will see what we can do about those - assuming they were actually converted correctly, and the punctuation problems are not caused by Notepad++ during the conversion.

[AndrewFG]

Our entire internal text handling and processing is designed around Unicode text, so I'm afraid we will not be able to support ANSI encoded subtitles.
If you are having problems with Unicode/UTF-8 subtitles, then we will see what we can do about those - assuming they were actually converted correctly, and the punctuation problems are not caused by Notepad++ during the conversion.

Hendrik, I think that his question is not about the encoding of the character set. I think his issue is about the on screen text writing direction "left-to-right" (LTR) versus "right-to-left" (RTL). I am pretty sure that Unicode/UTF-8 are just fine for encoding the characters in RTL languages like Hebrew or Arabic. But the issue is whether you are properly using the RTL writing APIs to write those texts to screen. I know that most of the Windows text writing APIs do have a LTR / RTL flag which you must set when you make the call to write RTL. And as far as I know it, you are using customized non OS specific writing API's for platform independence, which I suppose may not (fully) support an LTR / RTL flag on them. Or??

For example when calling the Windows DrawText() API call ( https://msdn.microsoft.com/en-us/library/dd162498(v=vs.85).aspx ) you have to include DT_RTLREADING in the passed flag set..

[Hendrik]

He clearly mentioned having to convert to UTF-8, which indicates his original files are not. I don't see how that would mean anything else. There isn't much room for interpretation in the original post.
Also, we support RTL text layout just fine, but of course that doesn't mean there couldn't be a bug in there somewhere.

[AndrewFG]

He clearly mentioned having to convert to UTF-8, which indicates his original files are not. I don't see how that would mean anything else. There isn't much room for interpretation in the original post.

Hendrik, I was referring to his 2nd point -- "the result is far from perfect, with punctuation marks appears at the wrong side, and lines containing both letters and numbers appearing as, well, a mess" -- from my experience such mis-positioning of letters (RTL), numbers (LTR), and punctuation marks (LTR), is a sure sign of some kind of mix up over the API writing direction.

Also, we support RTL text layout just fine, but of course that doesn't mean there couldn't be a bug in there somewhere.

I think the OP would need to post some screen shot examples. YonathanZ could you please do that ??

[Hendrik]

Hendrik, I was referring to his 2nd point

He seemed to put far more emphasis on his first point, which I can't really do much about, which is what my post was also targeted at.
Its also a possibility such a conversion could result in a "wrong" UTF-8 script if not done properly, hence further comments on that.

I think the OP would need to post some screen shot examples. YonathanZ could you please do that ??

Screenshots don't help, subtitle script files would (.srt's), preferably as Unicode (UTF-8 or UTF-16) as I can't read anything else.
It makes no sense to speculate what kind of flag might be missing where, our entire font engine is custom and only uses the lowest level OS functions needed.

[AndrewFG]

You don't need to be able to actually read the texts. I've done work on Chinese, Japanese, Korean, Arabic, Hebrew and Russian, and I can assure you that "you know it when it's wrong"..

[Hendrik]

You don't need to be able to actually read the texts. I've done work on Chinese, Japanese, Korean, Arabic, Hebrew and Russian, and I can assure you that "you know it when it's wrong"..

"Read" as in "have MC read the file", as I can't even parse ANSI Hebrew encoded files to get any kind of usable data without a lot of manual labor since my system doesn't have the Hebrew codepages, thats the entire point of having Unicode. Why would Unicode otherwise make a difference? It doesn't automatically translate to english. :p
In any case, maybe we can let YonathanZ come back with some info now, instead of questioning every of my requests?

[AndrewFG]

Hendrik, I am not "questioning" you. I am offering you my experience. My two areas of highest expertise are UPNP and multi language writing.

[YonathanZ]

It is possible that problem no. 2 is due to the conversion process and not the way JRiver reads the file. Then again, I have no idea how to fix it.

[raphaelof]

Hi Yonatan
did you solve this problem?
I'm planing to purchase MC and use it as my main media player, but if this problem is not solved and i cant use hebrew subs, then i'll be looking for another MP