Styleruns - OSX vs Windows

I have a need to parse the stylerun data of a textarea and use that information to populate another file …
But I have found that OSX breaks up the styleruns one way, and Windows another.

My test app populates a text area programmaticlly with various styles, colors etc for testing.
I need to read each style run, and write out the text and style information…
here is where the error is… I need to write a new line of text for each lineending in the textarea… and a single style run can contain any number of lines.
But Windows does not break the styleruns in the same place in regards to CR/LF it seems

here is a hex dump from OSX running the app


Run #0
54 68 69 73 20 
Run #1
69 73 
Run #2
20 74 68 65 20 
Run #3
74 65 78 74 
Run #4
20 
Run #5
74 68 61 74 20 0D 0A 
77 65 20 61 72 65 20 67 
6F 69 6E 67 20 74 6F 20 73 61 76 65 20 69 6E 74 
6F 20 6F 75 72 20 66 69 6C 65 20 66 72 6F 6D 20 
74 68 65 20 54 65 78 74 41 72 65 61 2E 0D 0A 
Run #6
49 73 6E 27 74 20 74 68 61 74 20 26 74 72 61 
64 65 3B 20 69 6E 74 65 72 65 73 74 69 6E 67 3F 
0D 0A 
Run #7
4D 61 6E 2C 20 49 20 73 75 72 65 20 64 6F 20 
6C 6F 76 65 20 75 73 69 6E 67 20 74 68 69 73 20 
74 6F 20 6D 61 6B 65 20 50 44 46 20 46 69 6C 65 
73 21 2E 

and here is how WIndows does the EXACT SAME Data


Run #0
54 68 69 73 20 
Run #1
69 73 
Run #2
20 74 68 65 20 
Run #3
74 65 78 74 
Run #4
20 
Run #5
74 68 61 74 20 0D 0A 
77 65 20 61 72 65 20 67 
6F 69 6E 67 20 74 6F 20 73 61 76 65 20 69 6E 74 
6F 20 6F 75 72 20 66 69 6C 65 20 66 72 6F 6D 20 
74 68 65 20 54 65 78 74 41 72 65 61 2E 
Run #6
0D 0A 
49 73 6E 27 74 20 74 68 61 74 20 26 74 
72 61 64 65 3B 20 69 6E 74 65 72 65 73 74 69 6E 
67 
Run #7
3F 0D 0A 
4D 61 6E 2C 20 49 20 73 75 72 65 20 
64 6F 20 6C 6F 76 65 20 75 73 69 6E 67 20 74 68 
69 73 20 74 6F 20 6D 61 6B 65 20 50 44 46 20 46 
69 6C 65 73 21 2E 

Run #5 - the OD 0A are at the START of Run 6 in Windows
Run #6 - the 3F 0D 0A are at the START of Run 7 in Windows

here is the code that produced the above

  For j=0 To st.StyleRunCount-1
    s=st.StyleRun(j).Text
    //
    s=ReplaceLineEndings(s,EndOfLine.Windows) ' put in 0x0D0A
    tt.WriteLine endofline.unix+"Run #"+str(j)
    for k=1 to len(s)
      tt.write right("00"+hex(ascb(mid(s,k,1))),2)+" "
      if (ascb(mid(s,k,1))=10 or (k and 15)=15) and k<len(s) then tt.WriteLine
    next k
    tt.writeline

And YES, I am changing the EndofLine… this is so I can split on 0x0A, but still know if I need a “new line” by virtue of the 0xOD the would be there. This is to handle situations where there are multiple styleruns on the same line. And as you can see I change the variable AFTER I take if from the stylerun set.

Any idea for a workaround ?

Found it… turns out that when I populated the textarea, I used the platform specific endofline
but when I applied the styles

  st.size(0,Len(st.Text))=30
  st.Bold(5, 2) = True
  st.TextColor(5, 2) = &cFF0000 //Bold and red
  st.Size( 7, 10) = 16
  st.Underline(12, 4) = True //16 pt underline
  st.Size(100, 4) = 18
  st.TextColor(100, 4) = &cFF00FF //18 pt and Magenta
  st.Font(0, Len(st.Text) ) = "Arial"

I didn’t take into account the additonal offset because the Windows EOL is 2 characters in size, so the Styleruns really DID break at different places…

I also had to learn to use CHR(13) only for this.

Adding CRLF for me shifts alignment.