REPLY: 1:3634/12.73 5cc48d32   
   MSGID: 2:280/464.113 5cc49588   
   Hallo mark!   
      
    ml> i keep wanting to say that QWK uses that i character for its EOL   
    ml> but it doesn't... it uses 0xe3...   
      
   That is a safe one as far as the MS encodings are concerned but a waste of a   
   character used in math (symbol for pi) in CP437.  I for one would strongly   
   protest by NEVER using QWK.  Hmm ... come to think of it I never liked nor   
   used QWK although I have looked at the format in the past.  You've just given   
   me another great reason for disliking it.  Thank you.   
      
    ml> i've also looked at the bluewave format and it doesn't specify   
    ml> anything for EOL...   
      
   I read somewhere years ago that they purposely left open the door for utf8   
   compatibility.   
      
    ml> we can only assume, at this point, that some system ignored   
    ml> (completely) that specific i character and as a result stripped   
    ml> it out during processing...   
      
   In the case of CP1252 it cannot produce a proper character or byte for 0x8d so   
   any processing, say tossing, would have issues if CP1252 is the default   
   codepage on that system.  This is a HUGE issue for utf8 since 0x8d is in many,   
   many multibyte characters that use 0x8d as a trailing byte.  Also notice the   
   holes in CP1250 and CP1251 which are supported by the CHRS kludge.  Another   
   reason that is a very flawed document.   
      
   Het leven is goed,   
   Maurice   
      
   ... Huil niet om mij, ik heb vi.   
   --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)   
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)   
   SEEN-BY: 1/123 15/2 18/200 154/10 203/0 221/0 226/17 229/354 426 452   
   SEEN-BY: 229/1014 240/5832 249/206 317 400 280/464 5003 310/31 317/3   
   SEEN-BY: 322/757 342/200 393/68 396/45 423/120 633/280 770/1   
   PATH: 280/464 229/426