[MPlayer-dev-eng] Small changes to subreader.c file
Ergzay
ergzay at everyoneproductions.com
Sat Oct 8 03:46:46 CEST 2005
On 2005/10/07, at 20:57, Rich Felker wrote:
> On Fri, Oct 07, 2005 at 04:21:29PM -0500, Joey Parrish wrote:
>> On Fri, Oct 07, 2005 at 03:43:42PM -0400, Rich Felker wrote:
>>> On Thu, Oct 06, 2005 at 12:22:00PM +0200, Adam Tla??ka wrote:
>>>> Hello,
>>>> I am sending a small patch which adds "\r\n" (DOS line endings) to
>>>> dump_srt function
>>>> which is a bug correction because SRT is really a DOS format and
>>>> will not
>>>> be
>>>> properly read with Unix like "\n" line endings.
>>>
>>> This is not a bug. .srt files are text files and as such should be
>>> stored in (standard) unix text format. If windows/dos/mac/etc users
>>> want to use them they can apply the appropriate (broken) textfile
>>> conversions.
>>
>> I disagree. If we are dealing with a text-based format, we should be
>> able to read CR or LF or CRLF. If we are writing it, we should write
>
> We can read either.
>
>> whatever is either 1) standard or 2) most compatible. If there is no
>> SRT standard spec, this means we should output CRLF.
>>
>> Is there an SRT standard?
>
> No, none of this windows-originated crap has specs. It's just a text
> file. And I'm totally against ever writing \r's into text files! If
> someone wants to put \r in there they can do it with a simple script.
> If you really insist we can open the file in "w" mode instead of "wb"
> so it gets the \r crap if you run it on windows...
I'm for adding support for the \n and \r. I see these in softsubs of
some dvd rips. It gets rather annoying. They should be either 1.
ignored completely so that they don't show up or 2. (better solution)
use them so that /n makes a new line.
More information about the MPlayer-dev-eng
mailing list