[Bug 717826] Re: Scour emits CR CR LF for newlines on Inkscape/Windows

[CoDEmanX]

Never mind, Python 2 doesn't support it...

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to scour in Ubuntu.
https://bugs.launchpad.net/bugs/717826

Title:
  Scour emits CR CR LF for newlines on Inkscape/Windows

Status in Inkscape:
  Fix Released
Status in Scour:
  Fix Released
Status in scour package in Ubuntu:
  Fix Released

Bug description:
  Currently, under Windows, Scour produces newlines of the form \r\r\n
  (=CR-CR-LF or \x0D\x0D\0A), which is not only wrong, but gets
  displaced as an additional blank line between every svg code line in
  Unicode editors (and might perhaps confuse older text editors).

  There is a unittest designed to catch such an error, namely,
  EnsureLineEndings, but the error only occurs after writing the
  document to disk, while the unittest investigates the string produced
  by scour before writing the document to disk.

  
  How does it happen?

  Python, following C, tries to shield programmers from OS related
  newline troubles, so you can always use \n as the newline character:
  if you read a file in text mode, os.linesep gets replaced with '\n',
  and when you write a file in text mode, '\n' gets replaced with
  os.linesep.

  Scour, when serializing the svg document, directly uses os.linesep
  instead of '\n', and on Windows systems, os.linesep is '\r\n'. Then it
  saves the file in text mode, and Python replaces '\n' with '\r\n',
  which means that '\r\n' is replaced with '\r\r\n'.

  What is rather confusing is that when I'm using Scour as an export
  filter for Inkscape, the line ending actually becomes '\r\n'. In this
  case, Scour sends the resulting file via sys.stdout.write(), and the
  default mode for sys.stdout.write() is 'text mode', which means that
  sys.stdout.write() also should replace '\n' with '\r\n' and '\r\n'
  with '\r\r\n'.

  Since Inkscape uses '\n' as the line ending if I save files without
  Scour as the export filter, I suspect that Inkscape somehow is
  replacing '\r\n' with '\n' after reading the document from stdin and
  before saving it to a file, which obviously turns '\r\r\n' into
  '\r\n', but that's just a guess, and frankly, I have no idea what is
  going on inside Inkscape.

  
  How *not* to fix it?

  The usual way would be to get rid of all the os.linesep and simply
  replace them with '\n'. Unfortunately, while that would work just fine
  if Scour is called from the command line to convert one file into
  another file, I guess it would screw Inkscape. This was the behavior
  of Scour before revision 153, and the purpose of revision 153 was to
  fix bug #482215 that Scour, used in conjunction with Inkscape,
  produced the line ending '\n' on Windows. So replacing os.linesep with
  '\n' within the code of Scour probably wouldn't work.

  
  How to fix it (I think):

  The alternative is: keep os.linesep, but save the file in binary mode
  instead of text mode, thereby suppressing Python from doing its magic.
  Instead of using

      outfile = maybe_gziped_file(options.outfilename, "w")

  within parse_args() that means replacing that line with

      outfile = maybe_gziped_file(options.outfilename, "wb")

  instead. Since this change doesn't affect sys.stdout, it shouldn't
  break the interaction with Inkscape. And on Linux/Mac OS X, changing
  from text mode to binary mode doesn't make any difference at all. And
  it should work with both gzipped and uncompressed files.

To manage notifications about this bug go to:
https://bugs.launchpad.net/inkscape/+bug/717826/+subscriptions