[fpc-devel] fpcsrc/rtl/unix/video.pp

[Daniël Mantione]

Op Fri, 3 Nov 2006, schreef Tomas Hajny:

> > Xterm supports two modes: ISO-8859-1 and UTF-8. There are two ways to use
> > a different code page:
> > * Put the xterm in ISO-8859-1 mode and just load a font with different
> >   characters in #128..#255.
> > * Use proper fonts, but use an emulator that switches the terminal into
> >   UTF-8 mode and emulates a terminal with the desired encoding. I forgot
> >   the name of the emulator.
> 
> UTF-8 mode should work, shouldn't it (as long as video unit can draw the
> line drawing characters using their UTF-8 codes, of course)?

You must assume a common base, which is the VT100, the only standard that 
every terminal emulator implements. This is the level the video unit 
currently supports.

Then, you can detect wether the terminal supports UTF-8. This is 
not possible, but you can write a character and detect wether the cursor 
moves one or two positions.

If the terminal supports UTF-8, there are still a few pitfalls:
The terminal emulator might not recognize line drawing characters. In this 
case the font might still provide them, but the terminal emulator
cannot draw continuous lines in this case. The situation gets more 
difficult if the line drawing characters are not in the font.

To use UTF-8, you must first determine wether a UTF-8 mode is available. 
To make it worse, you cannot, although there exists a hack to write a 
character and test if the cursor advances one or two positions.

> > The line in question enables the use of the vt100 alternate character
> > set. You access the normal font by switching the terminal to the G0
> > charactert set, and the ACS by switching it into the G1 character set.
> > The ACS should be available when code page 1251 is in use.
> >
> > However, the video unit emulates a code page 850 on a iso-8859-1, using
> > the ACS for the line-drawing characters. This doesn't work for Russian.
> > As a short term solution a conversion table should be added from a
> > Cyrillic Dos code page to 1251+ACS.
> 
> I don't think this is a reasonable solution. Why not to use translation
> capabilities provided by the WideString manager?

The widestring manager is part of a generic solution, but we aren't quite 
there yet. There are two code pages to worry about:
* The filesystem and terminal encoding
* The VGA font encoding

Normally the file system encoding is one of the iso-8859-* standard, or 
UTF8, the VGA font is normally one of the Dos code pages. The video unit 
has to care about both code pages, and therefore needs to keep track of 

> Otherwise you'd need to
> implement translation tables for all the different pairs...

Between the Dos code page and its matching iso code page, yes.
This has by the way an advantage, and that is that a fallback character 
can be used in many situations. For example an up arrow is replaced by a 
^. This is not possible with a widestring manager at this time, but 
necessary to be able to display scroll bars.

Keep in mind that we are just starting: Before 2.0.4 just the line drawing 
characters were converted and except those only #32..#127 could be 
drawn in a reliable way.

Daniël