- Original Message -
From: "John Cowan" <[EMAIL PROTECTED]>
To: "Chris Jacobs" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, August 08, 2003 6:22 AM
Subject: Re: Pigpen/Masonic/Poundex
> Chris Jacobs scripsit:
>
> > But you still need to pick one of the variants as the _plai
On 07/08/2003 09:27, Kent Karlsson wrote:
I was so glad that you got things so nearly right for once, and then
you go and spoil it with:
Another similar case would be the use of a isolated nukta (which
normally modifies a following base character): the sequence
Like all other combining c
Kent Karlsson scripsit:
> 4) Encode the vowel signs as combining characters, after
> the base characters they logical follow. Consider them as
> "double" [width] combining characters, that happen to
> have no "ink" above/below the character they apply to,
> but (like double width c
On Saturday, August 09, 2003 1:33 AM, Michael Everson <[EMAIL PROTECTED]> wrote:
> At 01:18 +0200 2003-08-09, Philippe Verdy wrote:
>
> > Such break in a middle of a multiple width diacritic exist in some
> > notations, and are not considered "horrible typography". Just look
> > at musical notati
Philippe continued:
> On Saturday, August 09, 2003 12:49 AM, Michael Everson wrote:
>
> > At 14:22 -0700 2003-08-08, Kenneth Whistler wrote:
> >
> > > Philippe, you are tilting at windmills, here. There is no chance
> > > that the UTC is going to consider such a character, in my
> > > assessment
Thomas Widman suggested:
> Peter Kirk <[EMAIL PROTECTED]> writes:
>
> > On 08/08/2003 08:54, Philippe Verdy wrote:
> >
> > > ... Could there be another codepoint assigned that has
> > >these properties:
> > >
> > >20CF;ZERO WIDTH SYMBOL;Sk;0;ON; 0020N;
> > > [...]
> > But I'm not sure th
At 01:11 +0200 2003-08-09, Philippe Verdy wrote:
I just picked "SYMBOL" to just match the required property that would match
other spacing variants of diacritics. The "ZERO WIDTH" is probably
confusive, but it just marks the fact that it has no associated
glyph and a null *minimum* width (which
On 07/08/2003 15:24, Michael Everson wrote:
At 18:03 -0400 2003-08-07, Karljürgen Feuerherm wrote:
My knowledge of Aramaic script is a little scanty, but my
understanding is
more or less the same as Peter's. Which leads me to suggest that
encoding Aramaic separately would be a bit like encoding
Elaine Keown
Madison WI
> > how to start from a base form and work forward to
> > encompass the whole series of characters which need to be treated "as
> > one" in certain processes, which can include cursor movement, hit
> > testing, display, line breaking, collation, norma
Hi Rajesh,
Unless you are using nchar/nvarchar fields for your data, SQL Server is
using a specific code page (non-Unicode character set) to store your
data. It is likely that this is Cp1252 (Western European).
If you switch to nchar/nvarchar fields your mapping issues will go away.
I have a p
An anonymous wag who picks the nits even finer that I did
wishes the following clarification to be posted regarding
an assertion I made about what Unicode code points are
interchangeable. ;-)
- Begin Forwarded Message -
> So, yeah, basically every sequence of code points "
Miikka-Markus Alhonen scripsit:
> Anyone interested in preparing an encoding proposal?
This is awfully marginal, it seems to me, not so much because of the colors
(which are letter features, like crossbars, bowls, etc. in other scripts),
but because except for "gb" (which is effectively a single
Peter Kirk responded to my plea for everyone to relax a bit:
> >If everyone would just go off for a week or two on their
> >August vacation, like they should be, we could all come back
> >about Labor Day and we wouldn't have to be having these
> >discussions. ;-)
> >
> >--Ken
> OK, understood now
> << Zs, Zl, and Zp are considered format characters, but their
> membership in the Z (separator) class takes precedence over their
> membership in the Cf class, because the General Category assigns
only
> a single value to each character. >>
Whenever you have a question about the status of a char
Kent said:
> >
> > How is: supposed to be different from
> >
>
> The first would be an å followed by separate dot below (under a space,
> according to p. 131 of TUS 3.0). The second one is an
> with a separate ring above (over a space according to TUS 3.0 p. 131).
Dunno what you are
> I suspect this was a typo for p. 1*2*1, where you find the sentence:
Yes, sorry.
> "Defective combining character sequences should be rendered as if they
> had a space as a base character."
>
> But if that is your intent, then you have to take that in the
> context of the beginning of the para
Did you solve your problem? I opened both of these documents into IE,
clicked the "Edit in Microsoft Word" button for each, and they imported
correctly, with the Japanese displaying fine.
In the first test file, the last letter of your name at the bottom is
not correctly encoded in UTF-8 so it doe
At 23:07 +0200 2003-08-07, Kent Karlsson wrote:
> Kent Karlsson scripsit:
> 4) Encode the vowel signs as combining characters, after
> the base characters they logical follow. Consider them as
> "double" [width] combining characters, that happen to
> have no "ink" above/below the c
18 matches
Mail list logo
