opening txt files

Robert Sneidar slylabs13 at
Wed Jan 16 00:27:15 EST 2013

I did that earlier. There are no encoding options available in the export dialog. It is possible that based on the system and language settings at the time the file is exported that the encoding might be set to Unicode, but I couldn't find anything by googling for it. 

Bob Sneidar
IT Manager
Calvary Chapel CM
Sent from iPhone

On Jan 15, 2013, at 21:19, Kay C Lan <lan.kc.macmail at> wrote:

> What happens when you open the Pages converted file in TextEdit, does
> it have the extra spaces? If so the problem is with the conversion
> process from Pages, not with LC. If so you need to look at some of the
> conversion options Pages offers and see if you can create the file
> without the extra spaces.
> If TextEdit opens the converted file just fine, then you may need to
> download the free TextWrangler:
> You can the select 'Show invisibles' from the 'T' toolbar icon.
> If that doesn't reveal anything then use 'Zap Gremlins...' option in
> the Text menu. Tick the boxes, use 'Replace with' and put in your own
> distinct character. This will then highlight if there are any chars
> that Pages is leaving behind that TextEdit is interpreting as
> non-visible but LC is interpreting as a space.
> If all else fails, assuming you have that selects the file and puts it
> in a variable, I'll call tData, and you have a breakpoint immediately
> after this, when you look at the variable tData it looks like this: H
> E L L O...
> So in the next line of you script after the breakpoint put:
> --to determine the ASCII number of the bad character
> put charToNum(char 2 of tData) into tBadChar
> run your script again, when it stops at the breakpoint step once so
> the above line is executed then check what is in tBadChar.
> Hopefully it won't be 32 - which is what a regular space is. You
> should be careful though, as there may be a bad character before the H
> so maybe the number you get is for the H. Basically any number between
> 32-126 is probably valid. Anything outside this range is likely to be
> the cause of your problem. So you may need to test char 1, char 2 and
> char 3 just to make sure you are looking at the Bad character.
> Once you've positively identified the ASCII value of the bad character
> then simply add this further line of script after the last line you
> added:
> --replace bad ASCII with nothing
> replace numToChar(tBadChar) with "" in tData
> Again, if the number is 32 this means Pages is doing the wrong thing
> with it's conversion and it's Page's problem, and it would be nigh
> impossible for LC to repair this.
> On Wed, Jan 16, 2013 at 2:34 AM, NISHOK LOVE < at> wrote:
>> Hi All
>> I have a problem when I open .txt files in OSX, and I don't have much (any!) experience of reading files in LiveCode.
>> I have a file originally written in Word on Windows. When I export it as a .txt from Word for Mac I just accept the default Mac OS encoding option (Western (Mac OS Roman) and it all works fine when I open the file in my LiveCode.
>> But when I open the original file in Pages and export it as Plain Text, I get a different result. When I open that file in LiveCode I find a space has been inserted after every character. So Hello world becomes H e l l o   w o r l d.
>> I guess this is a problem with the encoding, but how can my LiveCode understand what the incoming file's encoding is and respond accordingly? My LiveCode needs to be able to deal with any kind of text file...
>> Thanks,
>> Nishok Love
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the use-livecode mailing list