It certainly is exciting!
I learn a lot from your fun Doug. I remember when we had The Respectfully
Experiment and I asked you how you managed to get the U+E707 character into
your message and you mentioned the SC UniPad program from the
http://www.unipad.org webspace. That program is very
John Clews wrote as follows.
quote
In fairness, you ought to take account of the fact that languages of
the Indian subcontinent have been displayed on TV systems in India
for nearly ten years, based around ISCII.
Is there a reason for doing anything different for DVB-MHP?
Or are mappings and
From: William Overington [EMAIL PROTECTED]
It certainly is exciting!
Whoosh!
MichKa
Ken Whistler wrote on 04/02/2003 03:54:10 PM:
That isn't the only convention. I am finding several samples of
typographic
retroflex hook being used to indicate nasalisation of vowels.
Jim Allan is right. It is the *ogonek* which is used to signify
the nasalization of vowels. If you have
I am a new list member interested in
implementing archaic, classical and Hellenistic Greek glyphs in a Unicode font.
My initial questions will be focused on handling multiple alternate glyphs for
each character, andhow to organize a font with several thousand
Hellenistic monograms.
Is this
At 01:45 -0600 2003-04-03, [EMAIL PROTECTED] wrote:
I can't comment on the historical development of this practice and whether
it might have arisen from confusion with ogonek. I think the library on our
center has IJAL from its inception (nearly 70 years), so I could jump back
a decade or two or
In the interests of some fun research in the hope that the fun will lead to
learning in some serendipitous manner I am starting off some Private Use
Area codes for vegetables.
U+10F700 POTATO
U+10F701 CARROT
U+10F702 PARSNIP
U+10F703 PEA
U+10F740 PEAS IN A POD
U+10F780 LEAF OF MINT
U+10F781
Michael Everson wrote on 04/03/2003 07:34:53 AM:
Peter, I often suggest this, and you rarely take me up on it
I take you up on it when it suits what I need to do.
What a bunch of base-ogonek
characters could mean is a mystery to me.
A bunch of ogonek-modified characters: a-ogonek,
At 4:11 PM +0100 4/3/03, William Overington wrote:
U+10F703 PEA
U+10F740 PEAS IN A POD
Surely one would use the GCJ with the first, in order to form the
last of these.
Oh, sorry. Wrong date.
--
Michael Everson * * Everson Typography * * http://www.evertype.com
At 09:28 -0600 2003-04-03, [EMAIL PROTECTED] wrote:
Michael Everson wrote on 04/03/2003 07:34:53 AM:
Peter, I often suggest this, and you rarely take me up on it
I take you up on it when it suits what I need to do.
Well if you want people to give accurate advice based on analysis of
actual
Doug Ewell scripsit:
ISO 3166-2 country
subdivision codes were included too, so codes like en-us-ny (for New
York English) could be constructed.
In fact en-us-ny is syntactically well-formed, but cannot be used unless
registered with IANA, as it does not belong to the set of preregistered
Doug Ewell wrote:
Just as users should not fling Plane 14 language tags around in plain
text, they also should not use Mathematical Alphanumeric Symbols to
create bold, italic, or double-struck effects in plain text. In case
this is not clear, the user interface and operability of MathText is
The attached sample from IJAL shows what is typographically a retroflex
hook being used to indicate nasalisation. I've been in touch with the
out-going editor, and he indicated that he had thought they were using
ogonek.
I've looked back in IJAL a little, and it appears that between 1991 and
Marco,
MANY THANKS for this! I don't know whether I have the skills to contribute
additional language entries for this, but it is a wonderful way to express
what so many of us, both in the USA and in the rest of the world, feel.
Thanks!
Jim
At 18:17 2003-04-03 +0200 Thursday, Marco
All this talk about these higher-plane characters - you know, plane
1 and above; let's call them MathText characters for short - has got
me wondering.
Why is there no UTF-24?
See, these MathText characters take up a lot of space. No matter how
you encode them; UTF-8, UTF-16 or UTF-32; they
.
Michael Everson wrote,
And I mean L2/WG2 documents in PDF format, not a web-page with gifs
that take forever to load. I was unable to review your
tresillo/cuatrillo document for this reason.
Don't you have a web browser?
HTML pages with gifs shouldn't take any longer to download than
PDF
Doug Ewell schreef:
they also should not use Mathematical Alphanumeric Symbols
to create bold, italic, or double-struck effects in plain text.
Why not? I mean, I understand the Mathematical symbols are not
intended for use as styled versions of normal text, but I read
between the lines that
Pim Blokland wrote:
Why is there no UTF-24?
Well, I once proposed UTF-20...
See, these MathText characters take up a lot of space. No matter how
you encode them; UTF-8, UTF-16 or UTF-32; they always are 4 bytes
long.
True for them alone, in those UTFs. Short of defining another Unicode encoding,
And I mean L2/WG2 documents in PDF format, not a web-page with gifs
that take forever to load. I was unable to review your
tresillo/cuatrillo document for this reason.
Don't you have a web browser?
Yes, I do. However, I also have punitively expensive internet access,
and I prefer to download
We add GB18030 support into Mozilla and also add 32 bit cmap support on
windows into Mozilla about a year ago. The Linux and Mac 32-bit cmap
support is a little bit behind
I think we first have GB18030 encoding support in Netscape in Netscape 6.2
You should be able to see whatever the
John Cowan jcowan at reutershealth dot com wrote:
ISO 3166-2 country
subdivision codes were included too, so codes like en-us-ny (for New
York English) could be constructed.
In fact en-us-ny is syntactically well-formed, but cannot be used
unless registered with IANA, as it does not belong
Stefan Persson alsjebegrijptwatikbedoel at yahoo dot se wrote:
Well, let's say that I make a plain text document and include a
mathematical formula or funtion such as cos x, it would still be
legal to use an italic x from the mathematical block, wouldn't it?
This is what those characters are
After searching far and wide and reading all the HOWTOs etc.
I'm still at a loss as to how to make a simple copy/paste
work within xterm and between xterm and XEmacs.
If I cat a utf-8 encoded XML file containing Russian and it
displays just fine. If I select a single word by left
double
I think that is depending on the application support the newly defined UTF8_STRING
for selection or not.
The Linux verion of mozilla implement it so it can copy/paste with the recent
version of xterm w/o problem
Notice that UTF8_STRING is defined AFTER X11 R6 ICCCM.
See the spec in
24 matches
Mail list logo
