Le 30/05/12 06:26, Jean-François Colson a écrit :
Le 28/05/12 22:53, Doug Ewell a écrit :
Karl Pentzlin wrote:
As said in an earlier posting, the part 9995-9 is now in DIS, which
means that its final version will be published 2013 or 2014. Thus,
national standards referring to this part will h
(鱼丹) pinyin is: dan1.
(鱼丹) is Chinese name of some fish.
In chinese:
Danioninae = (鱼丹)亚科
Gymnodanid = 裸 (鱼丹)属
Gymnodanid strigatus = 条纹裸(鱼丹)
Danio = (鱼丹)属
Danio aequipinnatus = 波条(鱼丹)
Danio kakhienansis = 红蚌(鱼丹)
Danio myersi = 麦氏(鱼丹)
Danio interrupta = 半线(鱼丹)
Danio apogon = 缺须(鱼丹)
Danio chryso
I have found examples of the use of this character (鱼丹) in print in
the following academic article available on line:
"Composition and Status of Fishes of Nanla River in Xishuangbanna,
Yunnan, China"
ZHENG Lan-ping, CHEN Xiao-yong*, YANG Jun-xing
Zoological Research 2009, Jun. 30(3): 334−340
http
And (鱼芒) on page 4.
Michael Everson * http://www.evertype.com/
On 30 May 2012, at 15:14, Andrew West wrote:
> I have found examples of the use of this character (鱼丹) in print in
> the following academic article available on line:
>
> "Composition and Status of Fishes of Nanla River in Xishuangbanna,
> Yunnan, China"
> ZHENG Lan-ping, CHEN Xiao-yong*, YANG Ju
Following up on Andrew West's comment that all such new scientific
characters should be researched and encoded en masse, I would also add
that consideration should be given to encode both the simplified and
traditional versions of such characters in pairs, where merited, as
clearly would be the cas
On 30 May 2012 15:30, Michael Everson wrote:
>
>> http://www.bioline.org.br/pdf?zr09050
>
> (鱼皮) is also found there, on page 3.
That one is already encoded as U+9C8F 鲏 so it is odd that they needed
to create their own custom glyph for it.
> And (鱼芒) on page 4.
But that is an unencoded simplifi
On 30 May 2012 16:12, Andrew West wrote:
>
>> And (鱼芒) on page 4.
>
> But that is an unencoded simplified form of U+29DF6 𩷶
Oddly, the editors have created a new glyph for the unencoded
simplified form of U+29DF6 𩷶, but have not done the same for U+9BA1 鮡
and U+9B88 鮈 (for which there are no corr
Making a proposal directly to the IRG isn't possible under the present
procedures. What's usually done for this kind of thing is to have the UTC
propose them.
Andrew West 於 2012年5月30日 上午8:14 寫道：
> I personally think that rather than add characters such as this
> piecemeal, it would be more
On 28 May 2012, at 01:33, Jean-François Colson wrote:
> Le 05/03/12 19:34, Michael Everson a écrit :
>> Comment is invited.
>>
>> http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4195.pdf
>>
>> I have had some feedback from the UTC already.
>>
>> Michael Everson * http://www.evertype.com/
>
> Hello
>
On Tue, 29 May 2012 12:52:12 -0700
"Doug Ewell" wrote:
> And yes, of course it's possible to stack an entire new layer on top
> of the existing Windows key architecture, as Keyman does. Maybe that
> is the long-term solution, but I haven't heard that MS is planning to
> go that route.
I'm confus
Michael Everson wrote:
>> “10a. Can any of the proposed character(s) be considered to be
>> similar (in appearance or function) to an existing character?”
>> “No.”
>> I’m a little surprised. If the 2nd possibility was envisioned, isn’t
>> it because many Unifon letters are similar in appearance a
On 30 May 2012, at 20:46, Doug Ewell wrote:
> N4262 says the same, and so do practically all proposal forms in response to
> that question, no matter how similar any of the characters are to others in
> appearance or function. I think authors know it's a big red flag if they say
> "Yes."
That,
On 5/29/2012 9:34 PM, Jukka K. Korpela wrote:
For comparison: The design of the euro sign was published in 1996. It
was added to Unicode in version 2.1 in 1998. As physical money, notes
and coins, the euro was taken into use in 2002. Considerable resources
were spent into the introduction of
There is definitely a problem.
The origin is complicated. All that anyone really needed were 10 characters
for emoji flags, encoded as compatibility characters. However, certain
people (I'll call Completionists) who think that if you encode one member
of a set (even for compatibility characters!),
On 31 May 2012, at 00:24, Mark Davis ☕ wrote:
> There is definitely a problem.
The problem is the condescending revisionism you are about to indulge in, Mark.
> The origin is complicated. All that anyone really needed were 10 characters
> for emoji flags, encoded as compatibility characters.
2012/5/31 Michael Everson :
> On 31 May 2012, at 00:24, Mark Davis ☕ wrote:
> Members of ISO National Bodies quite properly thought that it is
> inapprioprate for an International Standard to encode the flags of some
> countries and not the flags of others. You can stuff your condescension, Mark.
I do have a few comments and questions I'd like to make about N4262.
αʹ) I think LATIN LETTER TURNED-E R should be disunified from U+025A LATIN
LETTER SCHWA WITH HOOK. I don't think the identity of the new capital character
matches the established identity of U+025A. Of the five glyphs provided
Actually, I just noticed that Hupa and Yurok have TLE sorted after Y, so point
ϛʹ is moot.
—Ben Scarborough
On 5/30/2012 7:19 PM, Philippe Verdy wrote:
2012/5/31 Michael Everson:
On 31 May 2012, at 00:24, Mark Davis ☕ wrote:
Members of ISO National Bodies quite properly thought that it is inapprioprate
for an International Standard to encode the flags of some countries and not the
flags of others. Y
A seemingly straightforward solution to the “unambiguous mapping” problem would
be to use the existing Plane 14 tag letters along with a new FLAG TAG, say at
U+E0002. Then would unequivocally denote the current
Swiss flag. No need for separate lead and trail. Simple.
... What’s that? Oh, sorry
2012/5/30 "Martin J. Dürst" :
> On 2012/05/30 4:42, Roozbeh Pournader wrote:
>
>> Just look what happened when the Japanese did their own font/character set
>> hack. The backslash/yen problem is still with us, to this day...
>
>
> To be fair, the Japanese Yen at 0x5C was there long before Unicode,
22 matches
Mail list logo
