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

List:       kde-devel
Subject:    Re: konsole & unicode support, state and roadmap
From:       Jo Dillon <emily () thelonious ! new ! ox ! ac ! uk>
Date:       1999-08-17 12:49:14
[Download RAW message or body]

Lars Doelle (lars.doelle@on-line.de) spake thusly:
> 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.

  A friend of mine, Robert Brady, is converting some fixed width
fonts. I've cc'd this reply to him so he can help you out, which is
why I've left the whole message :)
 
> 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
> 
> 

-- 

	Jo

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