Re: Information about curly-tailed phonetic letters

[Richard Cook]

"J%ORG KNAPPEN" wrote:
> 
> The curly-tail consonants t, d, n, l, c, z are also included in the
> TeX IPA (tipa fonts). The documentation of those fonts is available
> on
> 
> ftp://ftp.dante.de/texarchive/fonts/tipa/tipaman.ps.gz
> 
> --J"org Knappen

Thanks. The URL should have a hyphen in it:

ftp://ftp.dante.de/tex-archive/fonts/tipa/

and I don't see the curly-tail-l in the tipaman.pdf ... which is not
really surprising. and no curly-tail-r either :-)

RE: Kana and Case (was [totally OT] Unicode terminology)

[Christopher John Fynn]

Michael Everson [mailto:[EMAIL PROTECTED]]wrote:

> What has fictionality have to do with it? The criteria for encoding rest
> primarily in the area of information interchange. Now it seems perhaps not
> very likely that most users of Klingon (which is a language people learn
> and use whether anyone else likes it or not; it's no worse than Volapük or
> Esperanto just because it's invented) actually employ the Klingon script.
> But Tengwar and Cirth are "fictional" scripts which are used and studied by
> linguists and enthusiasts, and there are manuscripts containing text
> written in these that people want to digitize and so on
>
> Arguably, more has been written in and about Tengwar and Cirth than has
> been written about the "non-fictional" Elbasan or Nsibidi scripts


OK but at present I think the acceptance and adoption of Unicode / ISO 10646 is
far more important. If the encoding of these scripts undermines the credibility
of these standards and gives people the excuse some are looking for not to
adopt them, let's leave them out at least until ISO 10646 / Unicode is THE
standard character set.

Meanwhile there is the PUA and conventions for it's use such as ConScript.

Once ISO 10646 is the universally adopted character set there would be no harm
in officially encoding these scripts.

Meanwhile, have there been any actual implementations of Klingon, Tengwar,
Cirth etc based on the Conscript encoding?

- Chris

Re: Japanese @ in html

[James Kass]

The full width at sign at U+FF20 (?)

HTML NCR format ＠

Hope this helps.

Best regards,

James Kass,

- Original Message - 
From: "George Zeigler" <[EMAIL PROTECTED]>
To: "Unicode List" <[EMAIL PROTECTED]>
Sent: Friday, November 24, 2000 1:50 PM
Subject: Japanese @ in html


> Hello,
> 
>   my companies programmer can't seem to figure at what composes the
> character "@" in Japanese html text as seen in:
> http://www.dragon.co.jp/category/0318.html
> 
> We copied this symbol from the Japanese text and copied the identical
> symbol from English text into Word.  When viewed with the same Times NewRoman
> font for instance, there did seem to be a difference, which was weird.  They
> both became identical when viewed with a Arial Unicode.
> 
> He wants the code as seen in html with the "&" sign.  Something like
> "&lkj" or whatever.  Anyone have any knowledge of this?
> 
> Thanks
> George
> 

Japanese @ in html

[George Zeigler]

Hello,

  my companies programmer can't seem to figure at what composes the
character "@" in Japanese html text as seen in:
http://www.dragon.co.jp/category/0318.html

We copied this symbol from the Japanese text and copied the identical
symbol from English text into Word.  When viewed with the same Times NewRoman
font for instance, there did seem to be a difference, which was weird.  They
both became identical when viewed with a Arial Unicode.

He wants the code as seen in html with the "&" sign.  Something like
"&lkj" or whatever.  Anyone have any knowledge of this?

Thanks
George

RE: List style type names

[Jonathan Rosenne]

It's missing in CSS2, although many similar numbering systems were included. It
should be brought to the attention of the CSS3 authors.

Jony

> -Original Message-
> From: Roozbeh Pournader [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 24, 2000 10:04 PM
> To: Unicode List
> Cc: Unicode List; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: List style type names
>
>
>
>
> On Fri, 24 Nov 2000, Lars Marius Garshol wrote:
>
> >  - are there any other numbering systems that are as commonly used as
> >those in this list that ought to be added?
>
> The alternative numbering system to the decimal system used in Iran and
> many Arab countries named "abjad" is surely missing. It is based on
> an old ordering of the Arabic alphabet, and is considered something like
> the equivalent of roman numbering in latin texts. I can provide info on
> the numbering system as used in Iran, but I do not anything about the
> differences with Arab countries.
>

Re: List style type names

[Roozbeh Pournader]

On Fri, 24 Nov 2000, Lars Marius Garshol wrote:

>  - are there any other numbering systems that are as commonly used as
>those in this list that ought to be added?

The alternative numbering system to the decimal system used in Iran and
many Arab countries named "abjad" is surely missing. It is based on
an old ordering of the Arabic alphabet, and is considered something like
the equivalent of roman numbering in latin texts. I can provide info on
the numbering system as used in Iran, but I do not anything about the
differences with Arab countries.

Re: List style type names

[Jungshik Shin]

On Fri, 24 Nov 2000, Lars Marius Garshol wrote:

>
> In the CSS 2 specification one can specify the numbering style to be
> used for numbered lists, and the specification lists some
> international style types, but also leaves out a substantial number.
> http://www.w3.org/TR/REC-CSS2/generate.html#propdef-list-style-type >

>  - are there any other numbering systems that are as commonly used as
>those in this list that ought to be added?

Two systems I know of  are hangul-syllable and hangul-consonant widely
used in Korea.

  Ga, Na, Da, Ra, Ma,Ba, Sa,...
  Gi-yeok, Ni-eun, Di-geut, Ri-eul, Bi-eub, Si-eut,  .

BTW, is there any way to 'fine-tune' the list-style in CSS 2 framework
beyond the numbering system?  For instance, can I distinguish between the
following two?

  1. ---  (1) ---
  2. ---  (2) ---
  3.  (3) ---


Jungshik Shin

P.S. I'm afraid this is clearly off-topic for the unicode list

Re: List style type names

[Jungshik Shin]

On Fri, 24 Nov 2000, Jungshik Shin wrote:

> BTW, is there any way to 'fine-tune' the list-style in CSS 2 framework
> beyond the numbering system?  For instance, can I distinguish between the
> following two?
>
>   1. ---  (1) ---
>   2. ---  (2) ---
>   3.  (3) ---

Sorry. I should have read the document (RFC-CSS2)  before asking the above.
There's for sure a way.

Jungshik Shin

List style type names

[Lars Marius Garshol]

In the CSS 2 specification one can specify the numbering style to be
used for numbered lists, and the specification lists some
international style types, but also leaves out a substantial number.
http://www.w3.org/TR/REC-CSS2/generate.html#propdef-list-style-type >

It now transpires that Mozilla has implemented a much longer list, as
shown below[1]. It seems to me that there would be definite value in
putting together a more complete list than the one currently in CSS2,
but that this list should be quality-checked in some sense.

If anyone on this list feels able to do so it would be nice to have
comments on the following questions regarding the list below:

 - are any of the names ambiguous in that they could refer to more
   than one possible numbering system?

 - are any of these numbering systems so rarely used that it would be
   better to omit them?

 - are there any other numbering systems that are as commonly used as
   those in this list that ought to be added?

Thank you for any help you may be able to provide on this.

--Lars M.

[1] (it may be that some of the values below belong to other CSS
properties that list-style-type)

(arabic-indic, arabic_indic)
(armenian, armenian)
(bengali, bengali)
(cjk-earthly-branch, cjk_earthly_branch)
(cjk-heavenly-stem, cjk_heavenly_stem)
(cjk-ideographic, cjk_ideographic)
(devanagari, devanagari)
(georgian, georgian)
(gujarati, gujarati)
(gurmukhi, gurmukhi)
(hebrew, hebrew)
(hiragana, hiragana)
(hiragana-iroha, hiragana_iroha)
(japanese-formal, japanese_formal)
(japanese-informal, japanese_informal)
(kannada, kannada)
(katakana, katakana)
(katakana-iroha, katakana_iroha)
(khmer, khmer)
(lao, lao)
(lower-alpha, lower_alpha)
(lower-greek, lower_greek)
(lower-latin, lower_latin)
(lower-roman, lower_roman)
(malayalam, malayalam)
(myanmar, myanmar)
(oriya, oriya)
(persian, persian)
(simp-chinese-formal, simp_chinese_formal)
(simp-chinese-informal, simp_chinese_informal)
(tamil, tamil)
(telugu, telugu)
(thai, thai)
(trad-chinese-formal, trad_chinese_formal)
(trad-chinese-informal, trad_chinese_informal)
(urdu, urdu)

Re: Kana and Case (was [totally OT] Unicode terminology)

[Marion Gunn]

Arsa Michael Everson:

> ...
> Arguably, more has been written in and about Tengwar and Cirth than has
> been written about the "non-fictional" Elbasan or Nsibidi scripts.

Only because devils find work for idle hands to do when angels are otherwise
engaged.
mg

--
Marion Gunn
Everson Gunn Teoranta

Re: Greek Diacritics Again

[Antoine Leca]

Lukas Pietsch wrote:
> 
> there's another issue about Greek diacritics I'd like to ask the opinion of
> the people who are in the know: the question of (monotonic) Greek "TONOS"
> and (polytonic) Greek "OXIA" and their equivalence.

Please note I am not an expert here, but things appear clear enough to me
that I believe I can answer your questions.

As you might already know (but as some new readers may ignore), "tonos"
means accent in Greek, and "oxia" means acute. So-called monotonic
Greek have (obviously) only one accent, and this is the acute accent.
Oxia (tonos). U+0301.

Now, about U+030D (combining vertical line above), which happens to have a
note appended saying tonos, I believe this is slightly misleading, but
any reader that has doubt here will be directed in the correct way by looking
at the note appended to U+0301:
= Greek oxia, tonos
(I am referring myself to NamesList-3.0.0.txt, available from www.unicode.org)
The book says very probably the same, but I did not check.
The same holds for U+0344.

Names are another things, since they are leagacy from the past and cannot
be changed; and here they may easily mislead.

 
> I seem to remember I read in some Unicode document that the Greek "TONOS"
> could be realized *either* as an acute *or* as a vertical stroke.

Anyway, Unicode does not require particular representations, it is just
a guideline here.


> On the other hand, the standard is of course quite unambiguous now about the
> fact that the two accents are equivalent in principle.

Again, there is no equivalence here. They are the same concept, known by
two different name. That is similar to Spanish. The Spanish accent can be
named as "accento" or "accento agudo". There is no need to create an
equivalence between "agudo" and "accento" in Spanish. The concept is always
the same.


> Would it be fair to sum up the consequences of all this for font design in
> the following way: If a font is designed for use with both monotonic and
> polytonic Greek, then the "tonos" glyphs should *definitely* look like
> acutes.

Sure (how can it be done otherwise?)

> If a font is designed for monotonic Greek only, a font designer can
> choose to use either acutes or verticals (or any other shape, for that
> matter: decorative typefaces in Greece are apparently using all sorts of
> things from wedges to dots or squares...)

Yes. But for quality, the acute form, the same as the one used above,
would be better.

> But can you think of any good reason for a font to have different (default)
> glyphs for the "tonos" and for the "oxia" characters side by side?

I can't understand this question.
If I translate to Spanish, it becomes:
| But can you think of any good reason for a font to have different (default)
| glyphs for the "accento" and for the "agudo" characters side by side?

?


Antoine

Re: Information about curly-tailed phonetic letters

[J%ORG KNAPPEN]

The curly-tail consonants t, d, n, l, c, z are also included in the
TeX IPA (tipa fonts). The documentation of those fonts is available
on 

ftp://ftp.dante.de/texarchive/fonts/tipa/tipaman.ps.gz

--J"org Knappen