On Tue, 27 Aug 2002, Torsten Mohrin wrote:
Thank you for your detailed response.
> Jungshik Shin <jshin@mailaps.org> wrote:
>
> >> http://www.unipad.org
> >disappointed. At first, I was intrigued by their claim that it
> >supports Hangul Jamos. I've seen some false claims that Hangul
....
> >claim. It just treats them as 'spacing characters' instead of combining
> means. We will explain this more precisely. However, displaying Jamo
> as separated characters is actually a certain level of support, while
> non-support would be to display hollow boxes. Therefore the Jamo
> support in UniPad is on a very basic level currently. But at least you
> can see something.
All right. I guess we just have to agree to disagree :-) as to what
'support' of a certain script means for a text editor. More on this
below....
> 2. Please keep in mind that software improves gradually. This is
> version 0.99/1.0. Better support of certain scripts will be realised
> in future versions. This is planned for Indic scripts and also for
> Hangul.
Good to hear that. I'll certainly looking forward to future
versions.
> 3. If your definition of "support" is that strict, than I doubt that
> you will be able to find any software that can claim to support
> Unicode at all.
There must have been some misunderstanding here. Unicode support
can mean many different things to many different people, but I NEVER
wrote that SC Unipad does NOT support Unicode. I believe it DOES support
Unicode very well in some aspects and not so well in other aspects. I
never thought/wrote that supporting Unicode means supporting all
the characters/ letters encoded and all the scripts representable in
Unicode as expected by native users of those scripts in a single stroke.
I think a product can claim "Unicode support" without supporting many of
scripts included in Unicode. There was a thread on this topic sometime
ago on this list and Unicode FAQ may have an entry on the issue.
Simply put, I did NOT blame SC Unipad for not supporting (in my
view) South and Southeast Asian scripts and Hangul Jamos (for pre-1933
orthography Korean support and perhaps for 'future' Korean support).
What I questioned was whether it's acceptable/wise to say an *editor*
supports South and Southeast Asian scripts and Hangul Jamos _without_
any qualification when all it does is just to treat characters/letters
comprising those scripts as spacing characters/letters and render
them serially when they have to reordered, combined and otherwise
processed through some complex rendering. To me, the answer is clear.
It's too misleading to put 'yes' next to all those languages for which
proper rendering is not provided at least for 'non-i18n engineer users'
(see below). On this point, I guess we now all agree and I'm expecting
you to have more refined classification of support levels in your
list.
> Okay, okay :) We will define "support" more precisely.
Thank you for this. As suggested by Marco, it'd be very nice if you
could have more fine-grained levels of support (than simple 'yes vs no')
marked in the list of languages supported.
> 4. You have the chance to evaluate the software, as you did. You are
> free to decide not to use UniPad. I feel sorry, if it does not meet
> your requirements. But I wouldn't say that it is useless. This depends
> on your needs. For example, a hex editor is useless for the purpose of
> writing a 200 page essay, sureley. Nevertheless, a hex editor is
> without doubt a very useful tool.
Please!! I never wrote that SC Unipad is useless. I'm sorry
if you got that impression from what I wrote. I just wrote that it's
useless for Hangul Jamo and SE and S. Asian scripts. Even for that,
it can be useful as others and you wrote(,which I admit I didn't realize
when writing my first message on the topic.). Here I should have made
it clear that I was writing from a point of view of average 'non-i18n
engineer' users.
As James, Marco, Doug and you wrote, sometimes it's handy to have
all complex script processing removed and be able to work with hexadecimal
numbers(like Carl Brown's missing glyph representation) or sequence of
clearly distinguishable _spacing_ glyphs for all characters. For sure,
I have a definite need for that.
> >Again, it does not. It treats combining characters as spacing characters.
> >I don't think users of those scripts would regard SC Unipad as supporting
> >their scripts/languages.
>
> You are right. I wouldn't write a letter to somebody in German where
> the diaresis of an umlaut is displayed on the right side of the base
> character. If I want to write a letter there are many word processors
> out there which I can use. However, if I have (for instance) the need
> to distinguish between 'u with diaresis' and 'u with double acute' I
> may need an editor that is able to display those characters separated
> and unambiguously. It's your decision whether you need such editor or
> a word processor or some other Unicode editor.
Here comes our difference. You draw a line between word processor
and editor at a difference place than I do. As I wrote above, I'm
wearing a hat of ordinary 'Pop and Mom' users when drawing that line in
this thread. Ordinary people in Laos and Kampuchea should not be required
to use feature-rich (or feature-ridden depending on how you view things)
expensive and sometimes sluggish word processors to edit simple documents
in their native scripts, should they? You can also consider the following
scenario. Sometime in the future, i-DNS will take off and FQDN can
have all sorts of characters drawn from many different scripts. If
you're a network administrator in India editing DNS table, wouldn't
it better/more efficient to be able to edit it with an editor that can
render Indic scripts properly than to have to work with hex numbers or
spacing representation of Indic letters? Well, I have to admit that in
this particular case (DNS table editing) unambiguous spacing character
representaion might be preferred by some for security reasons. How about
a Burmese programmer who wants to comment her/his C++ program in her/his
native language? Does (s)he have to use a word processor for editing C++
programs? (S)he can add comments with an editor that renders Myanmar script
with 'spacing' glyphs, but it is obvious which (s)he would choose when
there's a choice. The same is true of editing html/xml files. (please,
don't say nobody uses a simple text editor to edit html/xml files any
more..)
Thanks again for your clarification and looking forward to
improved support of many scripts in SC Unipad,
Best,
Jungshik
This archive was generated by hypermail 2.1.2 : Wed Aug 28 2002 - 14:23:30 EDT