plans for KDE4

[Ken Deeter]

Hi Lars ;-)

> 
> I really wouldn't call them GTK like. They are not bound to GTK and
> don't have any real close relation to GTK (at least not technically).
> They are basically client side input methods independent of the old
> XIM framework. 
> 

Right. I didn't mean to say they copied the gtk design (there are
actually a few mistakes that we avoided). Rather that the functionality
to the end user is rather similar.(loosely coupled input method engines)

> Which problems are you talking about? A general statement like this
> doesn't really help. What I need to fix issues is concrete use cases
> and wishes as how things should behave.
>

Well for example.. right now I have a case where I can set my font chain
to: Bitstream Vera Sans, subsituted by Kochi Gothic, subsititued by a
chinese font. If I set it up this way, and open a chinese webpage.. I
get a whole bunch of empty squares. Some are filled in, but about 1/3 I
would say are empty. 


> > I'm working on a document to explain this but it essentially comes
> > down to the fact that you need to have an API that lets an
> > application ask for a font for some language (or more specifically
> > script). This also means that many KDE apps will need to be modified
> > to be aware of what language they are dealing with.
> 
> The Qt font dialog (since Qt 3.2) mostly allows this. There are
> limitations in the CJK range (we only show Han as a script and not
> Japanese, Simplified Chinese and Traditional Chinese). These should
> get fixed in 4.0.
> 

I actually meant not a font dialog, but the application asking Qt
directly "gimme a font for this script".. or are you saying that by
being able to provide such a dialog, the backend functionality is
already there?

> > Some might think "just look at the locale" but its not quite that
> > simple. For example, you may have an IRC program with different
> > languages in each channel. Both may be using utf-8, but you want
> > different fonts for each (especially if you are talking about
> > Chinese/Japanese/Korean texts). You're locale may say use Japanese
> > or wahtever, but for a Korean channel, using a Japanese font to
> > render some characters may be incorrect.
> 
> This is independent of the font system. What you want is to be able to
> choose one font per channel. A Korean one for the korean channel a
> japanese font for the japanese channel.
> 

Well, maybe I should try to put it this way. There are lots of times
when the app knows what language it is dealing with. For example for
khtml, when you load a webpage, many times you can guess from the legacy
encoding, what script is being used (for example if its a EUC-JP page,
then its Japanese). Based on this information, the app should be able to
look up somewhere which font it needs to load. In the case of UTF-8 or
any unicode its difficult, but when it isn't unicode, it should be
automatic. 

I think if the apps remain ignorant, the burden will always be upon the
user to set fonts everywhere (which could get very cumbersome.. and
users typically don't understand when you tell them you have to set up
font substitution or pick fonts for different channels because each
font convers different ranges. It should just work. It may not be
pretty at first, but little empty squares shouldn't be shown if at all
possible). I think what we need is re-vamped font control center that
looks somewhat like mozilla's font configuration right now.. where you
can specify per-script fonts.. and then this information should be made
available to all apps.

There are also per-script information that is related to fonts. For
example, the minimum readable font size can differ from script to
script. There needs to be a way to set this information once (with good
defaults) and a user only have to change it in one place to set all
apps. Apps can provide their own font dialogs if they want, but it
should be in very specific cases.

There's a long discussion for a related konqueror bug.
  http://bugs.kde.org/show_bug.cgi?id=39185      


I'm trying to enumerate in my head all the possible operations that
would be needed for a font system;

"give me a font for this script"

"give me a font for this encoding"

"what is the smallest size font for this script/encoding?"

"give me a 'small/medium/large' sized font for this script"

"give me a font that can show script A, script B, script C, in that
priority" (priority as in, glyph from earlier fonts get used if multiple
fonts provide the same glyph)


My feeling is that what users would like is one uber-"font setup dialog"
to set font things per-script and then have apps respond automatically,
and intervene only where necessary.



> > Although I'm not anywhere close to having the solution yet, I would
> > like to point this problem out for KDE4. Gnome already gets this
> > right (or at least more right, thanks to pango and fontconfig), and
> > my guess is that since the majority of kde users are western, they
> > may not notice it as much. It will likely be a change that requires
> > the app developers to re-think their designs a bit, or at least
> > re-work some configuration dialogs.
> 
> KDEs font dialog needs some rethinking here. But could you please be
> more specific about what Gnome gets right and we get wrong? 
> 

Well, the prime example is mozilla. In mozilla, I can set my font for
Japanese to be Verdana. Verdana doesn't contain any Han characters, so
pango/fontconfig will set up the substitution automatically.

The difference with kde is that when the subtitution happens, the
substitute font gets picked dynamically. For example, if I point mozilla
at a Chiense page, I get verdana + chinese characters in a chinese font
(the default fallback specified in fonts.conf), where as if I go to a
Japanese page, I get Japanese characters. The bit of magic is that the
fonts.conf is already set up with the right information, but the point
is that the system knows when to go for a Japanese font versus a Chinese
font, because it could tell from the page's encoding.

<BTW>
THere is a bit in chapter 15 of unicode 4.0 that talks about language
tags to help font selection, but at the same time it discourages their
use when language information is available in from the context of the
text.
</BTW>

> > If anything, we need to get the message out to all the developers
> > that unicode doesn't solve all your problems. Its a good step
> > forward, but it introduces a lot of issues as well, and KDE/Qt needs
> > to come up with some ways to deal with them.
> 
> The main issue I can see in Unicode is CJK unification and I assume
> that's what you're talking about. But this usually boils down to
> selecting the correct font for the language you want.
> 

With regards to font handling, I think CJK unification is the big issue.
THere is also the problem of dealing with ambiguous character column
widths, but thats a relatively minor problem.

More generally though, I want to prevent people from thinking "oh we
support unicode, so we support all languages." The danger is that, if
you start thinking this way, you may design your app to be
language/script agnostic.. which is still clearly the wrong way to go.
If anything the fact that unicode can describe all languages makes the
problem much more complex. 

There are still things like RTL text (and CJK vertical RTL), input
methods, and various idiomatic things that need to be thought of to make
an app truly internationalized. If anything, unicode means we now have
to suport all those things potentially at the same time, making it even
more difficult.

Also, you always have to deal with legacy encodings.. they are not
likely to go away even by the time we move on to the next standard after
unicode.

sorry i'm kind of rambling... just woke up.

Cheers,
Ken