Printing ASCII characters

Posted by Zeno on Mon 07 Mar 2005 02:31 AM — 11 posts, 38,616 views.

Zeno USA Mon 07 Mar 2005 02:31 AM #0

Is it possible to print ANSII characters with ch_printf? I read some posts how to type it so the MUD can handle it, but not displayed via the code. I want to display the Yen symbol, so I tried this:

    ch_printf( ch, "Test: %c", 157);

But it turned out like this:

Test:

(If you can't view the above, it was a white rectangle box)

I'm pretty sure something like this is possible. I've seen ANSII characters on this GodWars MUD I played once, had like diamond, triangle and some other symbols.

David Haley USA Mon 07 Mar 2005 06:27 AM #1

IIRC, the MUDs tend to strip out characters from input and output that aren't 'printable' or something like that. You might want to check the functions that copy to the outgoing buffer or the functions that actually send it.

There is also the problem of signed vs. unsigned characters but that shouldn't make a huge difference.

Samson USA Mon 07 Mar 2005 12:10 PM #2

In comm.c you have in read_from_buffer a pair of calls that check to be sure what you're sending is printable. The calls to isascii and isprint govern what the mud will actually allow you to see.

The problem in removing this barrier is that not all clients treat the codes the same way. So while you're expecting to see a Yen symbol for 157, someone else may see a star, and still another may see a cent symbol. There's no real standardization on extended ascii yet.

Edit: And of course I read back and note that you meant WRITING to the buffer, not reading from it, although the reasoning still stands. The results are not predictable.

David Haley USA Mon 07 Mar 2005 05:26 PM #3

Quote:
There's no real standardization on extended ascii yet.

Really? I thought that all codes between 0 and 255 were standardized.

Zeno USA Mon 07 Mar 2005 05:43 PM #4

Is that right?

/*  Did not support ANSII  -Zeno
        if ( d->inbuf[i] == '\b' && k > 0 )
            --k;
        else if ( isascii(d->inbuf[i]) && isprint(d->inbuf[i]) )
            d->incomm[k++] = d->inbuf[i];
*/
        if ( d->inbuf[i] == '\b' && k > 0 )
            --k;
        else if (isprint(d->inbuf[i]))
            d->incomm[k++] = d->inbuf[i];

It doesn't seem to work.

Greven Canada Mon 07 Mar 2005 06:02 PM #5

Well, according to the manpage

        isascii()
              checks whether c is a 7-bit unsigned char value that fits into the ASCII character set.  This function is a BSD extension and is also an SVID extension.

...

       isprint()
              checks for any printable character including space.

Assuming of course that the yen symbol is in fact in the ASCII character set, since I myself am not sure, there should be no reason that it stops that character. The isprint, however, my be stopping it. Have you tried removing both altogether, or just using isascii()?

Zeno USA Mon 07 Mar 2005 07:08 PM #6

Well it does have the symbol:
http://www.cdrummond.qc.ca/cegep/informat/Professeurs/Alain/files/ascii.htm

Removing the isprint stops all commands to go through the MUD...

Samson USA Tue 08 Mar 2005 01:12 AM #7

Quote:

Really? I thought that all codes between 0 and 255 were standardized.

They are in the HTML standard. Sadly, they are not in ASCII. I've seen it enough from several different clients, and even different operating systems. You just never get the same results from program to program.

Raz Wed 09 Mar 2005 01:31 AM #8

Quote:
I'm pretty sure something like this is possible.

It entirely depends on the terminal that you are using. In standard Telnet (which is automatically the version you use), only 7-bit ASCII can be transferred and understood. No Telnet terminal is required to understand anything else. No Telnet terminal is required to have any certain definition of those odd characters you send to it. You could try to negotiate 8-bit ASCII mode, but thats a new can of worms since it is intended for binary transfers.

David Haley USA Wed 09 Mar 2005 01:57 AM #9

I would assume, though, that most MUD clients would know how to handle this stuff; I don't think MUD clients make assumptions about 7-bit characters. And I think it's not too hefty of a requirement that people use clients other than telnet if they want to play these internationalized MUDs.

Raz Wed 09 Mar 2005 04:01 AM #10

Quote:
There is also the problem of signed vs. unsigned characters but that shouldn't make a huge difference.

Why would there be a problem? Is the OP trying to play with raw data?

Quote:
I would assume, though, that most MUD clients would know how to handle this stuff

Windows-based clients may inherently be able to, but I wouldn't rely on such an assumption.

Quote:
I don't think MUD clients make assumptions about 7-bit characters.

No. I don't think many MUDs realize the old requirement about it. In this day and age, it is rather obsolete. However, all telnet applications must do 7-bit ASCII transfer until a request is made to do otherwise.

Back to the OP:

Quote:
I read some posts how to type it so the MUD can handle it, but not displayed via the code.

After going over the RFCs again, this might help you:
http://www.faqs.org/rfcs/rfc698.html
It allows safe negotiation with clients and servers about using extendend ASCII. I'm not sure of how many clients implement it, however.