End of Line character problems

[cricketbird]

I'm trying to export text from Revolution via the write to file command, and open it using a program that reads Multimarkdown language (Scrivener).

If I open the .txt file that Revolution generates directly in Scrivener, only the first line of the file appears.

However, if I open it in TextWrangler and save as a file with Unix line breaks instead, then the file opens correctly.

According to TextWrangler, Unix line breaks are the ASCII 10 character, which is exactly what Revolution says it uses when you use the return constant.

I've tried using both return and numToChar(10), but I always have to open the file in TextWrangler and save as in order to get my entire file and not just the first line.

How can I get Revolution to put the right end-of-line character so I can read more than the first line of my file?

[FourthWorld]

Without seeing your code I can only guess as to what's going on, but it sounds like maybe you're opening the file in binary mode, which would use Rev's native line endings, as opposed to text mode which automatically translates line endings to whatever's customary on the platform it's running on:

Mac: CR (ASCII 13)
Win: CRLF (ASCII 13+ASCII 10)
Linux: LF (ASCII 10)

It seems Scrivener expects only Mac-native line endings.

If this is true, you can change what I'm guessing is currently this:

Code: Select all

open tFile file for binary write

...to this:

Code: Select all

open file tFile for write

...since "text" is the default mode. You can also use:

Code: Select all

open file tFile for text write

...if you want to me explicit.

If my assumptions are wrong and this doesn't fix it, post your code so we can see what's happening.

As a side note, it may be worth submitting a feature request to the folks who make Scrivener to allow it to detect and account for text using any of the three common line endings, since over time I'm sure they'll find customers working with text from different platforms if they haven't encountered this already.

[cricketbird]

Thanks for the feedback, FourthWorld!

Here's my code:

Code: Select all

 ask file "Enter new file name" with mysuggestedfilename
   if the result = "cancel" then
      exit mouseup
   end if
   
   put it into myfile
   open file myfile for append
   put the number of cards into thecardnum
  
repeat with i = 1 to thecardnum
      replace return with empty in field data1 of card i
      replace return with empty in field data2 of card i
      write "# " & field data1 of card i & numToChar(13) & numToChar(13) & field data2 of card i & numToChar(13) & numToChar(13) & numToChar(13) to file myfile at EOF
   end repeat
  

I've tried this with return, numToChar(10) and the current numToChar(13) with the same results.

The first two lines of the repeat are there to make sure there are no extra returns in the fields that would interfere with the intended output format. Could this be messing it up?

For the record, the output should look like this (in a .txt file)

Code: Select all

# data 1 (from card 1)

data 2 (from card 1)

# data 1 (from card 2)

data 2 (from card 2)

Also, when I open the resulting text file, it does "look" right, even when viewing invisible characters (ie returns are hard returns, not soft returns, etc.).

Heidi, living in the third world

[FourthWorld]

I was going to see if I could simplify the code a bit, but I'm not clear on something: why do you strip the CRs from the field data?

[cricketbird]

I strip the fields of CRs so that the internal CRs don't mess up the format I need. I need each line to be separated by two CRs, and three between records (cards). If there were CRs in the fields themselves, then they might mess up the importation of my records into scrivener.

The fields are short enough they probably will never have a CR in them anyway, but in the name of troubleshooting I wanted to be sure the only CRs were the ones I put there in the code I pasted earlier.

[FourthWorld]

I wonder if the problem may be on Scrivener's side. Do you have a spec for the format they're expecting?

[cricketbird]

Backing up with more info about the big picture - I've been wanting a note taking application, and then a corkboard viewer to view all my notes and arrange them visually. It was a breeze to get Revolution to make my notecards to function the way I like, but I'm not a good enough programmer to get the corkboard layout. However, Scrivener has an excellent corkboard and furthermore excellent writing tools for when I write up my research.

Based on this thread:

http://www.literatureandlatte.com/forum ... own+import

I thought I'd get Revolution to export my notes to Scrivener, but am stuck. Documentation about the Multimarkdown format is at:

fletcherpenney.net/multimarkdown/

fletcherpenney.net/multimarkdown/using_ ... ith_scriv/

So, I'm not sure if the problem is at Revolution's export, Scrivener or multimarkdown. But, since the file is nice once it gets converted to UNIX format, I think it's Revolution.

Thanks again,
Heidi

[FourthWorld]

Rev's fine; it's just your script.

We can fix that, but it does seem unnecessarily limited that Scrivener only works with Unix line endings. Text can come from any platform, and it would be simple for Scrivener to do as flexible a job with reading text as Rev's "read from file" command (which automatically translates line endings on the fly).

In fact, it's that line ending thing that seems to be the issue. As I noted in my first post here, using "open file tFile for write" will open the file in "text" mode, which causes the Rev engine to convert any line endings to whatever's customary on the OS the engine is running on at the time.

Since you're running on Mac, regardless what line ending you use while you're assembling your data, when it's written out the write command will write with Mac line endings.

To handle Scrivener's finickiness, you'll need to make sure that your line endings are written exactly as you put them together. So first, change your "open file" command to use binary mode:

Code: Select all

 open file myfile for binary append 

Then instead of "numtoChar(13)" use "numtochar(10)" (or simply "cr", which internally is the same as numtochar(10) ).

With those changes you'll be putting the text together using Unix conventions, and writing it out in binary form so the engine won't alter the line endings as it does in text (the default) mode.