Differences in end of line characters Mac, Windows, and Linux
The differences between platforms end of line characters can cause a problem when importing point files produced on older Macintosh computers. The problem is how we handle ASCII text data files that end in a carrige return character.
How ASCII text files are represented are different on different operating systems. Take for example the following 3 line file:
1.0 2.0 0.0
1.0 2.1 1.0
1.1 2.1 0.0
How the end of the lines are stored is different depending on if you are using Windows, Macintosh, or Unix. There are two different characters that are not visible that are used to indicate the end of a line. They include the carridge return character "referred to as <CR>" and the linefeed character "referred to as<LF>". Things are further complicated because the Macintosh platform made a substantial change when Mac OS X was released. Mac OS X is based on a Unix core thus Mac OS X ascii files have the same default as Linux nodays.
Here is how the different platforms end lines in ASCII files.
Windows - Lines end with both a <CR> followed by a <LF> character
Linux - Lines end with only a <LF> character
Macintosh (Mac OSX) - Lines end with only a <LF> character
Macintosh (old) - Lines end with only a <CR> character
Fledermaus will have problems reading the old style Macintosh ascii files that end only in a <CR>. Fortnately the use of this style of ascii files is going away but there are still cases where these files will be generated (usually be some applications running on the Mac platform).
Where does this problem show up:
For example in Fledermaus if you use Import > Import Points and select an ascii file that ends with only the <CR> file you will get and error dialog saying that no data was read.
On the Mac platform the most likely source of this problem is data exported from Microsofts Excel program. When you want to export a spreadsheet, the first option you still will read "Macintosh Ascii File". If you select this it writes an oldstyle Mac ascii file that has the problem. If you look further down the list there will be a "Windows Ascii File." Selecting that option instead will avoid the issue described here.
On the Mac you can identify the type of ascii file by running the "file" command in a terminal windows:
You will see output that looks something like:
myasciifile.txt: ASCII text, with CR line terminators, or
myasciifile.txt: ASCII text, with CRLF line terminators, or
myasciifile.txt: ASCII text, with LF line terminators depending on what type of ascii file you have.
If you are using Mac OS X, or Linux there is a command line method to convert a oldstyle mac into the Windows style. Run the following command:
sed -e '1,$s/\r$/\r\n/' < myasciifile.txt > myasciifilefixed.txt