Qt-interest Archive, April 2007
Re: Line Endings on Qt/Mac
Message 1 in thread
XCode can be set to do the LF/CR thing as well as TextMate
(inexpensive and good) As alway, MS tends to make us choose a least
common denominator.
-Tom
On Mar 11, 2007, at 3:53 PM, Keith Esau wrote:
> I consider this a bug in Qt.
>
> Ever since files started getting exchanged between platforms (18+
> years ago at least), the probability of reading a file written on a
> different platform has continually increased to the point that it
> should be expected. Thus, a 'line' can end with CR, LF, or LF/CR
> pair. Even worse, not all lines in the same file are ensured to end
> the same way. (Visual Studio 6 is a prime example-when editing a
> file from a different platform, only changed lines get CR/LF.)
>
> Any 'text' reader that does not allow any mixture of line endings
> has a major flaw. Assuming that only the particular platform's line
> endings will be found assumes that the user is in an isolated
> environment, and in today's day and age is myopic. I, for instance,
> often load old Mac CDs to get archived CR only text files, even
> though my (Unix-based) Mac is now LF only. (Not to mention that
> Xcode lets you use any line ending of your choice.)
>
> Writing text lines is a separate matter altogether. (In that case,
> write the specified ending, platform as default.)
>
> Keith
>
> On 03-05-2007 10:56 PM, "Derek Ditch" wrote:
>
>> I'm trying to open a CSV file that was exported using MS Excel
>> 2004 on Mac and Qt/Mac 4.2.1. The file uses Mac line endings, CR
>> (\r, carriage returns). Reading the QFile documentation, it seems
>> in text mode, CRLF will be automatically converted to LF. However,
>> I guess since this file only has CR, this conversion isn't done.
>> This causes my entire CSV to be read in using a single
>> QTextStream::readLine() call, which obviously isn't ideal. A quick
>> cat oldfile.csv | tr "\015" "\012" > newfile.csv
>>
>> will fix the issue. Is there a way to handle this with either a
>> QFile or QTextStream without using a series of QIODevice::getChar
>> () calls?
>>
>> I looked deeper to see what causes this, and I find this in
>> qtextstream.cpp:
>>
>> 694 : if (delimiter == Space && ch.isSpace()) {
>> 695 : foundToken = true;
>> 696 : delimSize = 1;
>>
>> where ch is a QChar. I'm not really that familiar with Unicode,
>> is CR considered a QChar::Seperator_Line? For now, I'm just gonna
>> use the tr line above, but I think the CR and LF and CRLF should
>> be considered in the TextMode conversions.
>>
>> Thanks,
>>
>> Derek
