Elaine Keown
TEMPORARILY in Madison Wisconsin
Hello:
I am posting this to both regular Unicode and
the new Hebrew list. Please reply off-list or
to the Hebrew list if you want me to see what
you wrote immediately.
I am responding at great length to the Roadmap proposals
for the S
At 10:58 -0700 2003-08-11, Peter Kirk wrote:
On 11/08/2003 06:59, Jon Hanna wrote:
There are only two theoretical problems that I can see here, the first is
that a whitespace character other than space gets converted to space by
attribute value normalisation, and that this changes the meaning of t
Chris Jacobs scripsit:
> But you still need to pick one of the variants as the _plaintext_ (in
> crypto sense) variant, and then you can deem the others to be crypted by
> monoalphabetic substitution.
*shrug*
There are lots of ways to do it, but no compelling need for
standardization.
--
"No,
Philippe replied:
> From: "Kenneth Whistler" <[EMAIL PROTECTED]>
> > Of course a standard which mandates space folding is also
> > within its rights to mandate, for example, the non-use of
> > nonspacing marks applied to SPACE characters. It can simply
> > rule out such sequences as valid for its
I repeat again. Nothing on this list has any guarantee that it will be
seen by anyone in the UTC. If you want to submit a FAQ question that's
great -- and I strongly encourage it. But please use:
http://www.unicode.org/reporting.html to make sure it is tracked.
The same goes for comments from Pete
> It *is* part of the Unicode Standard. You want a stand-alone
diacritic?
> Use SP or NBSP followed by the combining diacritic. It says so, right
there.
Yes. But it is not quite clear how this should interact with combining
characters
that aren't purely 'above' or 'below' a single character (in
Philippe Verdy wrote:
> Spacing diacritics are not "on the edge" of the standard,
The "edge" I was speaking of was the requirement for the exact
display width of a nonspacing diacritic on top of a SPACE to
be specifiable in some determinant way.
> when they
> are already given a full block and
Peter Kirk scripsit:
> The gap may not be large, but Philippe, John H and I have identified a
> real gap. Why this antagonism against filling it?
What you have identified is a set of implementation defects, not problems
with the Unicode Standard. The standard way to do what you want is to
prec
On Monday, August 11, 2003 2:05 AM, Kenneth Whistler <[EMAIL PROTECTED]> wrote:
> Um, no. Precisely because it would introduce *another* way
> to do what is already specified in the standard. It would, I
> predict, lead to nothing but more trouble.
>
> You might, perhaps, find it satisfying, but
Elaine Keown wrote on 08/10/2003 06:30:44 PM:
> During this short period, when I am on this list and receiving
> the enormous volume of mail, I am stating things that I will not be
> around much to state.
Therein lies a problem in attitude: encoding of scripts, and doing it well,
takes an on-goi
Peter Kirk responded:
> On 11/08/2003 06:59, Jon Hanna wrote:
>
> >There are only two theoretical problems that I can see here, the first is
> >that a whitespace character other than space gets converted to space by
> >attribute value normalisation, and that this changes the meaning of the text
>
On 11/08/2003 06:13, [EMAIL PROTECTED] wrote:
Elaine Keown wrote on 08/10/2003 06:30:44 PM:
During this short period, when I am on this list and receiving
the enormous volume of mail, I am stating things that I will not be
around much to state.
Therein lies a problem in attitude: encoding
Kyekyeku, Quick answers re the characters:
Quoting "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
[ . . . ]
> Only the 5th and 15th characters of the Akan alphabet are not in the
Basic
> Latin character set. The Capital form (big letter) of 5th character is in the
> Latin Extended-B character se
Elaine Keown
still in Madison
Dear Michael Everson and Other Interested People,
> script does not mean that every script is just a font variant of the
> Hebrew script.
In actuality, one could make a very good case that all extant Semitic/
extended Aramaic-Moabite-A
On 10/08/2003 15:27, Kenneth Whistler wrote:
Peter Kirk said:
Tell Microsoft! (See Noah Levitt's posting.)
Indeed.
If this is indeed "The standard way to do what you want", then the
standard needs to make it clear that the sequence of or has the properties which I want, i.e. it
ha
...
> >and "interfere typographically" are assigned the same
> combining class,
> >while those that don't get different classes, ...
> >
> Not true, as we have seen for Hebrew. It's supposed to be true, but
> isn't, and the problems can't be fixed.
The combining classes for Hebrew (and Arabic) v
> Please can you clarify. Is there anything unusual about
> positioning of nukta,
No, just another "Philippe mistake"... there are so many :-(
> or is it just like any other combining character? In a sequence
> , where A, B and C are base characters, where is the
> nukta located relative to t
> > If this is indeed "The standard way to do what you want", then the
> > standard needs to make it clear that the sequence of
> > mark> or has the properties which I
> want, i.e. it
> > has the width of the combining mark alone, and not the full
> width of a
> > space,
>
> This is up t
18 matches
Mail list logo
