Note about philosophy around universal newlines

README.rst

@@ -158,9 +158,23 @@ Testing
 .. _`Detailed API documentation`: http://srt.readthedocs.org/en/latest/api.html
 .. _`tools shipped with the library`: https://github.com/cdown/srt/tree/develop/srt_tools
 
-Windows support
----------------
+Newlines
+--------
 
-Windows is supported, both from a code perspective (as tested on Appveyor), and in that we actively support CRLF line endings.
+If you are reading or writing to a file, you should use `universal newlines`_.
+All newlines will be represented internally as `\n` and will be properly
+converted during reading and writing to your system's line separator.
 
-If you are running Windows, everything should work as you expect. If you are not, I suggest that you use 
+If you are *not* reading from a file, but from a string, both `\r\n` and `\n`
+are accepted as line separators, but *only* `\n` will ever be output from srt.
+This permits reasonable output via the aforementioned universal newlines
+feature. If you want another format without universal newline support (or, for
+example, because you are not writing back to a file), it's your responsibility
+to do that through something like this:
+
+.. code:: python
+
+    for sub in subtitles:
+        sub.content = sub.content.replace('\n', os.linesep)
+
+.. _`universal newlines`: https://www.python.org/dev/peps/pep-0278/

srt.py

@@ -303,8 +303,8 @@ def parse(srt):
         raw_index, raw_start, raw_end, proprietary, content = match.groups()
         yield Subtitle(
             index=int(raw_index), start=srt_timestamp_to_timedelta(raw_start),
-            end=srt_timestamp_to_timedelta(raw_end), content=content,
-            proprietary=proprietary,
+            end=srt_timestamp_to_timedelta(raw_end),
+            content=content.replace('\r\n', '\n'), proprietary=proprietary,
         )
 
         expected_start = match.end()