Subject: RE: Feature matrix update from Pierre Abbat
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 30 2000 - 16:22:24 CST
At 10:31 AM 3/30/00 -0600, Robert Sievers wrote:
>At 02:09 PM 3/30/00 +0200, Henrik Berg wrote:
>>Good thinking with a table for character sets. One thing that I think of
>>is that if it works or not is very platform dependent. We need a table with
>>"platforms vs charsets".
>
>That might go here: http://www.abisource.com/ui_matrix.html I will check
>into this.
Yep. The current placeholder for this is note #1 in the fonts row. There
should be similar comments for the keyboard row. Essentially we'll need XP
mechanisms and platform-specific implementations for the following:
input -- use native input methods and/or keyboard charset detection
output -- if needed, draw unicode content using fonts w/other charsets
This way, we can preserve the design goal that all content is indeed stored
internally as Unicode, and just converted at I/O time on an as-needed basis.
My hope is that this work can be done once in a sufficiently general way
that we won't need an entire matrix to track specific classes of charsets to
be handled at each step. However, I'll defer to the judgement of folks who
are actually immersed in that work. For example,
- Henrik has made great strides for 8-bit languages on Win32,
- Vadim Frolov is looking at similar issues on Linux, and
- HJ is making inroads on related GTK-specific issues for Chinese.
When folks like that converge on a common implementation, I think we'll be
all set. :-)
>>The columns dialog and toolbar? What do that say? Do we need a collumn
>named spellcheck? Ispell is very hard to get to work for larger than 8-bit.
>
>Both dialog and toolbar might be n/a. There hasn't been any discussion
>about having the ability to choose various character sets from the either a
>dialog or from the toolbar. This is different than Martin's insert symbol
>patch, which would allow one character to be added at a time. Those two
>columns you refer to relate to options, either via dialog or toolbar, to
>completely change the character set being input. So far, nobody has
>suggested these particular items are needed or wanted.
Agreed. Our product is Unicode-centric. Charsets are a legacy issue that
we should just handle behind the scenes without requiring intervention from
the user. All of the necessary charset information should be coming from
someplace other than user input. For example,
- the platform should know what charset their keyboard is generating
- the platform's font manager should know what charset each font uses
- any imported file format should explicitly specify its charset
- etc.
Have I missed any concrete use cases here?
Paul
This archive was generated by hypermail 2b25 : Thu Mar 30 2000 - 16:16:53 CST