@CHRS: UTF-8 4
@MSGID: 1:18/200@fidonet 562f9614
@PID: MBSE-BBS 1.0.7.12 (GNU/Linux-x86_64)
@TZUTC: -0400
@TID: MBSE-FIDO 1.0.7.12 (GNU/Linux-x86_64)
Hey Bullwinkle!
Let's try this instead; A M????se once bit my sister ...
Offhand the above doesn't look promising.
Life is good,
Maurice
Greetings, Maurice Kinal
--- MBSE BBS v1.0.7.12 (GNU/Linux-x86_64)
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)
SEEN-BY: 15/2 18/200 123/1970 153/7001 154/10 20 30 40 700 203/0 221/0 6 SEEN-BY: 226/17 227/400 229/107 354 426 452 1014 240/5832 249/206 317 400 SEEN-BY: 280/464 5003 310/31 317/3 322/757 340/800 342/200 393/68 396/45 SEEN-BY: 423/120 633/280 770/1 3634/12 116/116 123/25 150 755 135/300 153/7715
SEEN-BY: 261/38 3634/15 27 50 123/50 3634/0 18/0 123/0 1/120
@PATH: 18/200 229/426 280/464 154/10 3634/12
on my box i had to specifically assign a modifier key to use so
as to be able to enter ""blended"" characters...
what i describe is what i had to do on a KDE GUI setup...
as well as the correct control codes
on my box i had to specifically assign a modifier key to use so as to
be able to enter ""blended"" characters...
By blended do you mean multibyte?
Anyhow I won't quote back your modifier keys as they show as C1
control codes here. I never use those but perhaps they will work in
other editors, maybe even joe. That I don't know.
what i describe is what i had to do on a KDE GUI setup...
Ah! Yeah I read something about that somewhere. No KDE here, or anything like it, so I cannot confirm nor deny. All I know for sure that on the linux console those tricks won't work. The left <ALT> plus the decimal number does on both the console and in vim, as well as the correct control codes, and I'd imagine the same might be true for codepages.
This being a native uft8 enviroment makes things much easier when that
is the goal.
Also having iconv handy makes it extremely convenient to convert to 8
bit codepages when needed.
However I try and avoid that since I have yet to see a 8 bit codepage
that has it all and I am greedy. ;-)
by blended i mean that i have to hold the modifier button and
then hit the two keys, in proper order, to create the character
AFAIK they're just CP437 characters greater than 127
especially the "box drawing" characters which we use quite a lot
when drawing our ASCII/ANSI menus and other screens
if only we were all so lucky
Let's see if I can recreate it using utf8 and iconv
It's all fun and games until someone loses an .
by blended i mean that i have to hold the modifier button and then
hit the two keys, in proper order, to create the character
Wow. That sounds far too much like work.
willAFAIK they're just CP437 characters greater than 127
You mean like the 0x8d I sent that went MIA along a certain path? Let's see if I can recreate it using utf8 and iconv;
It's all fun and games until someone loses an .
On the above line it is U+00EC according to vim but after I exit iconv
convert it to 0x8d which should be the proper cp437 character at your end.
especially the "box drawing" characters which we use quite a lot
when drawing our ASCII/ANSI menus and other screens
Which should be the same codes on CP866, CP850, and other assorted IBM 8 bit codepages.
They have *NOTHING* to do with ASCII. There is no such thing as a
code higher than 127 in ASCII as ALL ASCII codes are 7 bit characters
(ie 0-127). There are exactly zero "box drawing" characters in ASCII.
if only we were all so lucky
It has nothing to do with luck. It is all about making the right choices.
i may not have the UTF-8 -> CP437 conversion stuff right
all without having to fark around with some other 3rd party
muckity muck with your fingers crossed that it will come out
properly and not be all screwed up
Hallo mark!the
Whoa! Something funky just happened. I am seeing all sorts of weirdness in your reply and that is from all 3 paths, although 1 of the paths has
word wrapping while the other two doesn't. Offhand I don't see how a single 0x8d could have caused it but perhaps it did, which makes the schpiel about it in fts-0001.016 very much foreboding ... if indeed thatis
what caused what I am seeing.
i may not have the UTF-8 -> CP437 conversion stuff right
What's to get right? Just try this on a commandline;
echo -e "\x8d" | iconv -f cp437 -t utf8
If you cannot display utf8 characters on your shell then add another pipe such as this;
all without having to fark around with some other 3rd party
muckity muck with your fingers crossed that it will come out
properly and not be all screwed up
Exactly how is that all working out for you?
if that's the post i think it was, i included a graphic of a
rainbow over a pot of gold...
if that's the post i think it was, i included a graphic of a rainbow
over a pot of gold...
Yes that would be the msg in question. However the graphic is definetly grunged even when converted to utf8 from cp437.
Is there an original I can have a looksee?
If it contains any ansi escape sequences that is what would cause
extreme grief as those will not work in fidonet messaging.
Anyhow I have been able to convert cp437 ansi files to utf8 ansi files
in the past and the result is best viewed using stty. Offhand I don't recall exactly how it was achieved but do recall stty has some
switches to force the view to 24x80 so that the ansi escape sequences
behave themselves on terminals foreign to 'normal' DOS-think
terminals. Not sure if the same will work on a KDE terminal but
perhaps something closer to a 'normal' terminal such as rxvt?
there were also ^A codes as well as ANSI codes...
i see ANSI graphics posted in one or two of the BBS ads echos
all the time...
i'll have to try to dig one out...
that should not be needed with what i do...
i don't know at this point...
Those survived and I wasn't sure they were in your original as such. I didn't
count them but there are quite a few of them as well as \r's from hell.
Did you get it on the Brain?
If so can you confirm there are no ^M characters in there that
shouldn't be there?
Simple answer is everything is as it should be. Thank you.
Simple answer is everything is as it should be. Thank you.
Simple answer is everything is as it should be. Thank you.
Confirmed.
Excellent, I am glad to hear that.. and I think Paul is too.. :)
there were also ^A codes as well as ANSI codes...
Those survived and I wasn't sure they were in your original as such. I didn't count them but there are quite a few of them as well as \r's from hell.
i see ANSI graphics posted in one or two of the BBS ads echos
all the time...
Hm. Maybe I should pick one of those up. Any recommendations?
i'll have to try to dig one out...
I'd prefer the St. Patrick's one if available. I now need closure since you brought it up.
pointthat should not be needed with what i do...
Sounds great. The little I've done with ansi graphics I've made it a
to follow a similar plan. In my case it was only to colourize messages on a console.
i don't know at this point...
Understood. Anyhow back when it mattered to me I found rxvt to be the terminal of choice in GUI-land. If I am recalling correctly it was with the -rv and -ls switches turned on by default. Same with xterm now that I think about it.
@TID: Mystic BBS 1.12 A43
@MSGID: 3:770/100 a7d4b33d
@REPLY: 1:153/757.0 18db6fcf
@TZUTC: 1200
On 13 Apr 2019 at 06:11p, Alan Ianson pondered and said...
Excellent, I am glad to hear that.. and I think Paul is too.. :)
Out of interest how does this message look Al?
--- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100) SEEN-BY: 57/0 153/250 757 7001 154/10 20 30 40 700 203/0 221/0 6 227/400 SEEN-BY: 229/426 240/5832 267/800 280/464 5003 310/31 317/2 340/800 393/68 SEEN-BY: 396/45 423/120 712/848 770/0 1 10 100 330 340 772/0 1 210 500 3634/12
SEEN-BY: 116/116 123/25 150 755 135/300 153/7715 261/38 3634/15 27 50 123/50
SEEN-BY: 3634/0 18/0 123/0 1/120
@PATH: 770/100 1 280/464 154/10 3634/12
i went back and looked and GE has broken it all to hell...
BBS_ADS
BBS_PROMOTION
would a graphic work instead of the farkled ANSI?
Excellent, I am glad to hear that.. and I think Paul is too.. :)
Out of interest how does this message look Al?
it looks fine but there's no >80 character lines in it... try a
paragraph from this link...
https://loremipsum.io/generator/?n=1&t=p
that should generate only one paragraph... the default is 5...
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
occaecat cupidatat non proident, sunt in culpa qui officia deserunt
mollit anim id est laborum.
the above is 1 long line wrapped to 2.75 lines at 165x54 in GoldED...
Looks good here.. but it would be intersting if you post a paragraph
worth of stuff in just one line and we could see if there was any sort
of word wrapping applied to it as mark suggested.
BBS_ADS
BBS_PROMOTION
And they both ship out ansi escape sequences in pkts?
would a graphic work instead of the farkled ANSI?
By farkled ANSI do you mean what I saw in your msg?
If so then maybe a graphic might be better. Are we talking jpeg type graphic?
I've run across a number of commandline conversion tools to create ansi/ascii art from jpegs, pngs, etc, over the years but have never actually tried any.
@TID: Mystic BBS 1.12 A43
@MSGID: 3:770/100 1a36a4c3
@REPLY: 1:3634/12.73 5cb292bc
@TZUTC: 1200
On 13 Apr 2019 at 09:50p, mark lewis pondered and said...
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Varius duis at consectetur lorem donec massa. Nec feugiat nisl pretium fusce id velit ut tortor pretium. Quis auctor elit sed vulputate mi sit amet mauris.Faucibus
pulvinar elementum integer enim neque volutpat. Sollicitudin aliquam ultrices sagittis orci a scelerisque purus semper. Lectus magna fringilla urna porttitor rhoncus dolor purus non enim. Vitae tortor condimentum lacinia quis vel. Amet mauris commodo quis imperdiet massa tincidunt nunc. Et malesuada fames ac turpis egestas.
--- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100) SEEN-BY: 15/0 19/33 36 34/999 90/1 104/57 116/18 123/140 124/5014 5016 130/803
SEEN-BY: 153/7715 218/700 220/60 222/2 230/150 152 240/1120 250/1 261/38 100
SEEN-BY: 261/1466 266/512 267/155 275/100 280/464 282/1031 1056 291/1 111 SEEN-BY: 320/119 219 340/400 342/13 387/21 396/45 712/848 801/161 189 2320/105
SEEN-BY: 3634/12 5020/715 1042 31999/99 116/116 123/25 150 755 135/300 154/10
SEEN-BY: 3634/15 27 50 123/50 3634/0 18/0 123/0 1/120
@PATH: 770/100 1 280/464 396/45 261/38 3634/12
20190414-st-paddys-day-rainbow-01.jpg
mark lewis wrote to Maurice Kinal <=-
BBS_ADS
that looks fine... it has forced hard-CRs at like 72 character widths if
i counted properly... t'would be better if they were not forced at all
but that can be taken care of later ;)
@PATH: 770/100 1 280/464 396/45 261/38 3634/12
the one system we were looking at is not in the above path this time...
OK so I'm using the latest public release of Mystic and sent my original post via 3:770/1 which we are saying is not doing anything to content. So if I understand you right you're (and others?) are happy with the way my test post came across to you - right? :)
But.. we're also wondering about another system (running Mystic right? but perhaps earlier version?) that may be adding something to the way content is then displayed after packets pass though it.
Do I have that summarized correctly? Al?
Maurice and probably others can give you better information than
I can.
The only information I can add is that it was never about other's messages (ie
the ones they create) but instead the messages I create that somewhere along the line got editted which should never happen.
What was happening, and now seems to be fixed, was that \r's were added to
my messages that weren't there to start with.
That other's editors decide to wrap at 80 columns, or whatever amount of columns, is up to them despite my belief that it should never be done. I think it should be up to the viewer of messages that should decide where to wrap given the display the viewer is reading any particular message.
not just your messages, any message that passes through
The problem hasn't been fixed yet but I suspect it soon will be.
today they could be bigger or smaller in the case of a phone,
tablet, or a wide screen display.
Quoting mark lewis to Maurice Kinal on 13-Apr-2019 11:42 <=-
if that's the post i think it was, i included a graphic of a rainbow
over a pot of gold...
==== Begin "03-17.msg" ====
5 ==== End "03-17.msg" ====
Quoting Maurice Kinal to mark lewis on 13-Apr-2019 18:00 <=-
if that's the post i think it was, i included a graphic of a
rainbow over a pot of gold...
Yes that would be the msg in question. However the graphic is
definetly grunged even when converted to utf8 from cp437. Is there an original I can have a looksee? If it contains any ansi escape
sequences that is what would cause extreme grief as those will not
work in fidonet messaging. Anyhow I have been able to convert cp437
ansi files to utf8 ansi files in the past and the result is best
viewed using stty.
Sysop: | Weed Hopper |
---|---|
Location: | Clearwater, FL |
Users: | 14 |
Nodes: | 6 (0 / 6) |
Uptime: | 232:30:24 |
Calls: | 55 |
Calls today: | 1 |
Files: | 50,128 |
D/L today: |
35 files (4,430K bytes) |
Messages: | 275,424 |