The L SEP character
Posted: Wed Oct 03, 2018 3:57 am
L SEP is a mysterious character that I have recently encountered on the web. Apparently it is used in HTML as a line feed. It has its place in the ASCII table as character 8232.
I found that it also acts as a line feed in Smart Basic, with one major difference from the carriage return CHR$(13) or line feed CHR$(10). It does not cause a syntax error when L SEPs are included in a text string!
Here is an example of a perfectly legal string definition:
test2$="Today I am your chariot horse Tomorrow I'm your albatross Suspended by the finest thread No one could ever see And when there's breathing in your ear You put your faith in all you hear But just how deep those feelings go I have no way to know I'll never know" It contains 8 L SEPs!
Notice that on the Forum, these L SEP characters do not cause line feeds, and are invisible. But when viewed in Smart Basic's Editor, that same code looks like this, yet gives no syntax error.
test2$="Today I am your chariot horse
Tomorrow I'm your albatross
Suspended by the finest thread
No one could ever see
And when there's breathing in your ear
You put your faith in all you hear
But just how deep those feelings go
I have no way to know
I'll never know"
More weirdness: if you obtain the length of this test string using the SB LEN command, the result with be 8 higher than the count of visible characters. Fortunately SB string commands can identify, count and generally process the L SEP character.
I had problems when I tried sending strings that contained CHR$(8232) characters to a PC print server. The PC does NOT recognize LSEP characters as line feeds. It prints them instead as actual printable characters, such as shown here:
This character appears blank in an ASCII printout done in Smart Basic. That surprises me since iOS and Windows are compatible with the same fonts. Why don't we see the same L SEP font character in iOS that appears in Windows?
I had to come up with a method to identify ASCII 8232 and substitute standard CR and LF characters before I could print properly using a Windows print server. I will post that tomorrow.
I found that it also acts as a line feed in Smart Basic, with one major difference from the carriage return CHR$(13) or line feed CHR$(10). It does not cause a syntax error when L SEPs are included in a text string!
Here is an example of a perfectly legal string definition:
test2$="Today I am your chariot horse Tomorrow I'm your albatross Suspended by the finest thread No one could ever see And when there's breathing in your ear You put your faith in all you hear But just how deep those feelings go I have no way to know I'll never know" It contains 8 L SEPs!
Notice that on the Forum, these L SEP characters do not cause line feeds, and are invisible. But when viewed in Smart Basic's Editor, that same code looks like this, yet gives no syntax error.
test2$="Today I am your chariot horse
Tomorrow I'm your albatross
Suspended by the finest thread
No one could ever see
And when there's breathing in your ear
You put your faith in all you hear
But just how deep those feelings go
I have no way to know
I'll never know"
More weirdness: if you obtain the length of this test string using the SB LEN command, the result with be 8 higher than the count of visible characters. Fortunately SB string commands can identify, count and generally process the L SEP character.
I had problems when I tried sending strings that contained CHR$(8232) characters to a PC print server. The PC does NOT recognize LSEP characters as line feeds. It prints them instead as actual printable characters, such as shown here:
- E585777D-385B-4F49-B7A0-C1256DB35362.jpeg (98.94 KiB) Viewed 1419 times
I had to come up with a method to identify ASCII 8232 and substitute standard CR and LF characters before I could print properly using a Windows print server. I will post that tomorrow.