Lars Knoll wrote:
> 
> On Monday 12 November 2001 09:56, Dirk Mueller wrote:
> > On Fre, 09 Nov 2001, Lars Knoll wrote:
> > > This approach was a workaround for Qt-2, which did map these chars to
> > > boxes otherwise (for latin1 fonts, mostly used in khtml). With Qt3, the
> > > reasoning behind this is wrong, and we shouldn't do this anymore. If at
> > > all, Qt should provide a reasonable mapping for these chars, in case it
> > > can't find a Unicode (or other) font contaning them.
> >
> > Just as a reminder.. the world doesn't only consist of X11 yet ;-)
> >
> > This workaround is still very much needed for Qt/Embedded, as the fonts
> > there usually don't ship these characters either.
> 
> True for Qt Palmtop. If you're developing a Qt/E app yourself, you can also
> create fonts that contain these chars without much of a headache.

As I understand it, QT/Embedded only supports Unicode.  Without the
"simulated unicode" of QT3/X, if you want to maintain a workable browser,
that pretty much means creating Unicode fonts, regardless of the above hack.

The "wgl4" (Windows Glyph list 4) unicode subset is probably a good choice.

> > We could try #ifdef'ing it and see what happens.
> 
> It might need a bit more work on Qts side, as we currently don't try to map
> them to Latin1 in case we don't find a reasonable font.
> 
> Lars

The thing that's most wrong about the current solution is that the
mapping to ASCII takes place before it is known if a proper unicode
font exists.

			-Bryce


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<