[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    konsole & unicode support, state and roadmap
From:       Lars Doelle <lars.doelle () on-line ! de>
Date:       1999-08-15 20:32:25
[Download RAW message or body]

Here some notes on how unicode support within  konsole will
be implemented.

1) The internal representation of the text will consistently be
unicode. The implication is, that the burden of converting the
unicode representation to the font encoding is shifted onto QT.

2) After a some investigations, it came out that QT is not able to
handle this properly. Troll is not to really blame here, but the mess
of the different encodings. While the first observation is, that one
cannot set a QTextCodec with the font (which is later used to
convert to 256 glyph fonts), making the graphical glyphs
inaccessible, it would become necessary to accompany all those
fonts with a unicode charmap file. So i'm finally taking Troll's
omission as a chance to clear things up and decided that konsole
will support iso10646 fonts in future, only. Under these circumstances,
the code conversion in drawText becomes an identical map which
is then trivially handled by QT.

3) Now no iso10646 fixed width fonts are available. I've decided
to convert some available font (both pcf fonts distributed with
xfree86 and linux console fonts) to the desired encoding. To this
end, a new $KDEDIR/share/fonts directory will have to introduces.
The startkde script will be responsible to add this directory to the
font path.

4) Since this handles only the screen's side of konsole's operation,
the keyboard (application) codes have to be coped with, too. For these,
no way leads around having charmap set up. Though QT provides
conversion for iso8859-*, many other encodings are use, the cp865
like code of the linux console, to name one.


Problems:

1) There is no 8-bit clean pass through konsole anymore.

2&3) has an impact when konsole is run remotely on a machine
that does not provide the required fonts.

2) excludes type1 fonts which cannot cope with codes beyond 255,
eg.  0x2518 for the right lower corner glyph.

3) That kde ships non xfree86 font and comes with an addition of the
X11 font path has not yet been discussed.

4) There are not utf-8 (unicode) aware cli applications and the
whole key mapping stuff is therefore still base on ibm code
pages requiring a specific national setup.


State:

The outlined scheme is already implemented. I had some hundred
different glyphs the same time on the screen (and in the history
buffer) using an utf-8 codec. I was able run simultaneous sessions
with different encodings, also, including the linux console encoding
and vt100 extended iso8859-1 while using the same font all the time.

What is left to do is to convert the pcf fonts currently used by konsole

and to add configuration material to allow setting the codecs freely.


ETA:

Since i've developed the unicode support using a single font derived
from the LatArCyrHeb-16 font as distributed in the console font
package, i expect to cause inconveniences when releasing the stuff
in the current state. Taking job demands and a vacation into account,
i expect to be able to release the material by end of September.


Lars

[prev in list] [next in list] [prev in thread] [next in thread]