em from 2001.
Peter
Sent from my Windows Phone
From: Eli Zaretskii<mailto:e...@gnu.org>
Sent: 7/18/2013 11:47 PM
To: Peter Constable<mailto:peter...@microsoft.com>
Cc: nospam-ab...@ilyaz.org<mailto:nospam-ab...@ilyaz.org>;
unicode@unicode.org&
"... it is becoming more difficult to develop solutions for lesser used
languages."
Well, starting in Windows 8 the languages you can configure for input number in
the thousands, being limited only by text display capabilities. E.g., in
Windows 8 you could configure Dyirbal as one of your langu
e contents on Windows?
On Fri, Jul 12, 2013 at 04:46:23AM +, Peter Constable wrote:
> Your Tai Tham situation is, of course, exceptional. For a lot of
users, though, if they would only update their XP machines to even
Windows 7, if not Windows 8.1, they'd find a lot of characters
FYI: There's a page on the MSDN site that summarizes additions in each Windows
release to fonts and text display components to support new scripts. This has
been updated for Windows 8.1:
http://msdn.microsoft.com/en-us/goglobal/bb688099
Peter
ot improved for several
versions, but I know there are some updates that have been made for IE 11.
Peter
-Original Message-
From: Christopher Fynn [mailto:chris.f...@gmail.com]
Sent: 12 July 2013 09:41 PM
To: Peter Constable
Cc: Unicode List
Subject: Re: Ways to show Unicode contents o
1 Jul 2013 17:41:34 +0000
Peter Constable wrote:
> It's not clear to me what you're asking, or why you are asserting that
> "there is no way to show Unicode contents on Windows".
What Ilya wants is automatic fallback to a supporting font if there is one. For
exampl
It's not clear to me what you're asking, or why you are asserting that "there
is no way to show Unicode contents on Windows". All text display in Windows
uses Unicode. To my knowledge, Windows 8 has built-in text display support that
covers more of Unicode than any other widely-available OS, and
I would be inclined to assume that there are Unicode 1.1 apps loitering about.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Richard Wordingham
Sent: March 8, 2013 1:42 PM
To: unicode@unicode.org
Subject: Re: Are there any pr
Well, I suppose it's long enough since Klingon was invented that it's
conceivable there are people that grew up as in homes with dedicated Klingon
speakers such that they can reasonably be called native speakers.
But somehow I doubt it.
Peter
-Original Message-
From: unicode-bou...@un
Changing the primary fonts used throughout the Windows 7 shell is not a
supported scenario.
If you were to install a Chinese language pack (available to you if you have an
Ultimate or Enterprise license), then either Microsoft YaHei (for Simplified)
or Microsoft JhengHei (for Traditional) woul
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Naena Guru
> I made the first smartfont for Singhala in 2004... all the browsers except IE
> render
> the complex letters perfectly. (Er, Google Chrome, nearly there):
> http://www.lovatasinhala.com (hand coded)
>
Assuming that SignWriting display controls can be applied to _any_ character
will result in a large number of alternate encoded representations for text
elements. If encoded, then I will expect UTC to stipulate that rendering
engines must not allow such display controls to affect the display of
If SignWriting were encoded as per N4090 and I were implementing text display
support for those characters, I would not allow any of the SignWriting display
controls to itemize together with characters of any other script. I.e., I would
explicitly not support any of the effects you describe invo
From: unicode-bou...@unicode.org [unicode-bou...@unicode.org] on behalf of Doug
Ewell [d...@ewellic.org]
> Philippe suggests a mechanism for
> representing flags when Unicode already has one...
>> Next This is not "duplicate encoding". Given that there's no such
>> first encoding of national fl
: Andrew West; unicode-bou...@unicode.org; Peter Constable
Cc: unicode@unicode.org
Subject: Re: [OT] Flerovium and livermorium get names on the periodic table of
elements
Can't they be represented by fusion of other elements?
;-)
Sent from my Verizon Wireless BlackBerry
-Original Me
FYI – I know at least some folk here will find this of interest:
http://www.theverge.com/2012/6/1/3057261/flerovium-livermorium-periodic-table-of-elements
Peter
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of William_J_G Overington
> Thinking about this after posting and thinking of the vast coding space
> that could be opened up for flag encoding by just adding U+E0002 into
> regular Unicode...
I'd suggest you _don't
And Windows systems were updated in May 2011. (MS Office got updates in a
similar time frame.)
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Tom Gewecke
Sent: May-28-12 6:41 AM
To: Unicode Mailing List
Subject: Re: Exact posi
From: Shriramana Sharma [mailto:samj...@gmail.com]
> Any reason why the glyph of the current existing character 20A4 ₤ LIRA SIGN
> could not have been changed instead? The glyph is similar to that of 00A3 £
> POUND SIGN, and 20A4 was *anyway* not used in favour of 00A3...
In addition to Asmus'
[mailto:unicode-bou...@unicode.org] On Behalf
Of Andreas Stötzner
Sent: May-21-12 2:54 PM
To: unicode Unicode Discussion
Subject: Re: Unicode 6.2 to Support the Turkish Lira Sign
Am 21.05.2012 um 22:48 schrieb Peter Constable:
they will hardly want to use the old drachma sign (₯, U+20AF)—it’s very
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Jukka K. Korpela
> I think you (and Peter) missed a joke
I can't speak for Sharma, but as for me...
> they will hardly want to use the old drachma sign (₯, U+20AF)—it’s very
> old-fashioned and not in line with
20AF DRACHMA SIGN is our friend.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Andreas Prilop
Sent: May-19-12 8:42 AM
To: unicode@unicode.org
Subject: Re: Unicode 6.2 to Support the Turkish Lira Sign
On Tue, 15 May 2012, anno
Whatever Emacs or other implementations use, I'd consider 00D7 a better choice
than 0078 for a generic base placeholder on which to display non-Latin (or any)
combining marks.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Ri
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Ben Monroe
> Please advise on appropriate encoding method and display options.
> I am using a Windows 7 system.
Windows 7 supports display of conjoining jamos, though not in a manner
conforming to Korean standard
Someone has apparently discovered that Unicode’s rich character repertoire may
be able to help them avoid spam filters. Here’s a subject that made its way
into my inbox today:
ọNĺἺńἚ ṔɦȁṜḿãϚỲ==çhϵсK ḀṰťΑϚȟmȆŋŢ
Peter
If you want to make claims about Tamil script having a scientific basis, please
take that up with Korean experts who make the same claim of their script, and
then let us know when you come to some agreement.
Peter
From: indic-bou...@unicode.org [mailto:indic-bou...@unicode.org] On Behalf Of
. Ganesan; Peter Constable
Cc: wg02infitt; gbinf...@yahoogroups.com
Subject: Re: [indic] Re: Tamil Anusvara (U+0B82) glyph shape [ Re: Dot position
in Gurmukhi character U+0A33]
Dear All,
There is a misunderstanding about Tamil here.
To my knowledge, in day to day usage Tamil uses far more sounds
Srivas: You shouldn’t take a narrow view of the impact of the Tamil script.
Apparently, there are people that embrace it even when trying to write text in
languages other than the primary one it was associated with. This is not unlike
people using Hangul script for phonetic transcription of othe
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Philippe Verdy
> This arc is a true phonetic mark of a contextual elision...
> Exactly similar to other phonetic symbols like the elision tie
There are two kinds of arc shown in the image:
- arcs that span a spac
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Doug Ewell
> This is one of the things the PUA is for. Unfortunately, it has become
> very popular to tell people to stay away from the PUA, that it is evil
> and unsuitable for any sort of interchange
That's an
From: Shriramana Sharma [mailto:samj...@gmail.com]
> Peter, I agree that there are many variegated representations. But my
> gut feeling as a native user of many other Indic scripts and one who has
> to use the candrabindu a lot due to Sanskrit, is that it should be
> positioned above the RHS
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Gerrit
> It works flawlessly in Firefox (which is the only browser to support it
> - Internet Explorer, Chrome and Safari don’t support it. I don’t know for
> Opera).
I've scanned this thread and can't figure out
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of delex r
> I hope you understand my sense at that time and don’t go technically).
> I am not going into the technical matters of coding characters . My point ,
> I hope many of you understood, was regarding naming
Richard Wordingham
Sent: Sunday, September 11, 2011 5:19 PM
To: Unicode Discussion
Subject: Re: ligature usage - WAS: How do we find out what assigned code points
aren't normally used in text?
On Sun, 11 Sep 2011 23:14:04 +0200
Kent Karlsson wrote:
> Den 2011-09-11 18:53, skrev "Pe
There's no requirement that the width of glyphs in a monospaced font be 1 em. I
would agree, though, that if a monospaced font forms a ligature of a pair like
<0066, 0069>, then it should be twice the width (not necessarily 2em) of
single-character glyphs.
In a monospace font, nothing prevents
Once a script is encoded, the reference name used in the Standard for the
script becomes part of stable character identifiers that _cannot be changed_.
This is not just Unicode policy; this is policy of ISO JTC1/SC2. The reference
name "Bengali" for the script in question cannot be changed. The
You appear to be assuming that Unicode lists languages. It does not. It deals
with characters and scripts. As mentioned before, it does not attempt to
document all possible and preferred ways to refer to characters or scripts;
that is well beyond the scope, purpose and requirements. All that Uni
“TrueType” can mean different things depending on context.
- The TrueType font format specification
- The TrueType glyph outline/ hinting format
- The “sfnt” font file format
These are all inter-related. The TrueType font format was defined around 20
years ago by Ap
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
> 2011/8/22 Peter Constable :
>> Of course _OpenType_ cannot, but any rendering engine that uses OpenType
>> _must_ resolve the bidi level of _all_ characters in a sequence that it is
>> given
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Philippe Verdy
> But I suspect that the strong opposition given by Peter Constable...
Yet again, I think you're putting words in my mouth. The only thing I think
I've explicitly spoken against in t
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Philippe Verdy
> Lookup tables in fonts (at least OpenType) do not work at the character
> level, but at the glyph level: they substitute glyph ids by other glyph ids.
That much is true.
> Sequences of glyph id
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>2011/8/22 Joó Ádám :
>> Speaking of actual implementation, I’m convinced that this format
>> should be the same as it is for encoded characters ...
> As well, the small properties files can be embedded, in a very compa
u
expect. But there will likely be some different views on what ought to be
included within that "some".
Peter
-Original Message-
From: Doug Ewell [mailto:d...@ewellic.org]
Sent: Sunday, August 21, 2011 2:20 PM
To: verd...@wanadoo.fr; Peter Constable
Cc: Michael Everson; U
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Asmus Freytag
> Treating PUA characters as ON is very problematic
As would be changing the default property of PUA characters from L to ON.
Peter
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>> As I explained in an earlier message, the layout engine doesn't use
>> the "default" property value but the resolved bidi level.
>
> Once again, you refuse to understand my arguments.
I don't think I'm refusing to u
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
> A GSUB operation will only be used if it is specified in the correct feature
> table. The problem here is which feature to use: "rtlm" or "ltrm" ? It's
> impossible to know because it first depend on the layout engine
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>> In the OpenType specification
> In addition, this specification highly depends on two things:
> - the layout engine fully knows the properties of all characters in
> order to implement BiDi reordering as well as
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>> I agree that OpenType font tables cannot to glyph re-ordering. But totally
>> incorrect in saying that it cannot handle ligatures.
> I meant "recognizing and generating ligatures in the context where
> re-ordering h
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Philippe Verdy
> Hmmm Given the current standard in OpenType, and the fact that
> OpenType fonts cannot reorder glyphs to support the BiDi algorithm
> and correctly handle featues like ligatures...
I agree th
From: unicore-boun...@unicode.org [mailto:unicore-boun...@unicode.org] On
Behalf Of Michael Everson
>> Yeah OK maybe simply base+diacritic stuff or even ligatures would be
>> easy to do via simple substitution rules in tables, but how about glyph
>> reordering?
> No problem unless you are usi
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>>> These things are much easier if you are a member of the consortium (cost is
>>> as little as $35/yr for students).
>>
>> Which may still be not negligible sum for some people, especially not
>> US citizens...
> In
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of mmarx
> While I am at it:
> should Unicode acknowledge that U+0730, U+0733, U+0736, U+073A
> and U+073D are used with the ARAB script or does this lie outside its
> competence and jurisdiction?
Unicode has chara
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
> In clear texr this means that all those Asian "insular" scripts
In "insular SE Asian scripts", insular modifies "SE Asian", not scripts. It
means the island sub-region of SE Asia, as opposed to mainland SE Asia.
>
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>>> What would be the behavior of a font that would use GSUB entries (or
>>> ligatures) in a feature to implement the reordering that NO renderer
>>> currently implements for Buginese ? What will happen later if the
>>>
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
> What would be the behavior of a font that would use GSUB entries (or
> ligatures) in a feature to implement the reordering that NO renderer
> currently implements for Buginese ? What will happen later if the
> rendere
riginal Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of vanis...@boil.afraid.org
Sent: Saturday, July 23, 2011 11:35 PM
To: Peter Constable; vanis...@boil.afraid.org; unicode@unicode.org; Philippe
Verdy
Subject: RE: Prepending vowel exception in Lontara/
Van is mistaken in his understanding of OpenType Layout. There is no mechanism
to describe re-ordering in OpenType Layout tables in a font. That must be
handled by the OTL client software.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On B
In the OpenType model, a distinction is made between font-specific behaviours
and font-neutral script behaviours. OpenType Layout tables were designed to
deal with only font-specific details, leaving it to OTL client software to
handle anything that is font-neutral.
Re-ordering of prepended Bu
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Asmus Freytag
Sent: Sunday, July 17, 2011 6:34 PM
...
>> Another alternative: instead of encoding separate symbols for each
>> control, we could as well encode symbols for each character visible in
>> those symbol
So you want to be able to discuss NBSP (say) in plain text. You can already do
that; in fact, you have multiple ways that everybody here will have no
difficulty understanding:
"NBSP"
"no-break space"
"U+00A0"
Creating a different character for SYMBOL FOR NBSP doesn't make communication
here an
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Karl Pentzlin
Sent: Friday, July 15, 2011 9:46 AM
>AW> I oppose encoding graphic clones of non-graphic characters ...
>
> I am just waiting for the killer argument against the encoding of chart
> symbols.
For me t
As always, we want to know that there's a real use case for encoding. Doing
things on spec, especially in a case like this, is IMO not at all a good idea.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Michael Everson
Sent: Fri
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Jean-François Colson
> * In the C’HWERTY layout on Linux, the digraph and trigraph had to be
> replaced
> by six PUA characters
That would appear to be a limitation of the input method. In principle, there's
no
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Philippe Verdy
> One of the main reason for adding the variation sequence is that current font
> technologies ...
> can only be tweaked based on language (and IPA notations apply to any
> language), and
> there'
From: Asmus Freytag [mailto:asm...@ix.netcom.com]
> IPA has other characteristics in both its usage and its encoding that you
> need to consider to make the comparison valid.
> First, IPA requires specialized fonts because it relies on glyphic
> distinctions
> that fonts not designed for IPA
tcom.com]
Sent: Thursday, November 18, 2010 11:05 AM
To: Peter Constable
Cc: André Szabolcs Szelp; Karl Pentzlin; unicode@unicode.org; Ilya Yevlampiev
Subject: Re: Are Latin and Cyrillic essentially the same script?
On 11/18/2010 8:04 AM, Peter Constable wrote:
> From: unicode-bou...@unicode.org [
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of André Szabolcs Szelp
> AFAIR the reservations of WG2 concerning the encoding of Jangalif
> Latin Ь/ь as a new character were not in view of Cyrillic Ь/ь, but
> rather in view of its potential identity with the ton
Jim, behaviour will depend on fonts being used. It could also depend on the
version of software you are using. Windows 7 has pretty good support (fonts and
Uniscribe) for all of this.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Beha
On Windows, strings will display correctly in either NFC or NFD provided an
appropriate font is used--that choice being different for Japanese and for
Korean. Windows 7 and earlier do not ship with fonts that support Old Hangul,
but Old Hangul fonts are available from other sources; e.g. there's
You can copy and paste between Unicode-enabled apps to your heart's content.
Only legacy, non-Unicode apps need system locale support.
Peter
From: James Lin [mailto:james_...@symantec.com]
Sent: Tuesday, November 09, 2010 10:24 AM
To: Peter Constable; Andrew Cunningham
Cc: JP Blankert (
A non-Unicode web page is like a non-Unicode app. Web pages, and apps, should
use Unicode.'
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of James Lin
Sent: Tuesday, November 09, 2010 11:24 AM
To: Ed
Cc: Unicode Mailing List
Sub
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Andrew Cunningham
>> Your system locale has to handle the Burmese language. So you need to
>> either install Windows 7 in Burmese or change under Regional /
>> Language options in Control panel, under Adv tab.
>
If you want to write SMS emoji novels, that may be a concern. For occasion use
in SMS, or for non-SMS use, I don't think there's much of a concern.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Shachar Shemesh
Sent: Saturday,
In the subtitle where “atvīkė̄” occurs, the Verdana font is being used; Verdana
is left out of the styling on the following line:
Svēkė atvīkė̄ i Vikipedėjė žemaitiu
kalbuo,
encikluopedėjė, katra gal redagoutė kuožnos
nuorontis.
Verdana does not support U+0304. Arial, however has supported it
From: Andrew West [mailto:andrewcw...@gmail.com]
>> And I'd advise people to upgrade from Windows XP.
> The snide remark seems a little uncalled for. There are
> many reasons why people cannot or will not upgrade
> from XP, and I was simply pointing out an issue that may
> affect some users.
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Andrew West
> However, further testing has indicated that standard Windows applications
> such as Notepad may blue screen crash on some systems when attempting
> to render U+1F5FD (Statue of Liberty, but replaced
186 languages
and 159 regions and is growing.
Still, I’m with all of you that wish things progressed more quickly.
Peter
From: Saqqara [mailto:saqq...@saqqara.org]
Sent: Thursday, October 14, 2010 6:27 AM
To: Peter Constable; Unicode ML
Subject: Re: OpenType update for Unicode 5.2/6.0
From: Ngwe Tun [mailto:ngwes...@gmail.com]
> I understood that supporting Unicode should not be exceptional for Myanmar
> Character Block (U1000-U100F).
Unicode conformance does not require implementations to support all characters
/ blocks / scripts equally.
That said, I thought we had upda
I can’t comment on when limitations in MLang will be addressed; I can only say
that we are aware of them.
Can you clarify what you think is missing from Character Map?
Peter
From: Ngwe Tun [mailto:ngwes...@gmail.com]
Sent: Tuesday, October 12, 2010 7:39 PM
To: Peter Constable
Cc: John H
We are in the process of updating the tags to sync with Unicode 6.0. This has
to be coordinated with the ISO Open Font Format standard, so may take a little
time.
Peter
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of John H. Jenkins
Sent: Monday, October 11,
If this needed a distinct encoding, then I'd be inclined to encode the
letter-diacritic combinations as atomic characters because they form a single
outline, and the interaction of the diacritic with the letter depends on the
particular letter. This is similar to encoding of letters with retrofl
If anybody knows of such fonts and can point me to them or can answer a
question about them, that would be great. My question is to find out what width
they give these characters: proportional, or full cell width?
Thanks
Peter
py of
the text with Stylistic Set 7 enabled for the entire text--so that it will
really flourish.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Peter Constable
Sent: Thursday, August 12, 2010 2:39 AM
To: William_J_G Overi
See the attached PDF showing Unicode 5.2 text set in Word 2010 using the
Gabriola font with line-ending characters formatted with the Stylistic Set 7
OpenType Feature. No PUA; no variation selectors. Just flourishing, OpenType
glyphs.
Peter
-Original Message-
From: unicode-bou...@uni
Correct: Wordpad uses RichEdit; Notepad and Paint do not.
Peter
From: ChiGuy [mailto:chig...@gmail.com]
Sent: Monday, August 09, 2010 11:19 AM
To: Peter Constable
Cc: Murray Sargent; Unicode Mailing List
Subject: Re: number padless?
Ok, well I just tried both tricks out in WordPad, and they
The Alt-x trick Murray mentioned is specific to MS Office applications or to
applications that use the RichEdit control. The ctrl-~ + n trick is also
specific to MS Office products and RichEdit.
Peter
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of ChiGuy
Sent
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Mahesh T. Pai
Sent: Monday, August 02, 2010 6:54 PM
> a claim of IPR of any kind, and unhindered use are incompatible.
Are you saying that in your capacity as an IPR lawyer? ;-)
If the owner of IP grants unhinde
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of vanis...@boil.afraid.org
>I didn't say that. All I suggest is releasing v. 6.0.x, preferably the day
>that the WG2 approves the new Rupee sign or as soon thereafter as a new code
>chart can be uploaded.
New chara
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of John Dlugosz
>> This last message is certainly more on topic there, it discusses
>> existing characters and their usage in some experimental (mostly
> I think so too.
Then please trim the scope of discussion to d
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of John H. Jenkins
>> I am hoping to submit a document to the Unicode Technical Committee in the
>> hope that the Unicode Technical Committee will institute a Public Review.
> I don't believe that the UTC will instit
This is a bad idea.
The best way to make it go away is to just stop discussing it.
Peter
Can we please encode new characters for base-9 digits "0", "1", "2", "3", "4",
"5", "6", "7", "8"?
Peter
This is a bad idea.
The best way to make it go away is to just stop discussing it.
Peter
-Original Message-
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of William_J_G Overington
Sent: Wednesday, June 02, 2010 2:51 AM
To: Unicode Discussion; John H. J
Pollution on this list has waxed and ebbed constantly over the years. When it
has taken Eerie proportions, things have usually gotten sorted out before long
one way or another. Innocuous questions about name stability are nowhere as bad
as acute flame wars over the merits of encoding 22-letter s
"Some font vendors say and publish on their website that their fonts are
Unicode fonts."
All they mean by that that the character encoding assumed by their font is the
character encoding defined in the Unicode Standard.
Neither the Unicode Standard nor the Unicode Consortium has any relationshi
prior to Longhorn.
Peter Constable
such software, but at the same time it is very important
that
> operating systems and major software do the right thing here...
It appears that they are (apart from Web browsers that don't handle HTML
ruby).
Peter Constable
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
> Behalf Of Peter R. Mueller-Roemer
> Did you make a formal proposal for NBSP, as Elaine did for
Samaritan ?
> I have studied unicode's uniqueness-rules, bidi-algorithm and many
> others and feel almost
hat
there are many implementations that do not use those characters (and in
particular FB2A or FB2B). Nor is it necessary to use the precomposed
representations of shin and sin (FB2A and FB2B) for adequate text
representation. Note especially that the normalized representations for
shin and sin, *in
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of E. Keown
> So what's the significance of what you're saying,
> politically?
Please explain this question: what is political about this?
Peter Constable
101 - 200 of 547 matches
Mail list logo