The VideoLAN Forums

You should retry again with latest master

You should retry again with latest master

I was talking about the trunk, the new version is of the branch.

@j-b: I have tried the 0.9.3 2008-09-22 - 1653 and I don't see anything new about subtitles, what do you refer?
Edit: Maybe I haven't understand correctly your message.

@fenrir: About "\fr" and "\an" and also all other A.S.S tags that I don't have talked about it would be better enable them also for SRT rather then create duplicate code.

@j-b: I have tried the 0.9.3 2008-09-22 - 1653 and I don't see anything new about subtitles, what do you refer?
Edit: Maybe I haven't understand correctly your message.

@fenrir: About "\fr" and "\an" and also all other A.S.S tags that I don't have talked about it would be better enable them also for SRT rather then create duplicate code.

I see absolutely NO reason why we should EVER support A.S.S. markup in SRT subtitles. They are 2 different things, with two different purposes. It's terrible enough already in my opinion that we are implementing "full-HTML" support for what was designed to be a "plain text" format. MPC should wake up and learn to follow some standards, even those that are arguably poorly defined.

I even vote for removal of {\an}. The fact that SRT does not have features like this, is no reason to start implementing randomly troughout some applications. SRT is for text, SSA is for anime-fans.

Pick one, go with it, don't complain if SRT does not do what SSA is supposed to do.

DJ

Oh, and even the aegisub devs share this opinion. Which is the only group atm as far as I'm concerned that know what they are doing with subs.

I see absolutely NO reason why we should EVER support A.S.S. markup in SRT subtitles. They are 2 different things, with two different purposes. It's terrible enough already in my opinion that we are implementing "full-HTML" support for what was designed to be a "plain text" format. MPC should wake up and learn to follow some standards, even those that are arguably poorly defined.

It was designed to be a "plain text" format but it was extended and I don't see why don't support it, tags are alredy implemented for A.S.S. subtitles just need to be enable also for SRT with minor efforts.
There are real stardards and "de-facto" standards.

I see absolutely NO reason why we should EVER support A.S.S. markup in SRT subtitles. They are 2 different things, with two different purposes. It's terrible enough already in my opinion that we are implementing "full-HTML" support for what was designed to be a "plain text" format. MPC should wake up and learn to follow some standards, even those that are arguably poorly defined.

I even vote for removal of {\an}. The fact that SRT does not have features like this, is no reason to start implementing randomly troughout some applications. SRT is for text, SSA is for anime-fans.

Pick one, go with it, don't complain if SRT does not do what SSA is supposed to do.

DJ

It was designed to be a "plain text" format but it was extended and I don't see why don't support it, tags are alredy implemented for A.S.S. subtitles just need to be enable also for SRT with minor efforts.
There are real stardards and de-facto standards.

No, it is not de-facto standard.

De-facto standard is plain text and HTML subtitles. {\***} is SSA, not SRT, no matter what you say.

However, I don't care if those are added, since I doubt some legit subtitles would use {\ } in there translations.

However, I don't care if those are added, since I doubt some legit subtitles would use {\ } in there translations.

Fansubs are made by fans so the "legit subtitles" doesn't always applies.

However, I don't care if those are added, since I doubt some legit subtitles would use {\ } in there translations.

Fansubs are made by fans so the "legit subtitles" doesn't always applies.

If they do fansubbing, then use SSA, it is done for that.

I really think that everyone has the right to choose what format want to use.

I really think that everyone has the right to choose what format want to use.

Everyone has the right to do so. But they also should respect the format's specification. As pointed out by others, SSA tags were never meant to be used in SRT files. It's like if you were using diesel in your chimney ... it's not meant to be used there, even if people pretend that it should work.

SRT hasn't a real format's specification.
I don't know how that thing has started but it exist and it is used.

Ok. Let's stop the troll here.

{\an } will be supported (you should update your graphs, I think ). However, don't expect all SSA tags to be supported inside SRT for VLC, even if MPC people find it nice.

I don't want to troll, I was just my opinion.

Well, 0923 is out, IIRC.

Moreover, italics and bold work PERFECTLY for me.

Now it reach 14 points, impressive improvement in only one day.

Can you give me a build with debug messages specific to bold and italic, please?
Because I always delete "preference and cache" and it still don't work.

I am afraid this is a Windows/Linux issue.

Moreover, italics and bold work PERFECTLY for me.

on very last branch built it doesn't here (xp sp2)
doesn't work if using arialbd font or vlc font.

sorry if you were talking about vlc 1.0 which i didn't test yet =)

I really think that everyone has the right to choose what format want to use.

The one reason this "works" in some players is because several players/renderers take SRT subtitles and CONVERT them to SSA/A.S.S. and render them with VSFilter or something like that. So if there happens to already be some A.S.S code in them then this will be parsed. This is an ERROR. It should not be handled by the renderer, because it should only handle the HTML markup. Just because some people reuse VSFilter to render SRT and other types of subtitles by converting them to SSA is no reason for us to make the same mistake. It is non-strictness like this which leads to format->format conversion errors. If i write a SRT->pure text converter, I do not expect there to be ASS markup tags, which becomes a problem the moment i'm getting invalid stuff like this. As I am sure fansub groups are gonna want to try and "exploit" this strictness in our code, I think i will be adding an "ignore" for {\*} in the renderer. Then you can no longer use {\string} (which is a normal string in SRT), but i rather have that than anime subber groups putting {\VLC sucks because it renders this string} in all their subtitles.

Edit: Post removed

Edit: Post removed

i am a Mac user

i use Niceplayer (for OS X) for a few videos with subs that wont play right in VLC (mainly videos in a .mkv). i have a few videos with colored subs in different fonts.

but for everything else there is VLC. only if it will play the subs of a movie, if it dont i use another video player. i hope the developers of VLC will start working on better sub support

I believe VLC implemented many stuffs for this. Can you try 1.1 ?

I believe VLC implemented many stuffs for this. Can you try 1.1 ?

Strikethrough and font face work now. Plus all the bold/italic/underline things.