Hello all,

I have installed FPC on a Linux machine to find that in the virtual terminal (true text-mode, not GUI-based emulator) FP-IDE does not dispaly pseudographics correctly. It turned out that changes to the SFM (Screen Font Map) doesn't have any effect inside the IDE, and I count'd understand why.

Then, in the WIKI I found this:

On a terminal with VGA character set (currently only the Linux console), the video unit will enable the VGA char- acters and use them without translation.

which answered my question.

My console is in UTF8 mode, using an ISO8859-1 font, while the FP-IDE, as it seems, is accessing pseudographics symbols directly by glyph number (and bypassing the SFM table), expecting them to be at locations specified in the CP437 encoding:

http://en.wikipedia.org/wiki/CP437

which means that it will only work with a CP437-encoded font.

Why was this done and is there a workaround except re-encod- ing the console font into CP437?

Thanks in advance,
Anton

Modern FPC versions should support UTF-8 output for the IDE. I made a patch for this, that was included in fpc 2.4.2 IIRC. Which FPC version are you using and on which linux distro/version? What is the value of the LANG environment variable?

Nikolay Nikolov:

I am using FPC 2.4.4 on Puppy Linux. LANG=en_US.

Anton

Try changing it to LANG=en_US.UTF-8

Nikolay Nikolov:

Try changing it to LANG=en_US.UTF-8

Thank you very much, it works well now. Maybe this should be mentioned on the WIKI?

Anton

You are welcome to add it to the wiki. I would suggest you mention it to the Puppy Linux distro maintainers too. There is no excuse not to default to *.UTF_8 encoding in a modern distro.

Graeme Geldenhuys:

You are welcome to add it to the wiki.

I still do not fully understand the problem, so please, review what I have come up with:

On Linux/Unix the FP-IDE calculates the
addresses of the drawing charactes (also
called pseudagraphics) based on the LANG
environment variable, so for the IDE to work
correctly, its value must correspond with
the console mode which can be checked using
the kbd_mode utility.

    If the reported console mode  is  UTF8  then
    the  value  of  LANG  must  be  of the form:
    ll_CC.UTF-8.  For  most  cases   en_US.UTF-8
    should work.

Now I don't know for sure what happens with other locales. From my own experiments, in this case the IDE simply tries to get the pseudographics charac- ters from their respective addresses as defined in CP437. Is this correct?

Anton

Basically, all it does is, it checks if the LANG variable contains 'UTF-8' as a substring (not sure if it is the right way to do it, but it works for Fedora, Ubuntu, OpenSUSE, Mandriva and latest Debian) and if it does, it writes UTF-8 characters to the console, by using an internal CP437 to UTF-8 conversion table.

Nikolay Nikolov:

Then my guessing was correct, but in this case there is a better solution. Instead of relying on the value of LANG, FP-IDE should directly check the con- sole mode. This can be done using the 'kbd_mode' command. If the mode reported is UTF-8, then use the translation table, otherwise assume CP437.

At least, this will make it more reliable with UTF-8 consoles.

Anton

Yes, but there are still several issues:
1) It only works on the linux console. It doesn't work under xterm, gnome-terminal, konsole, etc and we still need a way to detect if they are in UTF-8 mode or not.
2) IIRC, it only checks if the keyboard input is in UTF-8 mode. What we actually care about is whether the console output (not input) is in UTF-8 mode. But I guess it's ok to assume that if the input is UTF-8, then then output is also most likely to be UTF-8.
3) I don't like the idea of having to invoke an external program and parse its output, but this could be done by directly invoking the ioctl that kbd_mode uses.

Do you know how many linux distros (besides Puppy Linux) would need this? When I came up with the 'UTF-8' string check in the LANG variable, I tested Fedora, Ubuntu, openSUSE, Mandriva and Debian and they all worked this way, so I figured it's a de facto standard.

Nikolay Nikolov:

[kbd_mode] only works on the linux console. It doesn't work under xterm, gnome-terminal, konsole, etc and we still need a way to detect if they are in UTF-8 mode or not.

But at least that will make the IDE work correctly in the true console... As for the graphical ones, to assume their mode as UTF-8 is much safer, but the vector fonts may not have the drawing characters anyway...

As I understand, the console mode defines the way the input bytes are treated all the way from the initial keycode to the charater address in the font. Therefore, it must be taken into account when decid- ing what keycode to send to get an expected charac- ter:

http://tldp.org/HOWTO/Keyboard-and-Console-HOWTO-6.html

When not in unicode mode, an additional ACM is used to get the Unicode value of a keysym:

http://www.tin.org/bin/man.cgi?section=8&topic=consolechars

I don't like the idea of having to invoke an external program and parse its output, but this could be done by directly invoking the ioctl that kbd_mode uses.

Agree. I did mean to mimic the kbd_mode's mechanism of determining the console mode.

No, I haven't done such a research, but I think it would be nice to have the IDE less dependent on the environment settings. Otherwise, this has to be a system requirement for FP-IDE.

Anton