Inconsistent Character Output

G

GordonShumway

First, before I get to my problem I should point out that I'm very new to FreeBSD and I'm coming from a Windows background so if anything I ask seems silly please be gentle. ;)

I'm working with ncurses trying to develop a terminal application (C++) and am having problems with output consistency between the system terminal and various terminal emulators. I've been pouring over the manual pages and Internet searches but I'm just not getting any really clear answers; though admittedly, I may just not know what it is that I'm looking for.

My problem is most evident with the line/box drawing characters like the old "Code Page 437". I can get these characters to show in the console emulators easily with just about any encoding (ISO8895-1, UTF-8, US-ASCII) but these characters are replaced with '|' and '+' characters in the system terminal.

Now, when I found the ASC_XXXX character defines I figured that this was the solution to my problem and to their credit it works great in the emulators. But once again, I get '+' and '|' instead of the actual drawing characters in the system terminal.

The thing is though, when I loop through the upper 128 values of a char variable in the system terminal the drawing characters show up just fine. In an emulator I only get accented characters. Albeit the results were displayed twice no matter which terminal was used.

I also noticed that there was an "asc_map" in the ncurses header but have not found any viable option of defining this on my own and figured it must be for internal work in curses or something.

NOTE: I've tried both the regular and "wide" versions of curses. I've tried setting "set_locale(LC_ALL, xxxx )" to everything that I thought would work and could find no appreciable difference so I just leave it blank.

My questions, I guess, are:

0) Am I doing something wrong?
1) Is there a consistent way of displaying these characters irregardless of terminal type?
2) If not, can I programmatically detect the difference between a system terminal and an emulator and take corrective action this way?

Particulars:
FreeBSD 9.1-RELEASE
curses 5.7 20081102

Thanks for your help everybody!
 
Don't quote me on this, but if I'm not mistaken it's a font thing. In any case, if you do get the "high ASCII" box drawing characters to work on the console, please report back here because I'd sure like to know how you did it. Not only does it look better, but I happen to have an old curses application I developed on Linux a long time ago and I'd like to port it to FreeBSD but with + and | instead of the proper box drawing characters it would just look silly.
 
Sure thing fonz, glad to know I'm not alone! Now that you mention it there is a documented option for switching software fonts under the man page for the syscon driver. The same manual page also mentions Screen Maps for those cards that don't support software fonts but I haven't found a method of actually setting it yet (outside of the "vidcontrol" command) and sort of dismissed it thinking it was overkill but maybe it's just what is needed?
 
wblock@ said:
This thread from the questions mailing list might be relevant. Short version: if you are using a real console, try setting TERM to cons25.
Click to expand...

Thanks! By switching TERM I was able to get it to print the characters proper!

I do have a question though, particularly as it relates to the last message in the chain:

... TERM is one thing, the driver is another. Since the "xterm" terminal description supports line-drawing characters, it sounds as if the underlying problem is in the console driver. ncurses would use ASCII characters if it is told that the terminal cannot use line-drawing characters. However, it uses the VT100 line-drawing characters if possible.
...
Thomas E. *beep**beep**beep**beep*ey
Click to expand...

But I know that my console is capable of displaying the line-drawing characters. He makes it sound as if this is kind of a "hackey" method to getting this to work and that it should have behaved like fonz and I had expected. Is this an indication of my hardware not being setup properly or something more fundamentally wrong?
 
wblock@ said:
This thread from the questions mailing list might be relevant. Short version: if you are using a real console, try setting TERM to cons25.
Click to expand...
I just tried this with a dialog(1)-driven program I'm working on. Short version: I can only click the "Thanks" button once.
worthy.gif


Note @OP: If you're using this in a C(++) program, I suggest you try using the getenv(3)/setenv() calls in order to set the TERM environment variable. I haven't tested it myself yet, but I hope it works. Another option is to adjust /etc/ttys.
 
GordonShumway said:
But I know that my console is capable of displaying the line-drawing characters. He makes it sound as if this is kind of a "hackey" method to getting this to work and that it should have behaved like fonz and I had expected. Is this an indication of my hardware not being setup properly or something more fundamentally wrong?
Click to expand...

The last message mentions PR kern/141633, which just says "VGA fonts are not guaranteed to have line-drawing characters". So no, your hardware and settings are okay, it's a regression over the previous version. It's intentional. Maybe there is no way to fix that problem with fonts, but it would be nice if there was at least a setting to tell it to assume line drawing characters are available. Modify the entries in /etc/termcap?
 
wblock@ said:
This thread from the questions mailing list might be relevant. Short version: if you are using a real console, try setting TERM to cons25.
Click to expand...

FWIW, I've for years had a non-X breakage of sorts, the page up key would not work (forcing the use of the up arrow, line-by-line) and past-viewed-lines would remain on the page, interspersed with present lines (in a text file) at the console. /lookat/ .txt ...
Code: 
TERM="xterm"  #was cons25; don't precisely remember the syntax (quoting) either, but...
That made those two issues go away. The fix is now taped to my monitor...
 
fonz said:
Note @OP: If you're using this in a C(++) program, I suggest you try using the getenv(3)/setenv() calls in order to set the TERM environment variable. I haven't tested it myself yet, but I hope it works. Another option is to adjust /etc/ttys.
Click to expand...

I just caught your edit! Thanks.
 
jb_fvwm2 said:
FWIW, I've for years had a non-X breakage of sorts, the page up key would not work (forcing the use of the up arrow, line-by-line) and past-viewed-lines would remain on the page, interspersed with present lines (in a text file) at the console. ...
Click to expand...

That's good to know! Did it do this with all applications or only certain ones? Or do you think it's a hardware thing? This is definitely something to keep in mind and I intend on being mindful of this with my applications.
 
wblock@ said:
The last message mentions PR kern/141633, which just says "VGA fonts are not guaranteed to have line-drawing characters". So no, your hardware and settings are okay, it's a regression over the previous version. It's intentional. Maybe there is no way to fix that problem with fonts, but it would be nice if there was at least a setting to tell it to assume line drawing characters are available. Modify the entries in /etc/termcap?
Click to expand...

Phew! Thanks for explaining, now it makes much more sense which is appreciated. I agree with you though, it would be nice to have an option to assume they're available or even base it upon locale, but if this behavior is intentional it must be a feature ;)

Honestly I never even thught about opening up the termcaps database but when I did, sure enough, CP437 support was listed on a couple of the terminals (namely cons25, etc) but haven't really checked the xterm listings yet as I just did a quick scan. I'm going to have to poke around in there a little and see what I can find later.

Thank you!:e
 
All applications or just some? Unsure, the only one I use consistently day in and day out is
Code: 
 lookat file.txt
. Most everything else I run in an xterm, it is more efficient. [No time to read up on any reasons, usually; I have a paper database of sorts of issues that are relegated to "someday" fixing them further...]
 
It also appears to fix the "missing line or two at the top of the screen" that appeared I think in V9-STABLE.... cons25 not working well with something extra in the kernel, rc.conf...loader.conf...login.conf.... Maybe if I searched the forum for "cons25" an hour or so it would turn up the reason.
 
Thanks JB, I'll be watching out for those problems you've mentioned. I chuckled a little at the paper database because I've got mine right here sitting next to me, at least it's crash-proof :) but since I'm still new to FreeBSD I've only filled two pages with notes. ;)
 
You must log in or register to reply here.
Back
Top